I've been freelancing whilst working on some of my own projects, and have helped a devent number of clients get their front end approach cleaned up enough to work for their end-user and use case.
So when I read an article like this (which I like by the way), I make comment/response style notes to make me think through it; its long but I've dropped it in here in case anyone cares:
The issue with bundle splitting for SPA's that he mentions is a real thorn in many peoples side. A not amazing, but workable solution is to structure the site as follows:
* Split your "entry" bundle down to nothing, so it is only the map of other things that can load and a bootstrapper that looks at the URL and loads the right one.
* On the server generate html files for all your main endpoints (or hot routes for dynamic paths), ideally these are Server Side Rendered, but at a minimum they must include a script tag for both the normal entry bundle and the correct primary bundle for that page (ie, you eliminate the round trip for requesting the bundle).
The issue of running an "out of date" app is a present one. I can often restructure it to gracefully cache the state and refresh at an appropriate time without the user noticing, but it is often a far cry from simplicity.
His attack on SSR is largely correct for the way people currently deploy it, but there is nothing stopping you doing it a lot better. It is perfectly possible to generate correct HTML that works without needing to have a hydration step - its just most people aren't willing to, or knowledgeable enough to, do the work to make only the parts that need rehydration be hydrated (or, allow everything to be rehydrated but with no effect to the majority of the page). To be clear, you don't need to hydrate links, buttons, or even basic forms.
Of course, anything that genuinely requires your app js to be around to do anything reasonable needs to be there; but if you aren't looking for a drag/drop stay on page interaction you can normally just add a traditional route to allow it as well (more work of course).
He is right about API's. Though I'd hardly count it as a web or an SPA problem. Software is all about abstractions and how they are very leaky (likely "unfixably" so).
I was surprised about the data fetching comment. I've taken a look at the React docs and done some searches around the web, and he's right. Unless you know what terms to search to get the useful patterns its just a mess of amateur/broken Medium posts.
SPA's are built on top of browsers that are trying to predict where we are going and react to where we were yesterday at the same time. I'm with the author that most things don't need react, and that the things that do are mostly SPA's that have to be SPA's. I have worked with other frameworks before, but my hammer is a nodeJS & React stack I've cobbled together; thankfully its very good at SSR generating static sites, so most people don't know I'm using such a big hammer.
And we finish with a wishy washy maybe its right maybe its wrong, do we need this, maybe we do, maybe we don't.
Here is something concrete. I'm writing a small web application for my sisters business that I'm going to be doing all the legwork to see if it can grow into something. It isn't a SPA, it has some highly complex interactions, and it only uses React as a static site templating language because of my exisiting well-tooled stack (hammers make things nails).
So when I read an article like this (which I like by the way), I make comment/response style notes to make me think through it; its long but I've dropped it in here in case anyone cares:
The issue with bundle splitting for SPA's that he mentions is a real thorn in many peoples side. A not amazing, but workable solution is to structure the site as follows:
* Split your "entry" bundle down to nothing, so it is only the map of other things that can load and a bootstrapper that looks at the URL and loads the right one.
* On the server generate html files for all your main endpoints (or hot routes for dynamic paths), ideally these are Server Side Rendered, but at a minimum they must include a script tag for both the normal entry bundle and the correct primary bundle for that page (ie, you eliminate the round trip for requesting the bundle).
The issue of running an "out of date" app is a present one. I can often restructure it to gracefully cache the state and refresh at an appropriate time without the user noticing, but it is often a far cry from simplicity.
His attack on SSR is largely correct for the way people currently deploy it, but there is nothing stopping you doing it a lot better. It is perfectly possible to generate correct HTML that works without needing to have a hydration step - its just most people aren't willing to, or knowledgeable enough to, do the work to make only the parts that need rehydration be hydrated (or, allow everything to be rehydrated but with no effect to the majority of the page). To be clear, you don't need to hydrate links, buttons, or even basic forms.
Of course, anything that genuinely requires your app js to be around to do anything reasonable needs to be there; but if you aren't looking for a drag/drop stay on page interaction you can normally just add a traditional route to allow it as well (more work of course).
He is right about API's. Though I'd hardly count it as a web or an SPA problem. Software is all about abstractions and how they are very leaky (likely "unfixably" so).
I was surprised about the data fetching comment. I've taken a look at the React docs and done some searches around the web, and he's right. Unless you know what terms to search to get the useful patterns its just a mess of amateur/broken Medium posts.
SPA's are built on top of browsers that are trying to predict where we are going and react to where we were yesterday at the same time. I'm with the author that most things don't need react, and that the things that do are mostly SPA's that have to be SPA's. I have worked with other frameworks before, but my hammer is a nodeJS & React stack I've cobbled together; thankfully its very good at SSR generating static sites, so most people don't know I'm using such a big hammer.
And we finish with a wishy washy maybe its right maybe its wrong, do we need this, maybe we do, maybe we don't.
Here is something concrete. I'm writing a small web application for my sisters business that I'm going to be doing all the legwork to see if it can grow into something. It isn't a SPA, it has some highly complex interactions, and it only uses React as a static site templating language because of my exisiting well-tooled stack (hammers make things nails).