[grey-area]

for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time

The premise of the article is that they are not easier to work with and do not save time in most situations. I agree.

Most websites are fundamentally documents, even those that think of themselves as apps. You could even build gmail quite easily as a document based app with some limited use of fetch() or WebSockets to get the data you need, though it's one of the few applications where a less document based approach might help.

React and other js frameworks are a huge amount of overhead for very little gain if you see the web this way. Your about page is not improved by using react.

[deiznof]

>Your about page is not improved by using react.

Well...fortunately people don't use React for making About pages.

These examples of why not to use React in these comments are silly, people use them for web apps 95% of the time.

[grey-area]

I gave an example of a prominent web app I don't think needs a js framework - most web apps don't IMO as the web correctly centres the experience on documents. Games would be the obvious exception where an immersive app experience is warranted and there are no documents as such, almost every other app works with data organised into stores of documents (i.e. in gmail every email is a document and deserves its own URL IMO).

[marcosdumay]

> fortunately people don't use React for making About pages.

No, About pages are out of fashion and people don't do them in high numbers anymore. But they do use react to display news articles, web shops, and all kind of text.

[ryanbrunner]

This doesn't match my experience at all. I've seen many, many places where a bleeding-edge React stack was deployed to serve what was 100% static content.

[tpxl]

Gmail has a HTML app which requires a reload whenever you click stuff and still manages to be faster than the JS app.