Second-Guessing the Modern Web

I'm a believer that you simply need to decide from the outset: "Is this a web app that people are going to dwell on? Are they going to stay here and use it or are they simply going to visit it?" And if yes, go all-in on treating it as a capital-a App whose "binary" consists of minified JavaScript, and if no, just stick with server-rendering. Most things fit neatly into one or the other. There's no need to shoot for the moon.

I do have to disagree with this part, though:

> The high performance parts aren’t React...The level of abstraction that React works on is too high

In my experience it's perfectly possible to write your complex, screaming-performance app in React or the like and spot-optimize it as needed. I've done that sort of thing myself. Now, something like Mapbox probably lives mostly in WebGL, which is not concerned with the DOM, so that portion isn't really relevant to React. And the question does get more complicated when it comes to shipping an embeddable widget. But at a base level, I think React and its abstractions are perfectly well-suited to high-performance apps.

XHR was invented because without it, Microsoft couldn't make a web-based email client that behaved the way users expected an email client to behave. 20 years ago. I'm not sure you can reasonably claim this stuff is not also strongly driven by the expectations of users and and the desire to meet those expectations.

As an example, the article brought up Craigslist; renowned for its brutalism. Craigslist would only be hindered by any frontend changes: arbitrary and confusing interface changes, (necessarily) slower load times, and increased complexity.

That said, I agree with the article that HTML form UX often requires more advance strategies like React and Vue. The decision requires discretion, of course.

Tools like webpack, babel, and react are also orthogonal to whether or not you're doing an SPA. These new tools aren't just to make your app a SPA, but are meant to decouple the maintainability of your code from the implementation details. React itself isn't even a framework but a paradigm which just happens to have a specific implementation that requires their runtime. The most recent shift is to turn your components into pure functions, and this is less about the framework and more about decoupling your app rendering logic from the react implementation. There's no objective argument that writing vanilla JS is better than writing modern ES next code. These language improvements are done to improve the failings of the javascript language after all.

You can totally use React to purely statically render your website. This is what most SSR implementations do, and the only reason JS is still activated is most modern apps require interactivity.

If you start doing vanilla JS and HTML you're doing a direct implementation. That's almost always the wrong way just because of browser differences between operating systems, mobile vs desktop, and all the other features that aren't really bells and whistles but more and more necessary as technology serves a bigger role. Perhaps in 1990 it's fine that a website can be made for a specific user for a specific purpose.