This is just a bad idea. Apart from abusing browser rendering quirks (which is unfortunately a sad tradition of the web, something that has claimed the life of entire technology stacks like xml/xhtml), it removes any hope of producing webpages accessible from screen readers and similar. In comparison, JS-only pages look like model citizens. This is the equivalent of abusing IE hot-comments and other CSS-parsing bugs to style your website, but worse (at least that technique was useful).

I think the difference is that nothing in React is abusing fault tolerance in a browser to the extent that this is. This very specifically works only because browsers don't generally care that an HTML page is anything close to valid HTML. There's no guarantee at all that this will continue to be the case, and it's resonable to assume that some browser in the future might decide to do render things that are very clearly a JSON document as a JSON document instead - fundamentally breaking the core architecture of your system.

React is a different approach, but it plays by the rules and doesn't serve invalid HTML or Javascript.

The primary reason for calling it an abomination is that if they actually plan on having this used (especially if by other people) it will spectacularly break the moment Chrome decides to make their quirks mode more strict.

It's a fun hack, although not exactly very unique. See also the very old by now "Website in a PNG file" concept, which does the exact same thing: https://gist.github.com/gasman/2560551

I’m going to double down here.

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.

I agree with you. People should just explore the possibilities that exist to the fullest, harmless extent. There's no harm in this. Along the way, they might find something entirely new. Blocking off that path with "don't ever do this" is just closed-minded.

It's a good thing people exist that aren't deterred by gatekeeping comments like these and actually try to innovate or simply play around and have fun with programming.

But what do you think one gains by serving json instead of serving valid html like a body with just `<data src="actual.json"></data>`?

If you can retain full functionality (and hack on your ideas) AND be standards compliant (to make sure someone who decides to start offering a new web browser doesn't have to worry about 10% of websites serving this instead of valid HTML), then you should do that.

You're both right. Suggesting other people try your blog built on this platform is giving people bad advice, and the comment you're replying to is overly negative.

I think the thing that's annoying is trying to sell other people on using such a tool. Anyone crazy enough to try it should jump right in, but don't try to talk people into it as an actual good blog option.

I call this sort of project "linux on a wristwatch." It's totally cool and a fun hack, but there's no real utility to it beyond an art piece.

Can’t you put the render at the top and the script can block before anything else to make sure a) it always executes and b) removes all the json content from the page.

Or actually, you can probably just put some closing angles before the start of your render to make sure you don’t get broken from above. Little sketchy though.

Quirks mode is not the only problem of this approach.

It may not significantly affect users of modern browsers in their default configuration with good internet connections, but it does affect plenty of other things.

You want to parse things in the document? Now you need a whole different suite of tools from the usual tools you use. Your library that parses all the meta tags, identifies the content, &c. is now useless. Now you need either a full JavaScript execution environment, or a JSON parser instead of an HTML parser (and that JSON has completely lost the semantics that HTML provides, so you can’t query things like “document title” or “meta description”).

You have JavaScript disabled? Here, have a mess that, well, it’s better than most client-side rendering things in that the content is still probably there, rather than the screen just being blank, but there are reasons why you should always prefer server-side rendering for things like blogs.

You have a slow or unreliable internet connection? Now the page is taking longer to load, and until the JavaScript loads, the page is empty—and it may fail to load.

I object to people doing things like this as more than a fun technical demonstration because it does harm some users.

Maybe browsers should artifically delay the rendering of pages in the quirks-mode to create incentive for website creators to use proper formats/techniques.

I can imagine the author had their fun, I also had fun reading the article, but I don't think this is leading to an accessible internet.

You know, if we could just go back and make that un-happen, we probably would have built an actual internet application platform. That probably would have been a lot better than the layers of hackery that we deal with now, but ok, that's pure speculation.

No, please read my other comments here—the point is that this thing doesn’t solve anything, but introduces various problems.

The only tenuous claim it can have is that the document is JSON, so if you want to parse the data, maybe you’ll find it easier? But in practice this is not useful: you can already embed or link to a JSON representation in the HTML, and that JSON representation then won’t be constrained by having to embed the renderer, either.

Not all inventions are useful.