Live Workshop: Server-side Rendering (SSR) Workshop using Vite with Romuald Brillout aka @brillout

[Music] and i also do a lot of open source work including big plugin ssr which i'm going to talk about tomorrow and today is a workshop about server side windowing so the next on my screen is mary maybe you want to introduce yourself hello i'm a front-end developer at le boncoin it's a website for classified ads in france yes marcos do you want to introduce yourself i guess not okay who's next alexandra ah no michael inside it's not convenient because it's not we're not in real life but i'll still try to make it interactive uh so let's also use the chat for anyone who doesn't have a mic so let's make it interactive so interrupt me if you have questions let me know okay who else who wants to introduce himself herself anyone see benoit just joined maybe you want to introduce yourself all right i guess we can get started and so who knows approximately okay so um who would say and now is what server side rendering is uh we can quickly chat yes or no like i will start but yes i know what server side rendering is okay let's try enough all right okay so i'll make uh because i wasn't sure but i guess i'll we'll make it really quick about what server is so um it's it's actually really simple so i said the rendering is two things one the content of the page is rendered to html well let me try to share the screen [Music] can you see my screen all right can you see my screen okay i'm reading yes i guess it's for the screen all right i guess you know if you don't see the screen uh speak the audio because i cannot see the chat now but i guess you can see the screen all right so now you should be seeing a little page demo ssr rendered to html question mark interactive question mark so this is a subset rendering it's it's page that is rendered to html and interactive technically speaking render to the dom um quick question here who knows what the dom is see yes yes okay i guess everyone will know what the dom is does any know what the dom is okay everyone knows if you don't know where the dom is interrupt me with the audio okay so i'm just assuming you know what the dom is okay so the page here we have a simple page and here we are it's the the content of the page so they know when the text here is rendered to the html you can see it here in the html and the nice thing as well is interactive so if you click on the counter here it's updating so this is server side rendering it's a page let's run it to html plus interactive technically speaking random um why is that asset rendering i guess most of you already know that so there are two parts of it one is seo and the second is mobile performance and seo and there are several aspects to it and first only google is crawling um so if the con if the page is not rendered to html let's actually see a page that is not in sba so here we have the same demo but as an sba so it's not serviced rendered it's only reddit in the browser only to the dom so the content of the page is actually missing in the html we can see it it's not here whether whereas in the server side rendering counterpart it is rendered to the html this means that the a bot or caller will actually not see the content it will not see rendered to html you will not see demo server-side rendering and that's a problem for bots because then they will not be able to see the content of the page that said google and the google crawler does also execute the javascript of the pages so google can see the content even though the content means is hidden behind the javascript execution and but it's a flaky support and for example if you have a problem with your page it doesn't execute and then google may actually not be able to crawl the contents um also it's not always clear when google interrupts because it cannot execute javascript forever so it's not always clear for google when to stop so also this is a problem um so google may has stopped and interrupted the javascript execution and then it will not see your contents also because uh javascript javascript is expensive google delays the execution of the javascript delays the crawling of pages that um have content only shown through execution of javascript so it means if you update your website and it's not server-side rendered then google will crawl it later whereas if it's if the cone is available html it will crawl it faster so if you update your website let's say you're a newspaper and it's important for you to appear fast on google so if there's some events and you update your newspaper you add a page to the newspaper then you may want to be on top of google quickly so that when people google the new event that just happens they'll find your newspaper and for that you need server side rendering because you cannot afford yourself to have a delay in the calling if you page if your website if your newspaper is not server-side rendered google will crawl it later so you will you will appear on google's results but later um there also many other issues like this so in general um seo you can you don't have to use server-side running for it but in general it's considered recommended um so if you want to be on the safe side here you may want to do server server that's google other search engines don't uh crawl don't execute javascript at all i'm not aware of any maybe nowadays some other and search engines also execute the javascript but i'm not not aware of any so if you want to appear on bing yeah yeah research dr you know m yandex all this also search engines you need server side rendering otherwise your content will be invisible for all these search engines other aspect is social [Music] social sharing so if you share your website on twitter on facebook and the content will also invisible invisible to the crawler facebook and twitter so if when you share you have usually facebook and twitter show a little preview of your content of your website and it will not be able to do this because the content is hidden behind javascript all right so that's the seo part and the accessibility parts are the same the other part is mobile performance and [Music] executing and loading javascript on mobile is usually very slow um so the nice thing is because our content is rendered to html it will the content will be able to be shown on the mobile on the mobile devices of your users before any javascript loads and executes and this is usually drastically quicker than the mobile device loading the world our scripts and executing it for the page to become interactive it still has to load the entire javascript but to see the contents so the time the user sees the content is dramatically shortened so even though the time to interactivity is the same the time to contents it's drastically reduced so if you're a newspaper again and you usually have lots of mobile users then you may also want to do servers and rendering to so the users can quickly see video the content of your pages without having the word javascript being loaded and executed um okay so that's for the motivation um let's quickly do you have any questions and can you hear me well everyone no okay no questions yes we can hear you well okay perfect any questions it's good to me okay i hope it's not too boring i feel like you most of you already know this stuff did you already did you people already know anything i was just telling as far as we got okay seems like you are did you so you all knew about this benefits of server side rendering okay interesting we've also got a question all right i guess we you mostly all knew about it already um we got a question and about okay we'll go to the knob so that's good so you learned something someone said i guess this is also this also addresses the issue of my browser is too old to execute javascript yes as well but honestly nowadays everyone has javascript and some some people have their gyroscope disabled but that's i'd say [Music] i mean i like people who do this but i would say it's a negligible amount of people who do it so i wouldn't put it in the arguments of server side rendering because nowadays if you build a newspaper you can assume your 1999 percent of your users could be enabled but maybe in the future there will be um some changes that makes some incentives to reduce the amount of javascript being loaded in the browser let's see but we're not there yet so today the item comments for service address mostly about i would say only about seo and mobile performance okay administrations usually run on deep brothers okay fair enough i wonder how they brought the internet then because nowadays you cannot do can you improve the internet without a brother such as scripts all right let's go into how to okay this is going to be more interesting for you so who um is okay let me put the question right who has heard of it before so yes or no start yes i heard of bits before no no no yes yes okay let me if it is then good true a bit with it's a new bundler i'm not even sure how to call it actually uh it's a replacement for apec it's also partially a replacement for next years and it's also a replacement for great rec type okay let me show you a little bit so this is wit front-end tooling okay that's the proper name better than one next generation font and cooling [Music] how can i describe it with is a french in is a word in french and it means fast so fast in french is bit um and assume at the name points and he's alluding to it's really fast and let me show you how fast it is and i will also show you what it does i guess you can get started here we go let's do this is it big enough i guess maybe it's not big enough if if there's any problem like if you cannot read the terminal let me know in the audio if there's something urgent audio because i don't see the chat okay so now we just let me do it again so now we initialize we run the the boilerplate generator of it product name with project let's since direct workshop direct let's do vanilla all right let's go follow the bridge project let's go into it with project and let's look at the dependencies and we have that penalty which yes but and we have to do when deployed dependencies react and rectum all right let's look at the source code so we have a basic index.html here should be familiar to any anyone um now the interesting thing here is if you look at the script it says type module i will explain a bit why this is relevant and so this is basic html and it points to a javascript file let's look at what this javascript file does and then loads reacts and it renders renders this app component let's go into it that is the app components same some like basic contrast things again all right so just some content and a counter command here count is okay let's start the thing script yes no we have to install first [Music] if you are familiar with puzzle this is a similar developer experience you just define an index.html you point it you add a script tag pointing to some javascript and that's it let's look here we are here we are a little counter now the cool thing is we didn't do anything we didn't configure webpack and um let's also check all the source let's check everything right let's check everything so this is these are all the files and here we see there is only one with config file this is the config file that's it so here what we do we basically add a plugin that is react we add a react plugin so that bit is able to process gsx and that's the only thing we do no complicated work becomes thick the rest just works so that's really cool and the neat thing also so this is a zero config like thing and the other part that is really neat is it's fast it's bit and we can launch again um let's clear the cache it also uses the cache and that's launching the thing again bam it's ready and the page is here that's super quick i mean the same thing webpack would take a lot of time even though it's just a simple app so the magic here is because i was telling you look at this script here look at this model thing and this is one part of the magic um it ships esm code to the browser in the lazy um in a lazy manner so it only loads so here if when we load the page before we load the page we didn't transpire anything it's only when we load the page that the vid starts to transpiling code so the first thing it does is it loads this html we're seeing now then it passes the html in csr there's a script here and this is all done dynamically this is not done in a pre-optimization step this is done at runtime when we load the page so this is discover.html say okay there's a script here and only when you see this script would it load the code of sse main.js gs6 and then it will transpile it this means the bit only transpiles what it needs um and um the other part aspect of it is it's um maybe you can see it here yes we can see it so before the server starts it also has it it does a pre-optimization step it pre-bundles dependencies so here we are correct um and what it does here is it transform react is shipped as a common gs but the browser doesn't understand commonjs so what vid does is transpires it into esm um i guess everyone if someone doesn't know what the smcrc commonjs is they also interrupt me but i guess since you all know about server side rendering i guess you also know about um yeah that's with any questions about vids let me read the chats yes this is very very light i mean it feels light and also the source code is light actually the source code of it is uh quite readable um like i contributed to it many times and it's just a pleasure like um the architecture of it is quite natural and when you navigate the source code you you understand what's going on um whereas like other source codes of other will not name them but it's just a huge mess and it's just overly complicated this is lean the source code is lean and also them just the the amount of the size of the source code of it is lean and [Music] the approach is lean it's just a very really well designed piece of software it's just in many many ways a pleasure to work with not only to contribute to but also at the user to use it i don't know about the ioniq framework but many frameworks are very interested people notice that the bit is having tremendous momentum so lots of are making sure that their projects work with bits we can quickly look because i'm also curious okay february it's all it's closed i guess probably make it bigger so yeah they're working on it i mean it seems like it's not there yet so i guess it depends on this ticket which is still open but yeah um as the member of the unique framework says keep an eye for no announcements so yeah i guess also i mean most frameworks actually nowadays already work with it can we bundle a library with a bit yet [Music] i would say no i mean it just one big part also what i didn't show but this is obvious nowadays and i i don't know you can just trust me it's it does the hmr and it's hot modular replacements so if you change the file it will and also i can i can change i can show it's actually quite exciting because it's fast and that's what i want to show you okay let's okay here we are again uh count is let's change this contest and to make sure it's really hot model replacement and on full page and here we are bam i mean it's just really fast and because everything is lazy lazy done it also stays fast so if you 100 pages um it's a hot modular replacement stays fast unlike other tools out there all right let me see other questions so yeah about the library thing i would use so if it is built on top of es build which is a transpiler an extremely fast javascript and css online magnifier [Music] so this is what is is built on top of this and if you the only thing you want is to transpire code which is usually what you need for um for library so let's say you have a typescript let's say you have a node.js typescript library you don't want to force your users to use typescript so you transfer it to javascript then you would use yes build directly you don't really need bit to transpire the library so yeah i would use this building set directly there's many projects around this build and there's also yeah there's many projects around this build that do this so we'll do a little bit of research what fits your needs best and what you like most and then use this but yeah for every it doesn't makes slightly less sense how is it transpiling different from webpack okay let me answer this after reading the second question i start to work with two months ago and i use lazy loading in direct app it's very easy but kind of can't find information about prefetch i think it only works with vue at this moment what exactly do you mean with prefetch so yeah i'm not sure what you mean with prefetch maybe you can elaborate okay [Music] okay but this is exactly just what you said it's um um it has nothing to do with it it's a view thing it's also reacting um it's an orthogonal problem to it you can do lazy loading um with bits just as you can with any other frameworks or bundlers out there so yes you can do lazy lazy loading it's it's really more react thing than a bit thing okay so okay how is transpiring different from white pack so basically what i was saying was what i was saying to me the most important thing is this lazy lazy transpiling approach and webpack when you when you start so when you refresh projects and you you you want to develop it you have to build the entire application before you can get started so webpack transpires each file of your applications and also um not sure if webpack has become more clever about it but it also transpires each file of your dependencies and this is massive especially the dependencies and because your source code is usually much smaller than the amount of source code in your dependencies so this is a lot lot slower and [Music] whereas with i was like like i was showing is only as you navigate your page it transpires what your page is loading so one way to think about it is um when you and first prepare your application for development with webpack webpack transpires everything without you having loading without you having opened the browser without you having loaded any page so um first step with webpack you transpire everything then everything is available for the broader so the browser can just navigate through the transpiled test outputs vit doesn't do this which when you start when you when i run the server here yonder when i when i saw the when i started the vid server here at this point it only transpired the dependencies well it already did it that's why it's i can show you again let's remove the cache let's start server again okay here we are pre-bonding dependencies so the only thing it does is what i was saying so on the pre-bundling step we can see it here let's run again and it's not here because it does it only once why should it do it twice webpack would do it a second time actually but anyways maybe it's gotten clever a little bit more clever now um so after pre-bundling your dependencies bit doesn't transpire anything at this point the server is the dev server is run started and none of your application source code is transfiled it only transpires it when you actually load the page so first thing is you load the page the html and now at this point well it's already loaded so if it already has done is his thing but it only transpires your files as you load them in the browser so the browser goes to this your localhost part um maybe i can show you no because it's not yeah okay um with delivered.html the browser loads this html we're seeing here at this point when we delivered the html vid still didn't transfile our main gsx file and only when the browser because this is a script type module so this is a native browser or code there's nothing to do with it this is just a normal browser request to load some javascript at this point bit will receive the request to get main dust gs6 and only at this point will it transpile the code so it's lazy transpiling webpack transpires everything at the entire world before getting started with only transpires as we go does that make sense does this affect the speed of loading pages okay a good question i didn't answer that um no because in production um it actually does build the entire world so in for production when we can i can show you check the script okay let's see building for production vid is now building for production and as you can see it's transforming all the files 33 modules transforms and here what we can see is the bundles so this this what we just did here is like webpack so building the world world and this means for production it's yeah it's the same with webpack and webpack and video more this is also why for the question should i use vit for libraries my answer would be no because really written webpack are more tools for development to develop your app in production written webpack the it makes doesn't make that much of a difference sure you can bundle differently and you can code speed differently but all in all i would say it's approximately the same results so the the this folder here will be approximately the same whether it's fits in back although it does nice things for example it appends a hash that allows you to aggressively cache your assets um [Music] but yeah all in all i would say it's it's not for me it's not the reason to use it for me the the reason to use bits is the quick dev speed that is super fast and most important that say as fast as you scale i mean there's many horror stories you can read on the internet about um big applications getting so slow and then they migrated to bit and it's super fast again so not only not only is it fast but also stays fast as you scale so i would see it more as a dev tool than really a production tool does that make sense let me read the chat yes all right any other questions about bits i'm not quite curious and maybe we can do a little quick round again of um what do you want to do with server side rendering what's your use case um some of you are working for companies so maybe you can tell a little bit more about how you're using server side rendering if you're considering using server cellular rendering and how has you experienced so far um yeah this is going to be relevant for the next for the next part of the workshop like we got the question when building is there a way to remove the unique ids for the file names i guess bruce is alluding to this things um i'm not sure where you want to remove them and there's no [Music] i can't think of any reason why you would want to remove them i mean these things are really convenient because it allows you to basically tell the browser as long as you get this url you can cache it forever because this is the unique hash for the it's a contact hash so it's unique for the content of the file meaning if the file changes the url changes in the browser now there is another file to fetch here the url doesn't change um this content hash makes sure that the content of the file stays the same so the url can aggressively can cache it forever basically so so this is really convenient i don't see if you can elaborate where you want to remove this unique id for the file names yeah i will just keep it okay to have the same file names on each build and why do you want this and yes maybe maybe there's a way to do it but i i but still i would recommend to keep it less storage um i maybe you want to elaborate why storage would be a problem i think in general like images okay i'm not i didn't i'm not not maybe there's some cases where you have a lot of images and you have some caching strategies i don't know i'm not familiar with that um intuitively i would say yeah um i mean static assets in general um the expensive parts of your apps in for deployments are usually elsewhere it's rarely about static assets and but yeah maybe there's some use cases where it makes why it makes sense to remove the unique id to have some okay there's a link oh well i guess i will check it later yes and with those [Music] so yeah this is a little explanation if you want to know more about bits someone posted a link about it and explains a bit about it ah okay for the code splitting okay it is actually yeah you're right it was it is bit related and yes bit does support so how it works is when you [Music] so when you do [Music] let me show you maybe i can show you so if you do something like this and you would so basically you um do a dynamic import let's see actually if it works i'm curious so anyways when vid sees this it will code spread so yes a bit so it your euro right um code splitting and lazy loading of source code is somewhat um a bundle i think so yes and bit does support this so when this is this and it will work it will cut me you can actually quickly see the result of it [Music] the server is not run anymore let me run the server nope not working okay sorry because the export default export i mean default export uh usually we actually had a lot of problems a little bit um [Music] with esm we actually worked on the last version has a lot of improvements about this kind of esm [Music] common gs inter probability problems so okay anyways let's see if it works now yes right okay then let's know by bundle the thing and build and let's see what happens normally bits should cut split here and here we are we have let me make it bigger we have our app component and it's not bundled maybe i can also show you so you don't just believe me let's film hello bits let's look for this string hello up a little bit hello plus react let's see if it's a new area and no that's the only file who contains it so makes me think it does it's exactly what we want let's also now revert this and let's see what the next build is going to be like and now it and normally i think it should not be part of the bundle instead of being its own file and here we are i don't see it it's not in here in there let's check where it is and yes it's in the bundle yeah so it's in the bundle and so if it does support code splitting lazy loading of code with the esm dynamic imports statement all right [Music] any other question yes i mean usually you always delete the test file distribution file um yeah all right let's do this quick i want to know about use cases about service rendering um so if you could talk about bit more about your interest why are you interested in if you're already using it how are you using it i'd be really curious to know uh not too long but since we're not that many i guess we can again still spend some time on it so yeah looking forward to hear how you guys use or want to use server side rendering who wants to start we can also do an audio for this because i will probably ask questions here okay so marie is saying that your company why is your company not interested into changing because they're afraid of change what's the thing yes i guess so and the two persons in charge of making such changes are over worked and don't delegate yes make sense but you should change we're looking at it for improving mobile performance i don't know if you can hear me well um okay yeah so that would be our use case we have specific progressive web apps which we use on mobile devices our customers use on mobile devices and we want to improve it to improve the the startup performance and yeah that's why i wanted to look into it okay that makes a lot of sense and i will talk a little bit more about mobile in a moment because it's not only i also want to talk about beyond server-side rendering a little bit and you may be interested in that depending on your application this could be very very relevant for you okay anyone else okay i guess you can last chance so if you want to talk about yourself aside rendering use case i'd be very curious to know about it if someone wants to talk about it i'm here for discovering service running i don't use it yet i mean the rendering is not a silver bullet [Music] for example if you do an admin panel don't do server side rendering an admin panel is well probably never been open in a mobile device it will probably never be i mean it's it's a private thing that's not on google there's just no reason to use server-side rendering from admin panel um it's also one thing i'd like to stress like services ringing is not a silver bullet it's just one part of your tool belt that you should use um [Music] thoughtfully yes so back for back office you don't really don't need server-side rendering but i guess you're still curious about it all right anything else anyone else we are using server-side running both for performance and seo for large-scale e-commerce platforms so yeah e-commerce is typically a typical use case for service and rendering since e-commerce is highly highly sensitive to seo and e-commerce wants the best possible seo imaginable and if you want to squeeze out seo you you really want server-side rendering and also mobile and more and more people i don't have desktop devices only have mobile devices and they also do shopping on them mobile devices so yeah three comments you yeah you usually need server cellular rendering ah we also got the question what are the drawbacks of services rendering then yes like you say never use it for an admin page so yeah pages that are not supposed to be crawled on not to be shown on google results and pages that are not more so this is really type of two things it's about seo so google basically google and mobile performance that's it there's also a little bit of what i was saying with social sharing so when you share your website on twitter and facebook but there are ways to seek them to do it without service and server side rendering so let's say it's really mostly about mobile performance and google and okay so the drawbacks and the so the drawbacks and why you should not use server-side rendering then because you may think well i can just still use it anyways even though i don't need it um [Music] because i mean really depends on the application that i would say mostly two things first your pages will now not only be run on in the browser that will not only be loaded so for example let's have a look at our little demo thing this app code app.jsx code will not only be loaded and executed in a browser but also in a node.js server at runtime not necessarily a runtime by the way but i will speak about this in a moment i guess i can speak about it now so let me and i was let me show you a little server-side rented app i already broke a little demo i already wrote and then i will also speak about the drawbacks and why cyberset rendering should not be used when not needed all right this is a little demo it has three pages index spa and html only let's run the demo hope you can read the terminal actually we already saw the demo here quickly so okay let's look at this page this is physics what i was showing before this is basic server sun rendering and let's recap the content here is rendered to html and it's interactive because it's random to the dom now let's look at the source code of it okay this is the source code this code in this [Music] here it's loaded in the browser it is also it's also running to html and it's running to html by using an ogs server and there are two ways to that we so the html you see here is run run dynamically at runtime but we don't have to do that we can also pre-render it and it's a common technique and also used by next years and many frameworks it's called pre-rendering it's also commonly known as server statics static site generators so ssg and the idea here is that instead of generating this html we're seeing right now at runtime we generated at build time so let me show you okay so our little demo app has a couple of scripts and it has a build script see what happens when i run the build script so here this is bit with build with build ssr so it's building our assets and now this is the last part here the last part is not vid anymore it's with plugging ssr so this little plugin i was mentioning that i built for a bit and we can see pre-rendering html and what it does is that it renders the html at build time so when i we can have a look and here we are that's uh yeah here we go okay so this is the html this is this html this the html is living in the test file here so it means um all the html of all our pages are already rendered.html at build time and we can deploy them and when then when we deploy our app though all htmls are already already rendered and this doesn't work if we this only works if we so for some apps we don't want to do this let me show you so let's have a look at our app again now let's add a little let me check who doesn't want to do it okay let me quickly fix it because so what's the little bug in the demo um the file is the dependencies the file is typescript but i don't have typescript loaded so let me just replace the server with a non-typescript server code okay i think that should do the trick right the demo is should be working again okay so what we did here is we added a little timestamp to the to our little demo app um as we can see when we reload the page the timestamp changes and this is expected because i can we can have a quick look at the server so this is server code it's normal express um server nothing special here we integrated bits you can see here yeah here's a bit integration so we add the vid dev so in in production we also that's one maybe that's also interesting also about the question now it's different in webpack in production um bit only doesn't exist anymore in production there's not a single line of width source code in in new bundles in in production so if it is really only a div i would i would i would see it only as a dev tool and and we can see it here so this is a normal express node.js server and in production so when we're in production we don't use width but we only use we only distribute the static folder we were browsing a couple of times now so this client and when we're not in production we add the vids dev server middleware to our express app and so this means like from an architectural point of view this vid is only um express middleware so that's also there's also many cool aspects about this but anyways let's skip that part so here we add our with the server and here we add our server side of server-side rendering integration the switz plug-in ssr thing i showed you before that i wrote now the interesting thing here is when we get a request we render the page so what i want to show you here is that we render the page at request time and that's why we see the time updated here so because the html has run it at request time but when we do a when we pre-render the page the html is run at so when we run build pre-render it's rendered at build time so it means now when we [Music] check now we use a simple static server and we use this script to basically statically statically server statically serve this file that's the file we saw a couple of times now okay so these are the assets that if it's bundled transpiled and bundled and this that the html we know here here the assets and here we are seeing some the html also here there's an html so our pages this spa and html only that's only the only other pages i will show you in a moment so anyways there are html time now let's serve this folder with this client folder and app right that's because we didn't we need to rebuild the application our timestamp is missing because we were using an old build without the timestamp now let's add let's also bundle the app that has a timestamp now let's do it yourself i guess it's because of the broader side yeah it's because of the process let me show you something else so here we see what i want to show you the timestamp not changing but it's changing because the app is hydrating actually there should be an error about hydration mismatch but not showing any error which is surprising anyways let me show you something else nope uh [Music] okay so let me also show you the other pages while we added okay let's redo it and this html only page is the same page without any broader side javascript which is an interesting thing i will talk about in a moment all right now it should work now we should see the time step not updating anywhere the timestamp i'm reloading i'm not sure if you're seeing it but i'm reloading the app and the timestamp doesn't change so that's the whole idea of pre-rendering so when we generate html we can render that we can render it at request time or build time pre-rendering aka ssg is about running the entire html at build time why doing this um because of mostly because of performance and deploy strategy so the cool thing here is that when we pre-render we only have our entire app is not only static assets so here in this folder with everything we need to show the app to distributor app so we only need to distribute this this client folder to some static host like github pages cloud for pages netify etcetera etcetera so one of these many static host and we can just ship it there and it will just work so what it means is we don't need a node.js production server and that's super convenient so for example this documentation page of the plugin everything here everything you see is built at build time so this is there is no node.js server after prerendering your app is only steady it is only broader side static assets and nothing else and if we look at the source code here [Music] it's this html is static so this means that starting posts like bit of pages netify etc i only have to give them this html once and they'll be i will able to to um to uh deliver it um on the plug-in does the circuit.com http requests and there is no runtime here there is a runtime but it's only in the broader brother [Music] so pre-rendering is um super convenient to be able to deploy to study ghosts and the nice thing about static hosts is they're super cheap i mean they're free and it's really a super simple deploy strategy you don't need a node.js server production server so this drastically makes deployment drastically makes deployment simpler and there's also about performance static hosts are usually deployed static html much much faster all right so this is pre-rendering and [Music] are there any questions about pre-rendering i guess no yes yes i i asked uh what if part of the page can be pre-rendered but some other part needs to to change depending on the user is it possible to mix both because with next it's possible yes you can do this as well with the plugin um you can i mean in general i would actually you can do this but i really recommend against it because the benefits are i mean it's only uh it's only a it's like so it's a performance benefit when you do this and it means that the html that are an aesthetic don't need to be re re-rendered every time necessarily at production and this is usually a negligible cost so i wouldn't worry too much about it if i were you i think in our case it's not negligible because there are so many requests to api and this is not clean at all but it's actually very heavy to render the page each time again but we need it because the user is logged in so so you mentioned it's it's uh so you you need a lot of the computation to do this you need a lot of computation for the ipa request or the initial computation to actually render the html so do you actually need a lot of computation to to transform direct code into html or for the apis for the api requests it's a mix and it's not very well orchestrated because there are 50 developers on the same code and so in the end it's not optimized at all can you imagine but yes you can do this um basically though how you can do it you just add a little flag can i show you the command directly so this is the comment to prerender and you can just add a partial and when you add a partial it will just um [Music] pre-render the pages that can be pre-rendered and you can also you have options to opt out out of pre-rendering so you have you have full control of what pages are pre-rendered and not um great great thank you yeah okay i feel like can you also tell me like um i think i was um talking a little bit too much about something you already knew like pre-rendering i guess you already all know about this okay anyways let's skip to some more interesting parts so this is for rendering um so someone was let me check who it was um one it's also so let's go beyond ssr so 77 should be very clear to anyone now um but also i think there is more coming to server-side rendering there's for example some people working on partial hydration and the idea here is to ship so we service that rendering our entire application code is loaded and executed both in the browser and in node.js now nowadays there's efforts going in the direction of reducing only rendering on the server so not so making it that the browser doesn't load our application code but if we don't load any let me show you the problem is if we don't load any brothers at javascript then now page cannot be interactive so this is the same page and it has i can show you the source code for it so this is the what we see the file we're seeing here is the entire client-side code so the react on the page is not loaded executed rendered in the browser so it doesn't have any javascripts let me actually show you something else now the problem so yeah when i was seeing it the nice thing about um having an edge to render a page that's html only so no browser javascript is that the browser doesn't have to load any javascript so it's faster but it's not interactive all right so this is the page the our html only page and it's not interactive i'm clicking on the content here and the contact is not updating which is obvious because there's no brother side javascript the only browser side javascript here is this file the little log yeah that's the only javascript is our console the only browser side javascript is our console log and that works for some pages but that doesn't work for interactive pages so one one thing that has been that is being researched by a couple of people is to only load the code needed to make this counter interactive this is there are many approaches to it one is partial hydration so it means that instead of loading the our entire application code our entire code for this page we only load the code for the counter what this means is that the browser will load much less javascript and execute much less javascript and remember it's important for mobile so someone was saying that they use um server-side running for mobile performance and this is a very exciting this is a new exciting approaches being researched that i would keep an eye on um so and it reviews it drastically reduces the broader site which is important for mobile and also the neat thing about the plugin is that you can you can so let's imagine you have some actually i can show you let me show you so this page this is the documentation page of the plugin and let me let me show you the broader side code for it okay that's not convenient looking at all the assets that are being loaded so okay this is okay so the first um javascript browser javascript being loaded this default page client file that basically only loads this navigation client file and just a little side note it doesn't make um the files the browser script let me show you these are prefetched so for example here let me make it bigger so this asset so when i go to this page render modes page the browser first loads um this file default page client ts this javascript file this average javascript file is only an import of this other navigation client file so you may think okay but that's bad because the browser will do a request just to do another request later um and but that's not an issue because the the module is pre-loaded this navigation client file is pre-loaded here in head in the head we see [Music] module preload navigationclient.js so there's no unnecessary round trip going on here all right let's see what's in this navigation file so these are the only two files being loaded here this is only two this is the wall broader side javascript here and that's nothing i mean maybe we can look at the file so that's the entire so we are looking at the entire browser site javascript of this page that's it um so i i think this is the best mobile performance you can get period today is not having prototype javascript so you'll be saying okay but this page is not interactive but that's not entirely true it does have some interactivity um so for example here there's some interactivity a little bit of interactive there's not much interactive but there is interactivity or for example when you click here that's also enter right that's also browser javascript so there's not much interactivity but there is a little bit of interactivity um so this is a technique i call html only the idea here is that we focus on html and we only add a little bit of javascript to make it interactive so we strategically insert um some javascript snippets to support interactivity um yes let me think um yeah so typically for a website you do have some pages that are not that interactive and where you can have only a couple of javascript lines like this but some type pages that are very interactive so now what you can do with this plugin and then some speak i'm not not about this plugin i think it's in general where servers are rendering the direction where service head rendering is heading to servers i wouldn't consider server side learning only about this practice of rendering everything to the gml and running everything and handwriting everything in the channel but also in the future there will be more for example html only and also i will talk about more things going on on the right side um so but typically in an application you are some pages are not interactive some pages that are highly interactive and what you can do here is um you can render some page as spa some page has server side rendering and some pages of html only and you can pre-render some pages and some other pages yeah and not some other pages and for example i was saying that for an animated panel you shouldn't use server-side rendering but maybe your website has some microphone marketing marketing pages and an admin panel so yeah you could use next gs for the marketing pages and from create react app for your admin panel but that's not very convenient because you end up using two tools you have two interface to learn um and i don't think that's the future i think the future is really supporting all render modes i think every any framework any library any server side rendering tooling will eventually support all render modes and because it just doesn't make sense for something like this page to have to load the entire react library which is quite heavy it's like 120kb and especially for mobile for mobile you really want to minimize the amount of broadside javascripts um so i think the future here is that to mix all different render modes um yeah any questions about this feel free to uh to also audio so bachata by audio let me read the chat if i missed something so yeah but the drawbacks about servers are rendering so but i was as i was um showing with pre-rendering you don't need a node.js production server anymore um but you can also not use server rendering at all and then you also don't have to know and not just uh production server and and as amazing i was also saying that at scale it does come with cost to render your pages on the server so service that rendering is not a free thing it does have a structural cost an architectural deployment structural cost so i wouldn't really only use services rendering um only when you need it and i think the future which is already implemented by the plugin is that you can mix so your admin panel you run it as spa your marketing pages as html only or server set rendering and especially for marketing and pages i mean marketing pages they want to be first on google and google has been relentless relentless about about performance and they will count your performance into their ranking so if you have a page like this with plugins.com page that has almost no brother-side javascript it will be super fast especially on mobile and google google will thank you for it and you were wrong you will rank higher so you if you are and i actually had a user recently he had his client was not happy about um the the performance and the pagerank google's page and google's lighthouse score and what they ended up doing is actually html only so they ended up removing all the unnecessary broadside javascript they only included the browse script that's strictly strictly needed to make the page interactive and they had huge boost in night of score and also um i mean it's difficult to measure but tentatively but tentatively also and higher page rank um yes so this hybrid approach this mixing of render modes i think is the future if it's so easy why not use it everywhere i mean next just makes you think it's easy um [Music] but that was just i was saying like for example if you want with next yes if you want to have zero browser such as scripts maybe they made some changes recently i think they made some efforts in this direction for example with reg server components but still not there yet anyways so with the latest table next yes version you cannot do this so you have to load your entire page on the browser side with next years so you can you cannot go the html only direction with nextgs so and yes you can pre-render and get rid of you know production node.js server but still when you do the other drawback of server-side rendering is not only that you need a knowledge production service also that your pages are going to be run by node.js and this has many subtle consequences it means that all your code all your page code needs to be able to run on node.js it's different environment and broader in this world you will inevitably have encounter problems i mean nowadays most libraries do support servers that are rendering and they are brought for example some ray component like a collapsible element some menu elements some hamburgers some tooltip so all kinds of red components know that they are designed um to be able to be run on on node.js but still there's still problems about it so you will have problems with it you will fight with and with some libraries that have not been designed with server-side rendering in mind and it just complexifies your app so if you don't need server-side rendering you're just making something you're just complexifying the app and you will lose time on making sure that your wall code is being able to run in node.js for basically nothing and i mean financial it's just silly to have an end in panel being servers at rendered and you all you will have problems with it so yeah use only service at running when you need it and the mixing of render rendering render mods in the future okay i think that's all the questions any questions i think we are actually on time so we are on time are there any questions yes will you share the recording with us uh we gotta ask patrick i mean if i have the recording i will gladly share it yes i don't know if patrick is listening i guess not but yes if i get if i get the recording yes i will talk to patrick and i will tell you that you want to recall great and maybe one last question when when react server components are there how how do you think vit will still be necessary for the static part maybe or so vit in itself [Music] is really so it's really different two different program space rect server components and solve two different problems with direct server components you still need something that transpires your code and you still need bits you still need the dev tool you you erect some components that cannot you always need a bundler or some kind of thing that transpires for example ugs gsx code your gs6 code the browser doesn't understand it node.js the energy server doesn't understand it it needs to be transpiled you need the transpire so you need some kind of tool and that's not react server components rec doesn't do this um so you need okay so we will need less of the plugins of it but we will still need it so the question second will you still need the plugin um yes and no i mean first off first thing is direct server components is not a silver bullet either i mean it does it's super exciting and i'm super looking forward to it and the framework i'm building is going to integrate direct server components in it um but you may also not need react server components um i think we really we really of course it's complex and of course you don't want to have a billion tools in your tool belt but we still got to stop thinking that silver bullets there are usually no startup bullets and usually it's about choosing the right tool and next yes they make it seem like there's one way to do it and it's usually not the case um of course it's complex and of course we cannot expect anyone to do it the right way and of course we need some beaten path that everyone goes to by default yes but there are still thinking in terms of silver bullets is dangerous especially if you are developing big applications for large companies like le banco and you may want to have a new more nuanced approach for it if you're 50 developers actually it's everything about architecture and you may want to choose the right architecture for your app and having a nuanced view on what is the right tooling for the right job is critical and nextgs is awesome if you want to ship a little e-commerce website on the side quickly that's you can use neck chest it's fine but if you want to have if you're a company and you're growing then you you want control over your architecture and that's actually the result of the plugin is it gives you control you you have you are under control and you it gives it gives you the right level of abstraction and you don't have to do it too much manually but you do you you still have enough control to do the right decisions um still and will we still need the plugin with direct server components um one thing that direct server component so one way to think about the plugin is so the headline here is it's like next year's but i will do one thing to it well with plugin um but one other way to think about it is basically only services rendering pres but it's only a little wrapper around widths and routing so we have seen some in our demo we have several pages here we have index page html only page and sbi page we have three pages here that's something that react doesn't understand rec doesn't support the rec doesn't ship with pages it doesn't ship with rooting routing and red server components doesn't either so you need some kind of router you need some kind of routing logic you also need some kind of it's not only routing in itself there's also some logic around routing so you can think of with plugging ssr to be a thin wrapper on top of a routing [Music] yes but for rec server components the best would be we talk about it again in a couple of months and i'll show you what i've in store for it thank you very much very clear and convincing thanks any other questions uh feel free to ask any questions about the plugin also any critical question i feel like i made many mistakes in the workshop like i was talking too much about the pre-rendering part um i wish would have been in real life in a real room it would have been much easier i would have seen your reactions i would have seen that your boards are not bored but yeah a little bit tricky online like this um yeah i hope it was okay so yeah any question otherwise i'll say let's call it off okay i guess no question hope you learned something and if you want i'm going to talk about the plugin in more depth tomorrow all right and maybe maybe see you tomorrow bye you

Channel: ReactEurope

Views: 293

Keywords:

Id: RKE_GVMrl5I

Length: 93min 27sec (5607 seconds)

Published: Thu Dec 09 2021