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

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