[bambax]

Rather 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, 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.

[crdoconnor]

http://markitdown.medusis.com/xsl/html2mk.xsl

It looks like 234 lines of code to me.

>This attempt for example https://github.com/domchristie/to-markdown/blob/master/src/t....

Is badly written, but still written in a better language. They're using regexps to parse HTML (omfg!), but that kind of nastiness doesn't excuse XSLT as a language.

>There is no better templating language than XSLT

Except mako, jinja2, django templating language, liquid, etc.

[bambax]

You're right, it's 230 lines; I updated my post accordingly. I wrote the thing 3 years ago and remembered the number of rules (templates) instead of the number of actual lines. But a line's a line, so I was wrong.

"written in a better language" doesn't mean much, however. A better language for what? I'm not picking on JavaScript, which I love and use every day; but templating in JS versus XSLT is crazy.

The templating languages that you mention are, in my opinion, extremely complex and very unpalatable; and they only work server-side.

But that's all a matter of taste, I guess. What I don't understand is why so many people go out of their way to declare their hate of XSLT (and all things XML), especially now that XSLT is all but dead...?

[crdoconnor]

>"written in a better language" doesn't mean much, however. A better language for what?

For general purpose programming, which is what transformations eventually end up requiring. XSLT isn't java or javascript. It theoretically can do everything that those two can do, but we both know in practice that once you don anything sufficiently complex in XSLT it will become horrendous. Even the biggest proponents of XSLT won't argue that you should put business logic in there (I hope, anyway).

>I'm not picking on JavaScript, which I love and use every day; but templating in JS versus XSLT is crazy.

Because?

>The templating languages that you mention are, in my opinion, extremely complex and very unpalatable

What??!? I can get web designers with no coding experience to edit them! Try doing that with xslt. They're that simple! Not only are they conceptually simpler, they are mathematically provably simpler due to their being non-turing complete.

>and they only work server-side.

Am not a client side developer so I don't know what the state of the art is in client side templating languages, but there are a few that look ok (dust, jsrender, handlebars...).

>But that's all a matter of taste, I guess. What I don't understand is why so many people go out of their way to declare their hate of XSLT

Because they have spent time debugging it and know that every second they spent doing that was both painful and unnecessary.

If you don't understand the pain it might mean that you don't even realize that the same pain you felt debugging it wasn't actually necessary.

My sincere hope is that all the people who create business critical XSLT abortions will stop doing it so I won't ever be called in again to fix what they did. That's why I'm passionate in my XSLT (and XML) hate.

[bambax]

> the same pain you felt debugging it

XSLT is "right the first time"; I have had to do corrections and evolutions but very rarely (never?) have I had to hunt for a weird unexplained behavior.

Of course I have seen horrible XSLTs, but horrible is in no way limited to XSLT (the only thing that's XSLT-specific is when people try to do imperative programming in XSLT).

I'm currently trying to make sense of a database model where every. single. property. is a flag in just one table (isClient, isProspect, isActive, isAForeigner, isMale, isFemale, etc. etc.)

No XSLT involved whatsoever. Big pain.

[woah]

Looks like 230 lines to me https://github.com/bambax/markitdown.medusis.com/blob/master...

[patrickg]

+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.