Hacker News Reader

Comment by _heimdall | Hacker News Reader

Its not just you. I think web development would be in a much nicer place today if we spent the last 20 years improving XML and XSLT rather than abandoning it for JSON and client-side JS.

People are starting to realize that most sites really boil down to parsing server state and rendering DOM. We never needed to do all this nonsense with serializing all state to JSON and shipping the entire rendering pipeline to the browser, that was just a heavy handed solution for a very specific scaling issue at Facebook.

View on HN

I want to believe in the cycle: "From telnet to static web to dynamic web to clientside rendered to serverside rendered to telnet."

Just as a thought exercise, if XML had been the de facto interchange format, how much would that have added to the historical bandwidth transfer of the Internet? Even 1 KB added to every AJAX call would add up pretty significantly pretty fast, I'd imagine...

Obviously JSON isn't well optimized either but I wonder how much, if any, progress might have been slowed by XML syntax clogging the pipes even more.

Resource requirements expand until it they hit a user-noticable limit. Even ultra-compressed every-bit-counts encodings[0] would be ignored and abused until they're bloated to a user-noticable limit. Or the extra bandwidth would be used for more video ads.

> how much, if any, progress might have been slowed by XML syntax clogging the pipes even more.

Depends what you mean by "progress", and if you think Web development has been improving or devolving over time.

[0]https://www.microsoft.com/en-us/research/publication/functio...

I feel like most web applications today make hundreds of HTTP requests when opening them. If that's acceptable, then XML vs. JSON doesn't matter.

XML is definitely more verbose than JSON, though I'd be very surprised if an average content-heavy site would be smaller with something like JSON + react. I'd be surprised if server components tipped the scales either given that the server state would still be shipped as HTML and/or a virtual dom representation.

FastInfoSet enters the chat

I.e., you can have XML and have it be compact by serializing it to something very close to ASN.1's PER (packed encoding rules).

Ditto for JSON, though there's lots of competing binary JSON schemes out there.

With compression a lot of the verboseness of XML disappears. And the vast majority of the data "clogging the pipes" is video and images.

jq is to JSON as XSLT/XPath is to XML.

Maybe any time we create a new serialization scheme we should create an ETL for it.

Or maybe we shouldn't create new serialization schemes all the time. Here's just a few of them, and that's rather many: https://en.wikipedia.org/wiki/Comparison_of_data-serializati...

Maybe we should require licensure for creating new serialization schemes :)

Reply on news.ycombinator.com