←back to thread

392 points _kush | 7 comments | | HN request time: 0.954s | source | bottom
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 #
diggan ◴[] No.44395678[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

Generally speaking I feel like this is true for a lot of stuff in programming circles, XML included.

New technology appears, some people play around with it. Others come up with using it for something else. Give it some time, and eventually people start putting it everywhere. Soon "X is not for Y" blogposts appear, and usage finally starts to decrease as people rediscover "use the right tool for the right problem". Wait yet some more time, and a new technology appears, and the same cycle begins again.

Seen it with so many things by now that I think "we'll" (the software community) forever be stuck in this cycle and the only way to win is to explicitly jump out of the cycle and watch it from afar, pick up the pieces that actually make sense to continue using and ignore the rest.

replies(2): >>44396131 #>>44396688 #
1. colonwqbang ◴[] No.44396131[source]
There have been many such cycles, but the XML hysteria of the 00s is the worst I can think of. It lasted a long time and the square peg XML was shoved into so many round holes.
replies(1): >>44396345 #
2. 0x445442 ◴[] No.44396345[source]
IDK, the XML hysteria is similar by comparison to the dynamic and functional languages hysterias. And it pales in comparison to the micro services, SPA and the current AI hysterias.
replies(3): >>44397347 #>>44397462 #>>44398988 #
3. xorcist ◴[] No.44397347[source]
Agreed. Also, Docker.
4. homebrewer ◴[] No.44397462[source]
IMHO it's pretty comparable, the difference is only in the magnitude of insanity. After all, the industry did crap out these hardware XML accelerators that were supposed to improve performance of doing massive amounts of XML transformations — is it not the GPU/TPU craze of today?

https://en.wikipedia.org/wiki/XML_appliance

E.g.

https://www.serverwatch.com/hardware/power-up-xml-data-proce...

replies(2): >>44398329 #>>44399317 #
5. soulofmischief ◴[] No.44398329{3}[source]
At least arrays of numbers are naturally much closer to the hardware, we've definitely come a long way in that regard.
6. vjvjvjvjghv ◴[] No.44398988[source]
Exactly. Compared to microservices XML is a pretty minor problem.
7. bogeholm ◴[] No.44399317{3}[source]
From your first link

> An XML appliance is a special-purpose network device used to secure, manage and mediate XML traffic.

Holy moly