Hacker News Reader

Comment by munificent | Hacker News Reader

> XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages.

Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively?

I'd be willing to bet good money that the Venn diagram of users that fit the intersection of "authoring content for the web", "care about separating content from HTML", "comfortable with HTML", "not comfortable with JavaScript", and "able to ramp up on XSLT" is pretty small.

At some point, we have to just decide "sorry, this use case is too marginal for every browser to maintain this complexity forever".

View on HN

> Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively?

Hi! I'm a non-programmer who picked up XSLT of my own volition and spent the last five-ish years using it to write a website. I even put up all the code on github: https://github.com/zmodemorg/wyrm.org

I spent a few weeks converting the site to use a static site generator, and there were a lot of things I could do in XSLT that I can't really do in the generator, which sucks. I'd revert the entire website in heartbeat if I knew that XSLT support would actually stick around (in fact, that's one of the reasons I started with XSLT in the first place, I didn't think that support would go away any time soon, but here we are)

For what it's worth, you can still run an XSL processor as a static generator. You of course lose some power like using document() to include information for a logged in user, but if it's a static site then that's fine.

Users don't log in to my site.

I eventually started using server-side XSL processing (https://nginx.org/en/docs/http/ngx_http_xslt_module.html) because I wanted my site to be viewable in text-based browsers, too, but it uses the same XSLT library that the browsers use and I don't know how long it's going to be around.

> Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively?

Admittedly this was 20ish years ago, but I used to teach the business analysts XSLT so they could create/edit/format their own reports.

At the time Crystal Reports had become crazy expensive so I developed a system that would send the data to the browser as XML and then an XSLT to format the report. It provided basic interactivity and could be edited by people other than me. Also, if I remember, at the time it only worked in IE because it was the only browser with the transform function.

Funnily enough, XSLT is one of those things that I don't know very well but LLMs do. I find that I can ask Gemini to blurt out an XSLT implementation of my requirements given a snippet of example doc, and I have used this to good effect in some web scrapers/robots.

I was such a non-programmer as a child, yes. At the time that XSLT was new, if you read a book on HTML and making web pages from the library, it would tell you about things like separating content from styles and layout, yes. Things that blew my mind were that you could install Apache on your own computer and your desktop could be a website, or (as I learned many years later) that you could make a server application (or these days now Javascript code) that calls a function based on a requested path instead of paths being 1:1 with files. By contrast, like I said XSLT was just a natural extension of HTML for something that everyone who's written a couple web pages wants to do.

The fact that the web's new owners have decided that making web pages is too marginal a use-case for the Web Platform is my point.

> it would tell you about things like separating content from styles and layout, yes.

That's what CSS does.

Yes that's why XSLT is such a natural fit when you learn about HTML+CSS. It's the same idea, but applied to HTML templates, which is something you immediately want when you hand-write HTML (e.g. navbars, headers, and footers that you can include on every page).

Your problem here is that you're hand-writing HTML including all the templates. This wasn't a good way to do it 30 years ago and it's not a good way to do it now.

See all these "static site generators" everyone's into these days? We used those in the mid-90s. They were called "Makefiles".

Yeah because I was 11 and didn't know what a Makefile was. That's my point. I wanted to make web pages, and didn't know any programming. HTML is designed to be hand-written. You just write text, and when you want it to look different, you wrap it in a thing. When doing this, you'll quickly want to re-use snippets/invent your own tags. XSLT gives a solution to this without saying "okay let's back up and go learn how to use a command line now, and probably use an entirely different document format" (SSGs) or "okay let's back up and learn about functions, variables, classes, and callbacks, and maybe a compiler" (Javascript). It just says "when you want to make your own tags, extract them into a 'template' tag, then include your templates just like you include a CSS file for styles".

XSLT is really separating (XML) data from markup in the case of the web. More generally it's transforming between different XML formats.

But in the case of docs (eg XML-FO for docbook, DITA etc) XSLT does actually separate content from styling.

I did. Just because the herd says it's dead doesn't mean XSLT is dead or "bad"

I've seen non-programmers learn SQL, and SQL is far more inconsistent, complex, non-orthogonal, fragmented, footgunny, and user hostile than most programming languages.

I'm not sure what I mean by this, WRT XSLT vs Javascript.

I did after reading about it. I immediately moved my personal site to it and got rid of the crap JS site I had.

Reply on news.ycombinator.com