Comment by bambax
11 years ago
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...?
>"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.
> 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.
>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...?
Seriously? It's because we're shocked to find people like you defending it. Incredulously wondering if you've been paying attention to literally any other piece of technology other than XSLT in the meantime.
:(, but, for you.
>and they only work server-side.
I choked on laughter, maybe you can help me take this one seriously, given XSLT and when it was actually even in consideration for being used server-side.