React and its ilk were designed for use in apps, where there are meaningful advantages in powering things entirely with client-side scripting rather than generating server-side HTML and possibly enhancing it on the client side with scripting.
They were then abused by increasingly many people for rendering static content, things like blogs.
These people were using the wrong tool for the job, and it has had a detrimental effect on the web.
Now, pages are regularly far heavier than before with expensive client-side code to do stuff that should have been done server-side in almost all cases, and it became popular enough that search engines eventually had to cave and introduce a full JavaScript execution environment in their indexers, tooling everywhere got a lot more complicated, and the last state of the web was worse than the first.
There is a place for things like React: in rich apps, and perhaps even for server-side rendering, though I’m not fond of that for things like blogs because it encourages you to end up depending on it on the client side too.
But client-side JavaScript app frameworks made some formerly-impossible things possible, and formerly-complex-and-unmaintainable things tractable.
This monstrosity, on the other hand, offers no actual benefits for the user, and does introduce a few new problems (quirks mode for styling, and an unnecessary dependency on JavaScript). And so I say it should never be exposed to the client side. Use it as an input format for your blog generator if you like, but don’t try shipping a wonky JSON/HTML polyglot directly.
Look. We're on a Show HN. You call his work a monstrosity with no benefits for the user. You call it an abomination. When you've used up all your insults, what's left? What are you going to call something deserving of hate? It's so petty and bitter, and you need to go have fun with something. Go play!
As for your React commentary, it's 4:42am my friend, and I was just sad to see someone take such a hot steamy dump on someone's work on a Show HN thread without a single other person standing up for them. But all of your points about React can be summed up as "well, yes, that's what happens when something is successful: history is rewritten to make it seem like it had a place from the beginning."
If someone was like "Show HN: React - a new way to write websites," it feels like a guarantee you'd be right there like "But it breaks when you turn off Javascript!" Meanwhile, even Tor admitted defeat long ago and enabled JS by default.
I’m specifically objecting because of the text “I'm creating a blog platform using this concept” and what else the author is saying here. As a technical demonstration, it’s fine—various people don’t realise you can do things like this, and I’m all in favour of showing people these sorts of things, as it does get people thinking in interesting ways. But the author seems to think that this is a good idea, which I’m afraid it’s just not, so I can’t mince words—though perhaps I have expressed myself a bit more strongly than is seemly (thank you for pulling me up on that).
Of React (and its ilk: React was by no means the first project along these lines; as an example, I can think of having hit a couple of full JS-required Knockout sites well before React was a thing, where they would have been better as prerendered HTML), I’m not saying that history was rewritten to say it had a place from the beginning, but rather that there was a place for it from the beginning: that there is a certain type of app where there are very substantial benefits for the user in doing at least some parts on the client side (that was where the jQuery style of progressive enhancement started, and then things like Backbone steadily expanded it), and then that architecturally there are substantial benefits to going all in on client-side rendering if you need this sort of enhancement (this was what Knockout tended towards, and what ExtJS and React more fully realised)—but that this had costs, too, in that it broke the traditional model, making life harder for all kinds of tooling and making pages heavier, so that it shouldn’t be used everywhere.
React was not initially intended as a way to write web sites, but rather web apps. It’s an important distinction. For apps like Facebook and Twitter, the advantages of server-side rendering were not so applicable, and the benefits of full client-side rendering more marked. Unfortunately, the SPA craze grew further, and people liked using one tool everywhere, and so it became more and more common to use React in places where it was inappropriate at the time; until finally tooling like search engines caved on the whole JavaScript thing.
I still don’t like how often I find normal websites depending on JavaScript for fundamental rendering (it may not surprise you to discover that I browse with JavaScript disabled by default—mostly for performance and minimisation of annoyances), but at least React has purpose and some advantages, and has done from the start.
Meanwhile, this thing here doesn’t get you any of the benefits of client-side rendering (things like lighter and faster subsequent page loads and transitions, by using AJAX and semantic knowledge), but does carry all of the costs of client-side rendering: poorer performance, and making life harder for tooling of all kinds.
React and its ilk were designed for use in apps, where there are meaningful advantages in powering things entirely with client-side scripting rather than generating server-side HTML and possibly enhancing it on the client side with scripting.
They were then abused by increasingly many people for rendering static content, things like blogs.
These people were using the wrong tool for the job, and it has had a detrimental effect on the web.
Now, pages are regularly far heavier than before with expensive client-side code to do stuff that should have been done server-side in almost all cases, and it became popular enough that search engines eventually had to cave and introduce a full JavaScript execution environment in their indexers, tooling everywhere got a lot more complicated, and the last state of the web was worse than the first.
There is a place for things like React: in rich apps, and perhaps even for server-side rendering, though I’m not fond of that for things like blogs because it encourages you to end up depending on it on the client side too.
But client-side JavaScript app frameworks made some formerly-impossible things possible, and formerly-complex-and-unmaintainable things tractable.
This monstrosity, on the other hand, offers no actual benefits for the user, and does introduce a few new problems (quirks mode for styling, and an unnecessary dependency on JavaScript). And so I say it should never be exposed to the client side. Use it as an input format for your blog generator if you like, but don’t try shipping a wonky JSON/HTML polyglot directly.