XSLT is a failure wrapped in pain
harmful.cat-v.org
XSLT is a failure wrapped in pain
1–10 of 157 posts
Re: XSLT is a failure wrapped in pain
#2XSLT is 15 years old technology. If it is painful or not should be obvious today even before starting a project.
Re: XSLT is a failure wrapped in pain
#3XSLT is one of the most powerful and elegant technologies created in the last 15 years. Those who don't understand it and that's why can't use it, should just do their home work and learn better
Re: XSLT is a failure wrapped in pain
#4XSLT is one of the most powerful and elegant technologies created in the last 15 years. Those who don't understand it and that's why can't use it, should just do their home work and learn better
My definition of powerful and elegant is lisp
XML is just death by overengineering
Re: XSLT is a failure wrapped in pain
#5Rather than singing the praise of XSLT (which I love) I'll show an example: this tool transforms any rich text to markdown:
It's about 30 lines of XSLT that run in the browser. [Edit: it's not 30 lines but 230, but I was thinking of the number of "rules" (templates) of which there are only 29.]
There are very few other tools of its kind and I don't think there exists any client-side, with the same simplicity. This attempt for example
https://github.com/domchristie/to-markdown/blob/master/src/t...
is about 180 lines of JS, is incomplete, doesn't work with many special cases, etc.
There is no better templating language than XSLT; every other templating approach (in PHP or Python on the server, in JavaScript on the client) feels like a horrible kludge once you've experienced XSLT.
Yes, XSLT is practically dead, that's a fact. But we should be very sad about it, instead of dancing on the coffin like the OP with its stupid quotes.
Re: XSLT is a failure wrapped in pain
#6XSLT is one of the most powerful and elegant technologies created in the last 15 years. Those who don't understand it and that's why can't use it, should just do their home work and learn better
The problem is that it's often misused. Using an XSLT that takes 0.5s to run to transform some XML to HTML during web requests on a busy site? Idiotic.
Using it for async transformations - html to pdf, customer message format to your message format. Fine.
Re: XSLT is a failure wrapped in pain
#7Rather than singing the praise of XSLT (which I love) I'll show an example: this tool transforms any rich text to markdown: http://markitdown.medusis.com It's about 30 lines of XSLT that run in the browser. [Edit: it's not 30 lines but 230, but I was thinking of the number of "rules" (templates) of which there are only 29.] There are very few other tools of its kind and I don't think there exists any client-side, wit…
Looks like 230 lines to me https://github.com/bambax/markitdown.medusis.com/blob/master...
Re: XSLT is a failure wrapped in pain
#8JSON/Javascript is just easier to learn and work with than XML/XSLT. For starters, you don't need to learn a special language that you'll never use for anything else.
Just in case you /do/ need to use XML every day: the primary benefit of XSLT is that it lets you avoid using XML libraries to munge some XML. Because the XML libraries are so horrendous to use from any language.
Re: XSLT is a failure wrapped in pain
#9The problem with XSLT, XML, SOAP, WS-* is that the community is driven by vendors with deep pockets who use their power to kill interoperability.
Imagine LISP, but in the hands of Sauron or Palpatine. That's the XML group of technology.
Re: XSLT is a failure wrapped in pain
#10Rather than singing the praise of XSLT (which I love) I'll show an example: this tool transforms any rich text to markdown: http://markitdown.medusis.com It's about 30 lines of XSLT that run in the browser. [Edit: it's not 30 lines but 230, but I was thinking of the number of "rules" (templates) of which there are only 29.] There are very few other tools of its kind and I don't think there exists any client-side, wit…
+1 - I have to deal with structured documents encoded in XML on a daily base, and most of the time there is no other tool for me than to write an XSLT stylesheet.
I really like the computational model of XSLT (push vs. pull), it is so elegant. But it takes a quite some time to fully understand what is going on.
What I think is bad, is that the infrastructure for XSLT is not perferct. There is only one good XSLT 2 processor that I know of, everything else is XSLT 1.
I am currently eliminating some XSLT scripts with custom (Go) programs, because of speed issues.