The Only Way to Eat an Elephant - Code Splitting With Server Side Rendering

Hi, my name is Lena, and today I'm here to tell you about the only way to eat an elephant. You can probably remember it's bit by bit, and I have one disclaimer to make. No, I do remember it's a React conference, but I will be telling my brief story of SSR code splitting and why you need to use them both using vanilla JS mostly.

So it all started at the time when there was no React. Someone does remember these times and someone can't even believe that there was such time when there was no React. But that time all HTML pages were served as strings. You wouldn't believe that. But the whole content was a string served from servers, and it looked something like this. One wrote for a whole HTML content and there were many of them, as much as many rows you have, and actually everybody was happy that time. It was pretty straightforward actually, until there, they were not. And you can probably guess the reason. It was because of JavaScript.

So, it became too tedious to handle all the JavaScript, all DOM manipulation with jQuery, you know, with rendering tools like EGS, handlebars, and many, many more in every server language, and also the server roundtrips made people suffer, and I can hardly tell you who suffered more, users or developers, with all their JavaScript, jQuery, and handlebars. So, JavaScript heroes came, and they decided to have SPAs, single-page applications, and and they were imagining rendering content, all the content, on the client-side and they decided that the browser can handle navigation without going back to the server and they think, they thought it was cool, and also they decided they can do client-side routing, not because it is easy, but because it is hard. But they can. And the HTML because became very small and shallow and nothing actually was rendered on server anymore. Everything was rendered in client-side with one of JavaScript frameworks.

And there became more JavaScript, more tools to build it in one bundle, and more JavaScript problems to solve, more JavaScript conference to talk about these problems and new monsters were born. Actually, more JavaScript resulted in bigger bundle sizes, which resulted in worse performance, first rendering, and everything else, and actually users started to suffer and also business started to suffer because SEO was a problem. Crawlers can't read JavaScript, they need strings. So JavaScript heroes came back again, and they decided to have SSR back, but this time was there the same JavaScript they wrote, because it was so beautiful to throw it away and they decided that the solution is to render this JavaScript they have to a string on server and to have JavaScript function returning a string. So that was a good solution for SSR and it solved SEO problem. But it didn't solve bundle size problem, right? So they were using both the same JavaScript on client side and server side. So JavaScript heroes decided so that they need to come up with an idea of code splitting. And they did. They did these dynamic imports. Here you can see that there is one problem with this code. Not because it's not in React, but because it's asynchronous. And it does solve the problem of a big JavaScript bundle. You can see that now the content is not in one bundle, but loads dynamically. But dynamic imports is for client-side and they can't be rendered on server-side because server-side needs to do it synchronously. So when your content depends on the route, meaning you need this content right away for client to see it, you can have code splitting both on server and client-side. The only problem you need to solve is to decide on the environment you're in and to load it synchronously when you are not in client-side environment and load it synchronously when you are. So this is vanilla.js solution for this problem and as much as I like vanilla.js, we all know it is It doesn't scale. It solves the problem, but it doesn't scale.