Hacker News Reader

I still can't believe that we (as a profession) kinda traded away schemas, namespaces, comments, sanity and well defined dates basically because some kids were too cool to write out closing tags. My early 20s teammate now closes blocks with } //for in his JS. That's even worse than XML!

JSON has schemas. Namespaces are simple, just add something like "namespace": "mynamespace" if you really need it. Comments are not really needed for machine readable formats and many JSON parsers allow comments if you need it for configs, so that's hardly an issue. Well defined dates are strings in ISO8601 format. It's not standardized with JSON, but not an issue I encounter on practice.

JSON itself doesn't have support for scheme of comments as far as I'm aware. Both are supported by individual rolls building on top of JSON rather than those features being part of the JSON spec.

Whether that stiffener matters to someone is up them, but that difference is what many comments on this thread are pointing out with regards to us having spent a decade rebuild many features of XML back into JSON.

XML does not have support for schemas either. XML Schemas is a separate spec (and actually not the only one, there were few competing ones).

I'd use JSON schema over XML schema any day. And I read and wrote many XML schemas and still do sometimes. JSON schema actually built by sane people. If that required a decade, so be it.

Oh that's interesting, I always thought schema names pacing was a part of the XML spec, learned something new!

Its incredible to look back at the arguments against XML and XHTML and realise just how poorly thought out they were.

Now, we've wasted the past few decades re-implementing everything that XML provided, but worse, and will spend the next few decades doing that all over again.

99% of the arguments in this industry are straw men or false equivalencies back by nothing but assertions and gut feel. There is little engineering in the field.

That's all fancy fluff. It's just optional benefit, we don't need all that in most cases. So if we add the flaws of XML into the evaluation, it naturally loses in most use cases.

Personally I just miss Dates. Even if I dont really like not having comments, it is probably for the best, force software to have proper documentation.

Maybe we need a Kotlin for XML. I mean a JSON-like, simple syntax without some of the verbosity of XML.

>but I think it's much more worthwile to dive into the particulars of why it failed

If you’re going to deep dive, define your terms: what did it fail at?

At being the future? Kind of a straw man, even if some people did argue that.

As a document interchange format? Between RSS — including podcasts! — Microsoft Office, and LibreOffice it seems to have done reasonably well.

As a data interchange format? Undoubtedly JSON is now preferred for this, but keep in mind that for several crucial years, as the “X” in “AJAX,” it paved the way for modern web apps via Google Maps, Gmail, and before that Outlook for the Web (literally the original AJAX app).

I think it’s not really interesting to examine how and where JSON displaced XML given this is not hard to grasp and well covered. Much more interesting to extract lessons that also work on JSON and predict what might displace it and where and how. For example it’s interesting that JSON is simpler than XML. Might it have discarded something valuable? The “X” is for extensibility - if we could extend JSON, which we can’t, how would we? First class date times might nice, mmm? Or to be able to add arbitrary other self describing data types? UUIDs?

What is XML still ideal for? Etc

The X in AJAX is there because the devs had to put it in MSXML, because they couldn't add it to IE itself due to a code freeze, and because XML sounded cool back then. https://web.archive.org/web/20170424220609/http://www.alexho...

While there probably were some pages using XML in AJAX, many were just sending HTML fragments.

> This was the good-old-days when critical features were crammed in just days before a release

Fascinating article, but really? I would have thought "cramming in" critical features days before release was more common these days, esp. if you're releasing/deploying to production on a daily (or even multiple-times-a-day) basis.

> esp. if you're releasing/deploying to production on a daily (or even multiple-times-a-day) basis.

What does releasing regularly have to do with cramming stuff in? We release when stuff is ready. That could be multiple times a day or once a week.

I think of people with set release dates as the most likely candidates of "cramming stuff in" because they fear they will miss the release and it might be a month (or worse) before the next release

Hence the quotes around "cramming" - it's now standard practice for the commits for a new feature to be merged into the mainline days before building a release. I can't say I ever remember doing that 20 years ago - there was always a code freeze period reserved for critical bug fixes.

> what did it fail at?

To stay. Yes, it's still used. But which new projects are still using XML? Most usage now are remnants from the golden age. Others are old companies who build their culture with XML, and continue to use it, but that's it. XML is not growing anymore, and slowly dying. It's quite like RSS, not dead yet, but not prospering either.

To offer a different perspective: I find XML simpler in that it tends to correspond more closely to most arbitrary data models. From ADTs to C structures, there are product types and sum types to encode, along with more or less arbitrary basic types, which have text representation. With XML you get a straightforward way to encode all those, while in JSON there is no single agreed upon method to encode sum types, but you get something like string-indexed arrays (or hash tables) instead, which are normally implemented on top, using simpler types (and are not restricted to strings). And a few arbitrary built-in types, but you have to use strings for others anyway. And no built-in extensibility, so ad hoc hacks are used when it is needed. It would be particularly awkward to use for documents, too.

I preferred JSON initially myself, since it seemed a little less verbose, I did not care about extensibility, did not consider its usage for documents, validation, did not care about using it for different data models, and it just seemed simple (FSVO) and straightforward. But then more of XML made sense. It is not perfect for everything, either, but the decisions behind it seem more justified to me than those behind JSON (though JSON still fits JS, at least).

I disagree. XML isn't that complex. I think it failed because:

* It's overly verbose. All those closing tags, ugh.

* The data model is not actually what people want most of the time. People are transferring objects, not documents. The fact that XML doesn't have a proper way to represent maps, and you have the redundancy of attributes, inline text, etc... There's a huge mismatch between the data model of XML and the data model that people usually want.

* SAX is obviously a shit way to do parsing. There were DOM parsers and pull parsers but for some reason SAX was stupidly common despite being stupidly awkward.

SAX parsers are quick and easy which probably explains their prevalence.

> With XML, it failed because something like JSON was much simpler.

I remember when XML was pretty new and I used this new-fangled technology called XML-RPC. XML-RPC was amazing and I was using it to connect desktop applications to web applications. If you go look it up, you'll notice that bears a striking resemblance to JSON.

But what technology actually took off for RPC in XML? SOAP. And SOAP is a nightmare of complexity and hardly works right the first time between heterogeneous systems.

It's funny how much people want to add complexity to the JSON ecosystems with the same over-engineering that killed XML in the same space. Luckily the design of JSON is such that it resists that kind of complexity and also because XML exists it takes a bit of that load.

Adobe Flex front end connected via xml-rpc to a python backend was my favourite way of whipping up personal desktop utils back in the day.

XML can be simpler. In C# you could generate an XSD from a good XML example, then fix it up and generated typed, nested C# code. You now have a builder and validator for the stuff you send across the wire.

You can sort of do the same with JSON though to be fair, in theory, and there are probably tools, but it wouldn't be as tight and then the "XSD" part I am not sure if there is a single spec to go with.

Overall though, I prefer JSONland!

We use XSDs to generate JSON Schemas. The schema converter also generates code to convert JSON files to XML, so we can use our existing XML infra while we migrate.

As you say both can be used to validate input and to generate typed code.

However I find the XSD design tools better, so I expect we'll be doing the XSD first approach even after all our integrations are JSON native unless something radical changes there.

IMO XML failed because of mismatch between programming language structures and storage format. JSON is perfect because it maps 1:1 to arrays and objects. XML does not. There were whole ORM projects to map XML to data structures.

That's a fundamental issue and replacing XML was not that hard.

My prediction is that SQL will fail too. There are infinite attempts to dethrone it. And the reason is the same: tabular data does not map well to our data structures.

Dethroning SQL much harder, though. It'll take decades.

We introduced fundamental roadblocks into IT and river of time will either break those roadblocks or smooth them into shapes hardly recognizable (SQL + JSON, for example).

SQL is a pretty decent language. Sure it could be improved and made more intuitive and maybe even simpler. Relational data maps directly to objects if you have halfway decent tooling. SQL is almost 50 years old now - it'll be here for a long time because it is actually useful paradigm that has not been outdone by other paradigms (so far).

> My prediction is that SQL will fail too. There are infinite attempts to dethrone it. And the reason is the same: tabular data does not map well to our data structures.

I'm deeply skeptical.

The relational data model is fundamentally about correctly representing relationships between data. Whereas data structures are about efficiently using computer hardware to perform computation on that data.

I don't see either going away, because they're driven by fundamental needs.

To dethrone SQL, you won't cut it with just average techbro hype. You need the top award of SIGMOD renamed in honor of your paradigm's inventor levels of hype.

> My prediction is that SQL will fail too...And the reason is the same: tabular data does not map well to our data structures.

The whole point of SQL is that relations and relational data are not data structures. They are higher level concepts and data structures are implementation details. The reason it has survived 4+ decades is because it isn't intrinsically tied to those implementation details and instead can be reimplemented over and over and over.

> There are infinite attempts to dethrone it.

Viewed another way, there are infinite attempts to reinvent it, all of which keep failing, because they aren't as good.

> Dethroning SQL much harder, though. It'll take decades.

Maybe not decades. I personally love EdgeDB (https://www.edgedb.com/) as an SQL replacement.

> The XML ecosystem with things like XSLT, Xquery,etc, were elegant, but also overengineered and clunk

Hell those were the better XML standards. Just consider SOAP, SAML (XMLSignature is insane), etc

XML just another example that unnecessary complexity is the worst sin in software development

SOAP still has a special place in my heart where only hate exists.

> With XML, it failed because something like JSON was much simpler.

No. XML was introduced as a simplified SGML subset/profile to become the base for new markup vocabularies on the web; both SVG and MathML were specified using XML (and later integrated into HTML 5). The intent was also to replace HTML by XHTML.

The idea to introduce service payloads as custom, non-UI XML and then transform those payloads into XHTML was induced by XML, but distinct from it.

However, W3C went crazy with SOAP and XML (and RDF), attempting to establish entirely new and unproven paradigms such as XForms with XHTML2 rather than merely simplifying syntax, which was bound to fail, and laid ground for browser vendors to evolve HTML outside W3C.

Then XML heads somehow felt insulted, refused to change course or learn new things. Most even didn't realize XML is just an SGML subset, and that everything that was possible using XML is by definition also possible using SGML (plus handling HTML and markdown and a couple other things making SGML more complex compared to XML). To this day, we're hearing XML heads dogmatically advertising their overly strict and verbose red-headed stepchild of a markup language, and wondering why nobody wanted to bow to XML. The article is about this kind of people who want to use their tool under all circumstances, project requirements be damned.

Stuff like GRPC / GQL feels cool, but JSON still feels "closer to the wire" and easier to work with using normal text-based tools / curl / etc. The internet felt like magic growing up once I learned about SMTP and HTTP using telnet and played with quite a few serial terminal devices. Now with many APIs behind OAuth or worse, it's getting much less trivial to hack around with in simple ways.

> Stuff like GRPC / GQL feels cool, but JSON still feels "closer to the wire"

This is like comparing a Mustang engine to a racetrack. They're not even equivalent technologies.

GRPC and GraphQL would equate to SOAP, REST or some other interface protocol. JSON equates to protobuf, XML or another transport format. Of those three options, I have no idea how JSON would be considered the "closest to the wire". Protobuf is definitely the lowest level, while XML and JSON are about equivalent in abstraction.

And specifically XHTML failed for two reasons: (0) Internet Explorer did not support it, and (1) there was no good migration path out of tooling that generated HTML by unrigorous string concatenation.

So instead WHATWG created HTML5, which bastardized well-designed (if clunky to use) XML features like namespaces, paving the way for vulnerabilities like CVE-2020-26870.