[ramones13]

To your third point - the author would recommend doing research and prototyping with all the options you might consider based on your use-cases. He actively avoids being prescriptive in generic contexts like this because he wants to avoid arbitrary dogmatic solutions (like React tends to be).

Source: I work closely with him and have been frustrated with this stance until I saw people using Next and Remix for things like landing or contact pages.

[johnfn]

(Sorry, somewhat copying this, since I responded to a similar point elsewhere.)

This is not practical advice for the vast majority of software engineering teams.

Most teams do not have the privilege of being able to do research and prototypes across multiple options, at least in a way representative of what their final product will look like. Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you were to run 5 different prototypes on A, you're going to be a bit upset when you end up at A' and you're likely to run horribly technically aground when you truly find the right thing to build.

Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.

[ramones13]

My experiences don’t really align with yours - most people are playing “follow the leader” with tech - “X uses Y, so we should to” and that’s it.

To your point though - use the platform. Vanilla HTML, CSS, and JS. All of that will be reusable no matter where you pivot and not lock you in to a pattern that might not work well for where you land.

[johnfn]

> Vanilla HTML, CSS, and JS

This is a non-answer. It only really is an admissible solution if you're just working by yourself. React solves real problems when building web applications. If you use vanilla HTML, CSS and JS, you're going to have to solve those same problems. How are you going to do it? How are you going to manage state? How are you going to synchronize your state with the DOM? How are you going to organize your components?

Teams that use vanilla HTML, CSS, and JS end up eventually building an internal, buggy, half-implemented, undocumented version of React.

[ramones13]

I didn’t say don’t use libraries at all. There’s a wide spectrum between rolling your own everything and putting a massive abstraction layer framework between you and the platform.

[troyvit]

This is a really good article that puts very clearly some of the WTF moments I've had since having to take over a React project. However, if the title is "If not React, then what?", then the author should've answered that question.

I did find some recommendations for other reactive front-ends buried in the article, but I didn't see anything that set them apart aside from the fact that they are smaller projects. Now, if I want to follow the article's advice and get off of React I have a ton of research to do, research that the article's title didn't hint that I'd have to get going on.