Hacker News Reader

XSLT is also so much more than just a way to render html. especially version 2. the browsers afaik are still XSLT 1 which is kinda limited.

back in the day i built so many nice solutions for both web and internal services using XSLT as a key component. i also found it interesting that it was pretty easy for less experienced devs and particularly non-devs to pick up and make changes to. declarative programming has been much neglected sadly.

interesting! way way back in the early ’00’s (like pre-9/11 iirc) i built a toolkit on js/xml/xslt in IE 5.5 to transform data into UI controls. it wasn’t quite React but it did form the basis for the most of the UI of the startup i was at during that time, which was a web-based radiology product. unfortunately it was much harder to convince an employer to open-source support libraries and tools that weren’t the primary IP of the company, so it’s been lost to posterity (not that anyone would want to use it today!) still, good to know there’s at least some support for XSL in modern browsers.

XSLT was one of the things that brought me to React indirectly over a decade ago. I wanted to runs something like apply-templates (components) and that got me looking at XHP. That was the inspiration for JSX which became popular via react. Ironically I don't even use jsx anymore now that javascript has caught up, and a lot of what react does was really appealing from the declarative side. Weirdly so many of the "experts" are pushing very non-declarative approaches to it now. I'd love if xslt could achieve its stated goals, but like the rest of xml it's too academic and ignores obvious practical requirements.

What I like best about XSLT is that it reminds me that someone thought this was a great idea. They went so far as to declare it as “the way” and everyone should use it everywhere. There were conferences, books, blogs, everything. Anyone who criticized it was harshly rebuked and criticized. It isn’t just XSLT. The highway of IT progress is littered with these. XML, XSLT, CORBA, JEE… It’s helpful to keep in mind that nothing has changed, the current ones just haven’t blown up yet.

We need a word for these snake-swallowing-its-tail indirect abstractions we keep building. I have problem X, so I solve with abstraction a. Then I have problem Y, so I build b on a. Then to solve Z I build c on b on a. Then we discover a problem that is actually just X again, but rather than use a to solve we build d on c on b on a to solve it.

I remember installing enterprise java beans to support my soap wsdl 16 years ago. Meanwhile shopify built a basic Rails app using http verbs and killed the product I was using.

Ever since I played around with xhtml/xslt ~15-20 years ago when I was a lot newer to programming, I've always had the sense that it was a great way to do things, and that most sites should be using it. The last few days I've been playing with it again, and... I feel even more like that's true.

Even in its neglected state, it's got tons of features. You know how when Hacker News is having server issues, it tends to still work when logged out? Well you can just always serve the logged out page so it's cached for everyone, and then in the xslt template you can do an include of the user's data (that's right, you can directly include and query other xml documents in xhtml/xslt), e.g. <xsl:variable name="myinfo" select="document('/app/users/myinfo')"/> or something, and set that URL to private cache or no-cache, and then in the parts where you need the page to be different for the logged in user, you can e.g. compare '$myinfo/user/@id' to '@authorId' of a comment to decide whether to show an edit/delete button, etc. You basically get graceful degradation by default if it can't fetch that myinfo document. XPath is like jq that's been built into the browser this whole time.

The same thing can be used for things like subreddit side bars that are common across many but not all pages. You can even do an xsl:copy-of and serve it as xhtml. No need to send the same data over and over with SSR. No need to do client side routing or have any frontend tooling. It's all built right into the browser. The code is concise (it's verbose in the sense that it's xml, but it's still declarative) and easy to read. You can have a clean separation between backend sending the data in an xml model that makes sense for the domain, and then frontend having templates to present it.

The downside is of course that it all runs before the html for your page is produced, so you can't use javascript inside of xsl (unless you run a separate xsl processor in javascript), and it's about the same as SSR in terms of how dynamic it is (i.e. not interactive after page load, though you can of course have javascript in the output html). That and there's no info out there about how to use it because no one uses it, so you have to be a little creative. But it's been quite fun to see how much I can milk out of client side static template rendering using a technology that browsers haven't even bothered to update past 1.0 from 1999.

another XSLT advocate here.

The first time I encountered XSLT I thought it was the most ridiculous thing to ever have been invented. A programming language written in XML?

but damn, the things you can do with that thing in a tiny bit of code. It was doing expression filtering years before anyone else, including the likes of Haskell.

yes, the learning curve can be a problem initially but, once you grok it, it opens up a whole world of interesting possibilities. and i do think, once you have created your initial transforms, it is then much easier for non-tech folks to "see" how things work and make tweaks/changes without having to mess with "code".

Ad-hoc and framework JavScript rendering JSON into the DOM is the modern way, don't you know? There's a reason for this: JSON is easier to produce than XML in many server-side systems.

Maybe what's needed is an extension to XSLT/XPath to consume JSON and transform it to XML.

On the other hand, it wouldn't take much doing at~all to modify something that outputs json into something that outputs xml.

I feel like this is being rediscovered right now with htmx. Servers having their responses updated to give back html markup to include.

yes. back in the day i would tend to wrap my database api in xml first in a standardised way and then i could just use xslt to return json or other formats from the api depending on the mime types requested by client. this fits in nicely with fielding's REST principles. all those technologies (HTTP/REST, XML, XPath, XML Schema, XSLT) actually work very nicely together and allow you to build nice systems that are very flexible, easy to integrate with and easy to change, even though they can be hard to make fast. maybe "move fast, break things" was a bad idea? =)

Why make your payloads bigger though?

yes, there's definitely a bandwidth overhead with xml compared to json. that was an important factor in the shift i suppose. but then we have things like graphql, which has pretty much erased all those gains. you can also do tricky things like using binary on the wire and transforming at the endpoints.

it would be nice to see if fundamental xml tech can be improved in a new hardware and software environment. afaik, there hasn't been much if any innovation in that space in recent times. would love to know if there has.

That functionality does in fact exist in the current versions of those programming languages, i.e. XSLT 3.0 and XPath version 3.1

I wasn't mature enough to grasp xslt at the time (the match construct confused me, and trees everywhere wasn't natural yet), but while you talk about corba and jee I had a few moments in the recent years where I thought all the json/rest/microservices are hand knitted remote beans..

well yes. i agree re corba, j2ee etc. but i think there were a lot of very nice technologies around xml that enabled automatic discovery, interop, validation etc. and we have ditched them all because there was also a lot of unnecessarily complex baggage and tooling that came with the ecosystem around them.

i even thought SOAP was quite nice if you used the message oriented flavour instead of RPC flavour. REST was imo better and won out, but then nobody really does REST today and we seem to keep on re-inventing the wheel. am watching the htmx discourse with interest.

I was at IBM during peak SOAP. It was crazy how much business pushed for abstraction for abstractions sake in this domain. I'm really hoping htmx helps people get their heads on straight with REST. All these scores of devs have been writing `POST /item {"method":"replace","id":12}` or `POST /item {"method":"delete","id":12}` for decades now.

yeah. RPC masquerading as REST is what people do now.

if your web service had a truly RESTful design then all you would need to do is point something like postman (or a browser) at it and it would be able to automagically figure out the whole set of available resources and interactions instead of having to use all this crazy swagger/OpenAPI stuff. there's a whole cottage industry around this api stuff rn.

i guess this is what happens when you put "programmers" in charge of a hypermedia system. everything becomes an RPC and nothing is standardised.

¯\_(ツ)_/¯

My day job combines assembly and XSL (GPU dev work can be weird). I have a soft spot for XSL; but, at this point, the combination of Python 3's performance story (concurrency, threading, multiprocessing), ElementTree, and itertools... I just don't see it anymore. Especially since any new hire has Python experience due to the current ML summer. I've been porting all my XSL to Python, and I couldn't be happier.

I still find it hard to write transformations nicely in normal programming languages. I actually even used it to transform structured formats and always am quite happy (using [0]). Also generated spreadsheets and docs (actually via markdown and pandoc) just 2 days ago. xsltproc is for me the awk/sed of structured.

[0] http://www.ananas.org/xi/

yeah, making XML/XSLT fast is definitely a hard problem. still in pretty wide use in enterprise systems where correctness and interop are bigger priorities. i did quite a lot of work with shipping api's recently and you would be surprised how many of them are still XML and even SOAP based.

i'm intrigued by the combination of Assembly and XSL - any pointers to what you use those for?

Hardware specs are written in docbook in a lot of places. On the flip side, new HW won't have good C compilers for a while.

Now that computers have more than 640kb of memory, it’s much easier to parse a document tree into a data structure and output exactly what you want.

I had never heard of XSLT before until I happened upon this Esperanto dictionary. https://www.tujavortaro.net/

> Try opening https://kmaasrud.com/blogroll.xml in a new tab (Ctrl+click or whatever), and observe the correct document title, but how the actual document area remains blank and the status bar says it’s still “Transferring data from kmaasrud.com…”.

It worked for me: https://imgur.com/a/Qccw9kT

I opened that URL.

It opened fine in Safari (macOS), and it opened fine in Chrome. Firefox did not apply the XSL file.

I tried to "view source" on both Safari and Chrome, and neither gave me the option. I could Inspect Element, and I got the HTML DOM, but not the original XML source. On Firefox, it showed me the XML file.

This surprised me. I was under the understanding that the browsers had effectively abandoned the XML/XSL concept any more. Apparently Firefox does.

It's also a shame the browsers stopped at XSL v1 as well, v2 is much better.

But, the browsers basically said "we're not in the XML ecosystem, we're in the HTML ecosystem".

The idea of downloading XSL, and then having a blog post that was little more than just content, with a wee bit of meta data, with all the chrome rendered locally via the template, I find that idea compelling. One less thing to download. More stuff to cache on the local system.

I had grand visions of an XProc pipeline terminated in the browser itself, but when I found out the browsers weren't really playing along anymore, kind of took the wind out of its sails.

> Firefox did not apply the XSL file.

It did for me. The "This is a list of blogs and news sources I follow." part of the page as rendered comes from the XSL file (opml.xsl). The actual list is rendered. I'm did not check whether the XSL was applied correctly, but applied it was.

> On Firefox, ["view source"] showed be the XML file.

Can confirm.

> The idea of downloading XSL, [...], I find that idea compelling.

> [...] but when I found out the browsers weren't really playing along anymore, kind of took the wind out of its sails.

Sad, yes, but for me Firefox did download the XML, the XSL, applied the XSL, and rendered the resulting page. I dunno why it didn't for you or GP, but maybe it's an add-on interfering? Do check, and please report, because I'm curious if the issue is add-ons.

Works for me too. I see a list with bolded links and descriptions and when I view source I see xml starting with an opml tag, instead of html.

edit: and yes opened the link on a new tab

I've never used there.com, but I’m told its “secret sauce,” is browser-applied XSL.

The "here's the content, you do the rendering" is very close to what gemini does. https://geminiprotocol.net/

> Try opening https://kmaasrud.com/blogroll.xml in a new tab (Ctrl+click or whatever)

I can't reproduce your issue (on Firefox 115.7.0esr (64-bit) from Debian). I open it in a new tab with middle click and it loads fine immediately.

> Try opening https://kmaasrud.com/blogroll.xml in a new tab (Ctrl+click or whatever), and observe the correct document title

Loads absolutely fine for me on Firefox Nightly and on Firefox 122.0.1 stable on Linux.

Adding firefox for windows (tablet) and firefox for android to the list

Add safari for macOS to the list

This discussion awoke an ancient memory in me - this DailyWTF article about skechers.com https://thedailywtf.com/articles/Sketchy-Skecherscom

The article is (as to be expected) very disparaging, but the author responded with valid points. Either way, a fun read and a blast from the past.

That URL loaded for me fine in FF 122.0.1 ....

Fwiw, article and feed render fine for me, FF 122, Arch, but my bookmarklets to popup a dialog and copy the url do not work.

Works for me in Safari too.

Did you open it in a new tab? In an existing tab, it loads fine.

On reflection, it’s also quite possible this is a platform-specific bug. I’m on Linux. I think I experienced it in Windows a few years back, but the memory is fuzzy.

… hmm, apparently if I start a blank Firefox profile this doesn’t happen either. Though I know I’ve encountered this with at least two completely distinct Firefox profiles over the years. This bears closer investigation.

Anyway, it’s still indicative of the disrepair of this feature set. It’s still used widely enough that I don’t think it’ll be torn out, but honestly on technical robustness grounds it could warrant being removed.

It works fine for me, with a current FF on Linux (Ubuntu), opening in a new tab. I have lots of extensions enabled.

But I do share your frustration: the modern web seems unusable, unless you have a collection of extensions that block ads, annoying consent forms and the likes. But once you have these extensions installed, you basically lose all support.

Sometimes stuff breaks, and it works in a new profile even with the same extensions installed... and then what? You're supposed to throw away your profile with bookmarks, CAs, years of history etc.?

>But once you have these extensions installed, you basically lose all support.

Its gotten to the point where I have multiple browsers as fallback. FF with lots of essential extensions > Brave with just a few > Unextended Chromium. A necessarily ridiculous state of affairs, but there you have it.

Same for me, but without Brave as a middle ground. I think Firefox even without extensions is less and less supported, sadly.

Maybe try disabling your extensions?

Firefox is sometimes weird that way. I too have seen issues (with other stuff, not this particular xslt page) that randomly seem in only some profile.

It works for me if you open in a new tab, a new window, or a new private window. FF122.0 on windows.

works fine for me in a new tab also on chrome/ubuntu.

It loads for me, and it applies the XSL. Do you have NoScript or some add-on like it interfering with the loading?

Opening it in a new tab on FF on Android works fine on the first try.

Blizzard of all peoples site in the late aughts was all XML with XSLT. It was kind of beautiful.