←back to thread

392 points _kush | 1 comments | | HN request time: 0s | source
Show context
badmintonbaseba ◴[] No.44394985[source]
I have worked for a company that (probably still is) heavily invested in XSLT for XML templating. It's not good, and they would probably migrate from it if they could.

  1. Even though there are newer XSLT standards, XSLT 1.0 is still dominant. It is quite limited and weird compared to the newer standards.

  2. Resolving performance problems of XSLT templates is hell. XSLT is a Turing-complete functional-style language, with performance very much abstracted away. There are XSLT templates that worked fine for most documents, but then one document came in with a ~100 row table and it blew up. Turns out that the template that processed the table is O(N^2) or worse, without any obvious way to optimize it (it might even have an XPath on each row that itself is O(N) or worse). I don't exactly know how it manifested, but as I recall the document was processed by XSLT for more than 7 minutes.
JS might have other problems, but not being able to resolve algorithmic complexity issues is not one of them.
replies(9): >>44395187 #>>44395285 #>>44395306 #>>44395323 #>>44395430 #>>44395839 #>>44396146 #>>44397330 #>>44398324 #
nolok ◴[] No.44395323[source]
It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them, doesn't matter if XSLT or SOAP or even XHTML in a way ... Those were defined as machine language meant for machine talking to machine, and invariably something go south and it's not really made for us to intervene in the middle; it can be done but it's way more work than it should be; especially since they clearly never based it on the idea that those machine will sometime speak "wrong", or a different "dialect".

It looks great, then you design your stuff and it goes great, then you deploy to the real world and everything catches on fire instantly and everytime you stop one another one starts.

replies(6): >>44395678 #>>44396319 #>>44396490 #>>44398819 #>>44398980 #>>44399134 #
vjvjvjvjghv ◴[] No.44398980[source]
Now we have "JSON as savior". I see it way too often where new people come into a project and the first thing they want to do is to replace all XML with JSON, just because. Never mind that this solves basically nothing and often introduces its own set of problems. I am not a big fan of XML but to me it's pretty low in the hierarchy of design problems.
replies(1): >>44399372 #
SoftTalker ◴[] No.44399372{3}[source]
The only problem with XML is the verbosity of the markup. Otherwise it's a nice way to structure data without the bizarre idiosyncracies of YAML or JSON.
replies(2): >>44399781 #>>44400539 #
1. vjvjvjvjghv ◴[] No.44400539{4}[source]
XML has its own set of idiosyncrasies like everything being a string. Or no explicit markup of arrays. The whole confusion around attributes vs values. And many others.

JSON has its own set of problems like lack of comments and for some reason no date type.

But in the end they are just data file formats. We have bigger things to worry about.