Second-Guessing the Modern Web

IMO React and it's ilk are amazing in some applications but the problem is trying to make 'everything' a React/Angular/Vue app without considering scaling or how it would benefit a user. I have been tasked with building complex UX'x which would've been far simpler and performant as a multi-page type app with some plain JS sugar.I agree with wrnr - I too am leaning more towards WebComponents where some dynamic functionality is required. It provides us the ability to not only keep the tech stack small and also avoid all the dependency and version pitfalls.

Dan Abramov put up a tweet thread agreeing with this piece, and talking about how the React team is now looking at trying to come up with some server integration capabilities to enable a hybrid model for the rest of the community:

https://twitter.com/dan_abramov/status/1259614150386425858

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).

The only important question is whether this is a technology problem or a business problem. Fundamentally the problem is this:

Web developers don't know what they are doing and oversell their capabilities.

To be more clear though, this isn't a new problem, just that the symptoms of the problem have changed as the tools have evolved. I remember starting at Travelocity in 2007 and they sure as shit didn't know what they were doing either. All the JavaScript developers there, except for 1 (so about 6 of them) were spun off onto a special project that never made it to production. There was 1 guy left to write JavaScript for the rest of the site in a company who only real product was a website and employed 3500 people. All the other developers were Java people. Most of those guys were scared shitless of web technologies. There were a few Java developers who had a solid working knowledge of CSS and JavaScript but worked extraordinarily hard to keep that a secret.

That was a big WTF, but then I discovered it was also the same at both Expedia, Orbitz, and Southwest.

Now people really, and I am not being figurative, expect Angular and React to do their jobs for them from solving technical problems to telling them exact what products to build.

Worse still is when you point out the incompetence that so clear to everybody else the developers doing the work get angry. I mean hostile out to stab in you the back angry. The non-developers see the dysfunction and have absolutely no idea how to manage it or solve for it. Sometimes the dysfunction is so pronounced that it leads to inter-department warfare within the company, as was the case in one of those previously named travel companies (not Travelocity).

Here I am 13 years later working on the web that is now a 30 year old platform (20 years old if you count the modern standard web), and its still the same shit show. How have businesses allowed such cancer to prosper?

This is an absolutely perfect take on what’s wrong with front-end web right now. I've been trying, and failing, to explain this at work for several years now. Indeed, swimming against the cultural tide is hard.

React is built on two fundamental ideas that are both extremely valuable. The first and most transformative is that the web is mostly made of _components_, and specifically that organizing the markup, javascript, and CSS makes many thing easier. The second idea is that _declarative programming_ is better than imperative.

The thing is, HTML and CSS are already declarative. So React is not inventing this, nor bringing it to the web, but rather providing a pretty solid idea for how to make Javascript (or more generally, complex interactivity in the browser) declarative as well.

Thus, as MacWright argues, there is a sweet spot for React (or similar libraries) where you have highly interactive, complex UI elements on the screen.

But the rest of the web really, really doesn't need it, and when you try to apply "React Everywhere" things get very bloated, slow, and complicated, very fast. This is _especially_ true if you didn't start from scratch with Next.js or create-react-app, but are incrementally converting an established application. It's just painful.

I think more and more people are realizing this, and the fact that Dan Abramov himself agrees is pretty indicative that the tide is going to turn. But the question is, what next?

One major problem that the author didn't go into is the special pain of bundling front-ends these days. The actual work of setting up and integrating a "modern" javascript asset pipeline with a server side framework is not trivial, and I've yet to see a framework nail this. In the ones I've used there's always some gotcha - if you don't roll your own web pack (and understand what every bit of it is doing), you will eventually run into some library you want to use that just won't play nice with the rest of your bundle, and then you have a problem. And on the JS side, even simplicity-focued tools like Parcel are SPA oriented, thus gluing them together with your server-rendered app is non-trivial.

I think that will remain an issue for a while. But it also means there's an opportunity for the "old school" frameworks to keep working at this and, if they really nail the bundling and server-rendered / reactive component handoff, to thrive in the next decade of web development.