[grndn]

I came here to say the same thing. :)

The fundamental problem is that you want one piece of (semantic) content to be presented on many different platforms with very different design approaches.

The current approach uses if-then-else conditions in CSS, and when that fails, if-then-else conditions in JS, and when that fails, complex JS to transform the DOM. The XML/XSLT approach, although clunky, might actually be better in many cases.

[skrebbel]

You can't honestly propose XSLT as a programming language in a thread where half the comments are about how shitty JavaScript is. I mean, JavaScript isn't God's gift to mankind, but XSLT?

I have a very hard time coming up with a worse programming language than XSLT, across all dimensions. INTERCAL, maybe? If XSLT had been proposed as a satirical esoteric programming language, people would've laughed and believed it. And probably made better tooling for it than the serious crowd ever did, just for the lulz.

[guitarbill]

> I have a very hard time coming up with a worse programming language than XSLT

What a straw-man argument. He clearly says "[t]he XML/XSLT approach", which is not advocating that XSLT is the best thing ever, but that we ought to consider that the people who developed XSLT had a similar problem to solve, thought hard about it, and came up with that. Many years later, it isn't out of this world that we could come up with a better solution. Arguably now there's more interest in such a solution than ever. For example, there are companies who have made generating PDFs for reports or bills their business model, because it's hard to do reliably with standard web tech. ePUB too? That would be all kinds of awesome.

So let's not dismiss XSLT and simply go back to the dysfunctional way it's currently being done. That said, of course XML et al are clunky, old and too enterprise-y - by trying to cover every use-case ever or having big corporations pushing their use-cases during the spec design this tends to happen. This seems to be a problem with the W3C in general, but they have to get their money somehow, and standards that nobody will use don't help either. Somehow we still ended up with JSON for the data serialisation use-case, which is pretty good. So there's hope. (The irony of JSON being at least inspired by Javascript does not escape me.)

[skrebbel]

> What a straw-man argument. He clearly says "[t]he XML/XSLT approach",

That's a good point. I think I'm so scarred by how much I dislike XSLT that I fail to read comments that are positive about it in good faith. Clearly a mistake on my part, thanks.

[mattmanser]

I made a pivot table creator in XSLT, it was pretty awesome and amazingly fast compared to how slow JavaScript was back in 2007.

Still, I know what you mean. Blizzard had a pretty cool WOW character editor in XSLT.

If you used only certain stuff and never had to debug someone else's XSLT it was pretty awesome.

[e12e]

The xslst "approach" + Javascript/json = graphql.

[bonesss]

> I mean, JavaScript isn't God's gift to mankind, but XSLT?

Well... for just about any scenario where I would use XSLT, and demand the validation capabilities it provides, I can imagine the same functionality being delivered in javascript... I can also imagine trying to do QA on it when provided by a third party... thanks, but no thanks.

XSLT solves some serious problems in a way that satisfies some serious Enterprise demands. For any given issue a pure code solution will be better, but in aggregate you don't want your systems open to third party incompetence.

[hnzix]

But XSLT is functional so that makes it awesome right?

XSLT 2 was actually usable. 1 on the other hand... it really did feel like a twilight zone sick joke.

[always_good]

It's simply a way to brandish your nerd cred.