6 ms·

I'm aware I'm in a minority, but I find it sad that XSLT stalled and is mostly dead in the market. The amount of effort put into replicating most the XML+XPath+

by eftpotrm 10mo ago

I'm aware I'm in a minority, but I find it sad that XSLT stalled and is mostly dead in the market. The amount of effort put into replicating most the XML+XPath+XSLT ecosystem we had as open standards 25 years ago using ever-changing libraries with their own host of incompatible limitations, rather than improving what we already had, has been a colossal waste of talent. Was SOAP a bad system that misunderstood HTTP while being vastly overarchitected for most of its use cases? Yes. Could overuse of XML schemas render your documents unreadable and overcomplex to work with? Of course. Were early XML libraries well designed around the reality of existing programming languages? No. But also was JSON's early implementation of 'you can just eval() it into memory' ever good engineering? No, and by the time you've written a JSON parser that beats that you could've equally produced an equally improved XML system while retaining the much greater functionality it already had. RIP a good tech killed by committees overembellishing it and engineers failing to recognise what they already had over the high of building something else.

VMG 10mo ago
> by the time you've written a JSON parser that beats that you could've equally produced an equally improved XML system while retaining the much greater functionality it already had. Here is where you lose me The JSON spec fits on two screen pages https://www.json.org/json-en.html https://www.json.org/json-en.html The XML spec is a book https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/
- geocar 10mo ago
  > The JSON spec fits on two screen pages https://www.json.org/json-en.html https://www.json.org/json-en.html It absolutely does not. From the very first paragraph: It is based on a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999. which is absolutely a book you can download and read here: https://ecma-international.org/publications-and-standards/standards/ecma-262/ https://ecma-international.org/publications-and-standards/st... Furthermore, JSON has so many dangerously-incompatible implementations the errata for JSON implementations fills in multiple books, such as advice to "always" treat numbers as strings, popular datetime "extensions" that know nothing of timezones and so on. > The XML spec is a book https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/ Yes, but that's also everything you need to know in order to understand XML, and my experience implementing API is that every XML implementation is obviously-correct, because anyone making a serious XML implementation has demonstrated the attention-span to read a book, while every JSON implementation is going to have some fucking weird-thing I'm going to have to experiment with, because the author thought they could "get the gist" from reading two pages on a blog.
  - VMG 10mo ago
    The "References" section of the XML spec is almost longer than the JSON spec itself > [...] serious XML implementation [...] You are cherry-picking here
  - MrJohz 10mo ago
    I think you are misreading the phrase "based on". The author, I believe, intends it to mean something like "descends from", "has its origins in", or "is similar to" and not that the ECMAScript 262 spec needs to be understood as a prerequisite for implementing a JSON parser. Indeed, IIRC the JSON spec defined there differs in a handful of respects from how JavaScript would parse the same object, although these might since have been cleaned up elsewhere. JSON as a standalone language requires only the information written on that page.
    - geocar 10mo ago
      > JSON as a standalone language requires only the information written on that page. JSON.parse("{\"a\":9999999999999999.0}") Either no browsers implement JSON as written on that page, or you need to read ECMAScript-262 to understand what is going on.
      - MrJohz 10mo ago
        Well yes, if you're writing a JSON parser in a language based on ECMAScript-262, then you will need to understand ECMAScript-262 as well as the specification for the language you're working with. The same would also apply if you were writing an XML parser in a language based on ECMAScript-262. If you write a JSON parser in Python, say, then you will need to understand how Python works instead. In other words, I think you are confusing "json, the specified format" and "the JSON.parse function as specified by ECMAScript-262". These are two different things.
        geocar 10mo ago
        > The same would also apply if you were writing an XML parser in a language based on ECMAScript-262. Thankfully XML specifies what a number is and anything that gets this wrong is not implementing XML. Very simple. No wonder I have less problems with people who implement XML. > In other words, I think you are confusing "json, the specified format" and "the JSON.parse function as specified by ECMAScript-262". These are two different things. I'm glad you noticed that after it was pointed out to you. The implications of JSON.parse() not being an implementation of JSON are serious though: If none of the browser vendors can get two pages right, what hope does anyone else have? I do prefer to think of them as the same thing, and JSON as more complicated than two pages, because this is a real thing I have to contend with: the number of developers who do not seem to understand JSON is much much more complicated than they think.
- eftpotrm 10mo ago
  Aside from the other commenter's point about this being a misleading comparison, you didn't need to reinvent the whole XML ecosystem from scratch, it was already there and functional. One of the big claims I've seen for JSON though is that it has array support, which XML doesn't. And which is correct as far as it goes, but also it would have been far from impossible to code up a serializer/deserializer that let you treat a collection of identically typed XML nodes as an array. Heck, for all I know it exists, it's not conceptually difficult.
  - vbezhenar 10mo ago
    You need to distinguish between the following cases: `{}`, `{a: []}`, `{a:[1]}`, `{a:[1, 2]}`, `{a: 1}`. It is impossible to express in XML in an universal way.
    - Mikhail_Edoshin 10mo ago
      XML is not a data serialisation tool, it is a language tool. It creates notations abd should be used to create phrase-like structures. So if a user needs these distinctions, he makes a notation that expresses them.
      - vbezhenar 10mo ago
        JSON is immediately usable without any notations. Basically the difference is that underlying data structures are different. JSON supports arrays of arbitrary items and dictionaries with string keys and arbitrary values. It aligns well with commonly used data structures. XML node supports dictionary with string keys and string values (attributes), one dedicated string attribute (name), array of nodes (child nodes). This is very unusual structure and requires dedicated effort to map to programming language objects and structures. There were even so-called "OXM" frameworks (Object-XML Mapper), similarly to ORM. Of course in the end it is possible to build a mapping between array, dictionary and DOM. But JSON is much more natural fit.
        Mikhail_Edoshin 10mo ago
- josefx 10mo ago
  > The JSON spec fits on two screen pages https://www.json.org/json-en.html https://www.json.org/json-en.html The beloved minimalist spec. . No way anything could be wrong with that: https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html Turns out there are at least half a dozen more specs. trying and failing to clarify that mess.
- Mikhail_Edoshin 10mo ago
  But the part of XML that is equivalent to JSON is basically five special symbols: angle brackets, quotes and ampersand. Syntax-wise this is less than JSON (and it even has two kinds of quotes). All the rest are extras: grammar, inclusion of external files (with name and position based addressing), things like element IDs and references, or a way to formally indicate that contents of an element are written in some other notation (e. g. "markdown").
deleted 10mo ago
[deleted]
theoryaway 10mo ago
> RIP a good tech killed by committees overembellishing it and engineers failing to recognise what they already had over the high of building something else. Hope I can quote it to Transofrmer architecture One day
jeltz 10mo ago
There are still virtually zero good XML parsers but plenty of good JSON parsers so I do not buy your assertion. Writing a good JSON parser can be done by most good engineers, but I have yet to use a good XML parser. This is based on my personal experience of having to parse XML in Ruby, Perl, Python, Java and Kotlin. It is a pain every time and I have run into parser bugs at least twice in my career while I have never experience a bug in a JSON parser. Implementing a JSON parser correctly is way simpler. And they are also generally more user friendly.
- gwbas1c 10mo ago
  Take a look at C# / dotnet. The XML parser that's been around since the early 2000s is awesome, but the JSON libraries are just okay. The official JSON library leaves so much to be desired that the older, 3rd party library is often better.
  - nflekkhnnn 10mo ago
    The old and new json lib is written by the same person. The newer one is a bit more low-level — that’s intentional, the old one was too bloated.
    - gwbas1c 10mo ago
      Oooh, then it makes sense why there isn't a good set of layers: XmlReader -> (XmlDocument or XmlSerializer) generally hits all use cases for serialization well. XmlReader is super-low-level streaming, when you need it. XmlDocument is great when you need to reason with Xml as the data structure, and XmlSerializer quickly translates between Xml and data structures as object serialization. There's a few default options that are wrong; but overall the API is well thought out. In Newtonsoft I couldn't find a low level JsonReader; then in System.Text.Json I couldn't find an equivalent of mutable JObject. Both are great libraries, but they aren't comprehensive like System.Text.Json.
- taeric 10mo ago
  JSON parsing is pretty much guaranteed to be a nightmare if you try and use the numeric types. Or if you repeat keys. Neither of which are uncommon things to do. My favorite is when people start reimplementing schema ideas in json. Or, worse, namespaces. Good luck with that.
klodolph 10mo ago
Having used XSLT, I remember hating it with the passion of a thousand suns. Maybe we could have improved what we had, but anything I wanted to do was better done somehow else. I'm glad to have all sorts of specialists on our team, like DBAs, security engineers, and QA. But we had XSLT specialists, and I thought it was just a waste of effort.
gwbas1c 10mo ago
IMO, XSLT seems like something that should be handled on the server, not in the browser.
immibis 10mo ago
Not the minority. People can be sad that XSLT failed and also recognize that removing it from browsers is quite sensible, given the current situation.
altmind 10mo ago
You can do some cool stuff, like serving an RSS file that is also styled/rendered in the browser. A great loss for the 2010 idea of semantic web. One corporation is unhappy because it does not cover their use cases

VMG 10mo ago

> by the time you've written a JSON parser that beats that you could've equally produced an equally improved XML system while retaining the much greater functionality it already had. Here is where you lose me The JSON spec fits on two screen pages https://www.json.org/json-en.html https://www.json.org/json-en.html The XML spec is a book https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/

geocar 10mo ago
> The JSON spec fits on two screen pages https://www.json.org/json-en.html https://www.json.org/json-en.html It absolutely does not. From the very first paragraph: It is based on a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999. which is absolutely a book you can download and read here: https://ecma-international.org/publications-and-standards/standards/ecma-262/ https://ecma-international.org/publications-and-standards/st... Furthermore, JSON has so many dangerously-incompatible implementations the errata for JSON implementations fills in multiple books, such as advice to "always" treat numbers as strings, popular datetime "extensions" that know nothing of timezones and so on. > The XML spec is a book https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/ Yes, but that's also everything you need to know in order to understand XML, and my experience implementing API is that every XML implementation is obviously-correct, because anyone making a serious XML implementation has demonstrated the attention-span to read a book, while every JSON implementation is going to have some fucking weird-thing I'm going to have to experiment with, because the author thought they could "get the gist" from reading two pages on a blog.
- VMG 10mo ago
  The "References" section of the XML spec is almost longer than the JSON spec itself > [...] serious XML implementation [...] You are cherry-picking here
- MrJohz 10mo ago
  I think you are misreading the phrase "based on". The author, I believe, intends it to mean something like "descends from", "has its origins in", or "is similar to" and not that the ECMAScript 262 spec needs to be understood as a prerequisite for implementing a JSON parser. Indeed, IIRC the JSON spec defined there differs in a handful of respects from how JavaScript would parse the same object, although these might since have been cleaned up elsewhere. JSON as a standalone language requires only the information written on that page.
  - geocar 10mo ago
    > JSON as a standalone language requires only the information written on that page. JSON.parse("{\"a\":9999999999999999.0}") Either no browsers implement JSON as written on that page, or you need to read ECMAScript-262 to understand what is going on.
    - MrJohz 10mo ago
      Well yes, if you're writing a JSON parser in a language based on ECMAScript-262, then you will need to understand ECMAScript-262 as well as the specification for the language you're working with. The same would also apply if you were writing an XML parser in a language based on ECMAScript-262. If you write a JSON parser in Python, say, then you will need to understand how Python works instead. In other words, I think you are confusing "json, the specified format" and "the JSON.parse function as specified by ECMAScript-262". These are two different things.
      - geocar 10mo ago
        > The same would also apply if you were writing an XML parser in a language based on ECMAScript-262. Thankfully XML specifies what a number is and anything that gets this wrong is not implementing XML. Very simple. No wonder I have less problems with people who implement XML. > In other words, I think you are confusing "json, the specified format" and "the JSON.parse function as specified by ECMAScript-262". These are two different things. I'm glad you noticed that after it was pointed out to you. The implications of JSON.parse() not being an implementation of JSON are serious though: If none of the browser vendors can get two pages right, what hope does anyone else have? I do prefer to think of them as the same thing, and JSON as more complicated than two pages, because this is a real thing I have to contend with: the number of developers who do not seem to understand JSON is much much more complicated than they think.
eftpotrm 10mo ago
Aside from the other commenter's point about this being a misleading comparison, you didn't need to reinvent the whole XML ecosystem from scratch, it was already there and functional. One of the big claims I've seen for JSON though is that it has array support, which XML doesn't. And which is correct as far as it goes, but also it would have been far from impossible to code up a serializer/deserializer that let you treat a collection of identically typed XML nodes as an array. Heck, for all I know it exists, it's not conceptually difficult.
- vbezhenar 10mo ago
  You need to distinguish between the following cases: `{}`, `{a: []}`, `{a:[1]}`, `{a:[1, 2]}`, `{a: 1}`. It is impossible to express in XML in an universal way.
  - Mikhail_Edoshin 10mo ago
    XML is not a data serialisation tool, it is a language tool. It creates notations abd should be used to create phrase-like structures. So if a user needs these distinctions, he makes a notation that expresses them.
    - vbezhenar 10mo ago
      JSON is immediately usable without any notations. Basically the difference is that underlying data structures are different. JSON supports arrays of arbitrary items and dictionaries with string keys and arbitrary values. It aligns well with commonly used data structures. XML node supports dictionary with string keys and string values (attributes), one dedicated string attribute (name), array of nodes (child nodes). This is very unusual structure and requires dedicated effort to map to programming language objects and structures. There were even so-called "OXM" frameworks (Object-XML Mapper), similarly to ORM. Of course in the end it is possible to build a mapping between array, dictionary and DOM. But JSON is much more natural fit.
      - Mikhail_Edoshin 10mo ago
josefx 10mo ago
> The JSON spec fits on two screen pages https://www.json.org/json-en.html https://www.json.org/json-en.html The beloved minimalist spec. . No way anything could be wrong with that: https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html Turns out there are at least half a dozen more specs. trying and failing to clarify that mess.
Mikhail_Edoshin 10mo ago
But the part of XML that is equivalent to JSON is basically five special symbols: angle brackets, quotes and ampersand. Syntax-wise this is less than JSON (and it even has two kinds of quotes). All the rest are extras: grammar, inclusion of external files (with name and position based addressing), things like element IDs and references, or a way to formally indicate that contents of an element are written in some other notation (e. g. "markdown").

deleted 10mo ago

[deleted]

theoryaway 10mo ago

> RIP a good tech killed by committees overembellishing it and engineers failing to recognise what they already had over the high of building something else. Hope I can quote it to Transofrmer architecture One day

jeltz 10mo ago

There are still virtually zero good XML parsers but plenty of good JSON parsers so I do not buy your assertion. Writing a good JSON parser can be done by most good engineers, but I have yet to use a good XML parser. This is based on my personal experience of having to parse XML in Ruby, Perl, Python, Java and Kotlin. It is a pain every time and I have run into parser bugs at least twice in my career while I have never experience a bug in a JSON parser. Implementing a JSON parser correctly is way simpler. And they are also generally more user friendly.

gwbas1c 10mo ago
Take a look at C# / dotnet. The XML parser that's been around since the early 2000s is awesome, but the JSON libraries are just okay. The official JSON library leaves so much to be desired that the older, 3rd party library is often better.
- nflekkhnnn 10mo ago
  The old and new json lib is written by the same person. The newer one is a bit more low-level — that’s intentional, the old one was too bloated.
  - gwbas1c 10mo ago
    Oooh, then it makes sense why there isn't a good set of layers: XmlReader -> (XmlDocument or XmlSerializer) generally hits all use cases for serialization well. XmlReader is super-low-level streaming, when you need it. XmlDocument is great when you need to reason with Xml as the data structure, and XmlSerializer quickly translates between Xml and data structures as object serialization. There's a few default options that are wrong; but overall the API is well thought out. In Newtonsoft I couldn't find a low level JsonReader; then in System.Text.Json I couldn't find an equivalent of mutable JObject. Both are great libraries, but they aren't comprehensive like System.Text.Json.
taeric 10mo ago
JSON parsing is pretty much guaranteed to be a nightmare if you try and use the numeric types. Or if you repeat keys. Neither of which are uncommon things to do. My favorite is when people start reimplementing schema ideas in json. Or, worse, namespaces. Good luck with that.

klodolph 10mo ago

Having used XSLT, I remember hating it with the passion of a thousand suns. Maybe we could have improved what we had, but anything I wanted to do was better done somehow else. I'm glad to have all sorts of specialists on our team, like DBAs, security engineers, and QA. But we had XSLT specialists, and I thought it was just a waste of effort.

gwbas1c 10mo ago

IMO, XSLT seems like something that should be handled on the server, not in the browser.

immibis 10mo ago

Not the minority. People can be sad that XSLT failed and also recognize that removing it from browsers is quite sensible, given the current situation.

altmind 10mo ago

You can do some cool stuff, like serving an RSS file that is also styled/rendered in the browser. A great loss for the 2010 idea of semantic web. One corporation is unhappy because it does not cover their use cases