HN Reader

I have worked for a company that (probably still is) heavily invested in XSLT for XML templating. It's not good, and they would probably migrate from it if they could.

  1. Even though there are newer XSLT standards, XSLT 1.0 is still dominant. It is quite limited and weird compared to the newer standards.

  2. Resolving performance problems of XSLT templates is hell. XSLT is a Turing-complete functional-style language, with performance very much abstracted away. There are XSLT templates that worked fine for most documents, but then one document came in with a ~100 row table and it blew up. Turns out that the template that processed the table is O(N^2) or worse, without any obvious way to optimize it (it might even have an XPath on each row that itself is O(N) or worse). I don't exactly know how it manifested, but as I recall the document was processed by XSLT for more than 7 minutes.

JS might have other problems, but not being able to resolve algorithmic complexity issues is not one of them.

These days I use XSLT to style my feeds. For example:

https://susam.net/feed.xml

https://susam.net/feed.xsl

One of my first projects as a professional software engineer at the ripe age of 19 was customizing a pair of Google Search Appliances that my employer had bought. They'd shelled out hundreds of thousands of dollars to rack yellow-faced Dell servers running CentOS with some Google-y Python because they thought that being able to perform full-text searches of vast CIFS document stores would streamline their business development processes. Circa 2011 XHTML was all the rage and the GSA's modus operandi was to transform search results served from the backend in XML into XHTML via XSLT. I took the stock template and turned it into an unholy abomination that served something resembling the rest of the corporate intranet portal by way of assets and markup stolen from rendered Coldfusion application pages, StackOverflow, and W3Schools tutorials.

I learned quickly to leave this particular experience off of my resume as sundry DoD contractors contacted me on LinkedIn for my "XML expertise" to participate in various documentation modernization projects.

The next time you sigh as you use JSX to iterate over an array of Typescript interfaces deserialized from a JSON response remember this post - you could be me doing the same in XSLT :-).

The x86-cpuid-db project [1] heavily uses XSLT 3.0 through the “saxonche” PIP package.

It has worked amazingly well for us, and the generated files are already merged in the Linux Kernel.

[1] https://gitlab.com/x86-cpuid.org/x86-cpuid-db

XSLT is great fun as a general functional programming language! You can build native functional data-structures[1], implement graph-traversal algorithms[2], and even write test assertions[3]!

1: https://github.com/pjlsergeant/xslt-fever-dream/blob/main/ut...

2: https://github.com/pjlsergeant/xslt-fever-dream/blob/main/ut...

3: https://github.com/pjlsergeant/xslt-fever-dream/blob/main/ut...

I love XSLT, that is what I ported my site to after the CGI phase.

Unfortunately it is not a sentiment that is shared by many, and many developers always had issues understanding the FP approach of its design, looking beyond the XML.

25 years later we have JSON and YAML formats reinventing the wheel, mostly badly, for that we already had nicely available on the XML ecosystem.

Schemas, validation, graphical transformation tools, structured editors, comments, plugins, namespaces,...

It's worth mentioning that current XSLT version is 3.0 but browsers are only compatible with XSLT 1.0

I remember Blizzard actually using this concept for their battle.net site like, 10 years ago. I found it always really cool, but at some point I think they replaced it with a "regular" SPA stack.

I think one big problem with popularizing that approach is that XSLT as a language frankly sucks. As an architecture component, it's absolutely the right idea, but as long as actually developing in it is a world of pain, I don't see how people would have any incentive to adopt it.

The tragic thing is that there are other pure-functional XML transformation languages that are really well-designed - like XQuery. But there is no browser that supports those.

My first resume was in XSLT, because I didn't want to duplicate HTML tags and style around, it worked really well, and it was fun to see the xml first when clicking "view source".

I hate this grug brain writing style. It sounds bad and is hard to read. Please just write normal, full sentences.

My first intranet job early 2000s reporting was done this way. You could query a db via asp to get some xml, then transform using xslt and get a big html report you could print. I got pretty good at xslt. Nowadays I steer towards a reporting system for reports, but for other scenario you’re typically doing one of the stacks he mentioned: JSON or md + angular/vue/react/next/nuxt/etc

I’ve kinda gotten to a point and curious if others feel same: it’s all just strings. You get some strings from somewhere, write some more strings to make those strings show other strings to the browser. Sometimes the strings reference non strings for things like video/audio/image. But even those get sent over network with strings in the http header. Sometimes people have strong feelings about their favorite strings, and there are pros and cons to various strings. Some ways let you write less strings to do more. Some are faster. Some have angle brackets, some have curly brackets, some have none at all! But at the end of the day- it’s just strings.

Blast from the past. I actually used XSLT quite a bit in the early 00s. Eventually I think everyone figured out XML is an ugly way to write S-expressions.

What is needed more now is YAML, especially the visualization of the YAML format supported by k8s by default. On the contrary, in the devops community, people need to generate YAML through HTML to execute cicd. For example, this tool shows k8s-generator.vercel.app

I used XSLT as a build system for websites way back in 1999–2000. The developer ergonomics were terrible. Looking at the example given, it doesn’t seem like anything much has changed.

Has there been any progress on making this into something developers would actually like to use? As far as I can tell, it’s only ever used in situations where it’s a last resort, such as making Atom/RSS feeds viewable in browsers that don’t support them.

Sometimes I wish we could have kept XML alive alongside JSON.. I miss the comments, CDATA etc, especially when you have to serialize complex state. I know there are alternatives to JSON like YAML but I felt XML was better than YAML. We adopted JSON for its simplicity but tried to retrofit schema and other things that made XML complex. Like we kind of reinvented JSON Schema, and ended up like what XSD did decades ago and still lacking a good alternative to XSLT..

I also did a similar XSL blog demo a few years ago. Here is the demo:

https://evidlo.github.io/xsl-website

I made a website based on XML documents and XSLT transformations about 20 years ago. I really liked the concept. The infrastructure could have been made much simpler but I guess I wanted to have an excuse to play with these technologies.

After spending months working on my development machine, I deployed the website to my VPS, to realize to my utter dismay that the XSLT module was not activated on the PHP configuration. I had to ask the (small) company to update their PHP installation just for me, which they promptly did.

XSLT is cool and was quite mind-expanding for me when it came out - I wouldn't say it's "grug brain" level technology at all. An XML language for manipulating XML - can get quite confusing and "meta". I wouldn't pick it as a tool these days.

What an incoherent writing lol. I'm not sure if grug = incoherent necessarily, but I'm sure that there is the type of genius that every sentence of them is painfully clear. Wouldn't it be better to cater towards that?

Anyway.

Paco Grug talks about how they want a website (e.g. a blog) without a server-side build-step. Just data, shape of data, and the building happening automagically, this time on the client. HTML has javascript and frames for that, but HTML painfully lacks transclusion, for header menu, sidebar and footer, which birthed myriads of web servers and webserver technologies.

It seems that .xml can do it too, e.g. transclusion and probably more. The repo doesn't really showcase it.

Anyway, I downloaded the repo, and ran it on a local webserver, it works. It also works javascript disabled, on an old browser. (Not as opened as a file tho.) Nice technology, maybe it is possible to use it for something useful (in a very specific niche). For most other things javascript/build-step/dynamic webserver is better.

Also, I think that for a blog you'll want the posts in separate files, and you can't just dump them in a folder and expect that the browser will find them. You'll need a webserver/build-step/javascript for that.

XSLT was truly cool.

I have created a CMS that supported different building blocks (plugins), each would output its data in XML and supply its XSLT for processing. The CMS called each block, applied the concatenated XSLT and output HTML.

It was novel at the time and really nice and handy to use.

Please let this come back since I was highly skilled at it and nobody uses it and I am the sads.. since it was a bit functional and a good challenge and was fun. And I would like to be paid to write teh complicated stylesheets again. Thanks

Does anybody remember Cocoon? It was an XSLT Web Framework that built upon Spring. It was pretty neat, you could do the stuff XSLT was great at with stylesheets that were mapped to HTTP routes, and it was very easy to extend it with custom functions and supporting Java code to do the stuff it wasn't really great at. Though I must say that as the XSLT stylesheets grew in complexity, they got *really* hard to understand, especially compared to something like a Jinja template.

I believe some people might find Zjs Components interesting for this matter :

https://news.ycombinator.com/item?id=44290315

Paper abstract :

ZjsComponent: A Pragmatic Approach to Modular, Reusable UI Fragments for Web Development

    In this paper, I present ZjsComponent, a lightweight and framework-agnostic web component designed for creating modular, reusable UI elements with minimal developer overhead. ZjsComponent is an example implementation of an approach to creating components and object instances that can be used purely from HTML. Unlike traditional approaches to components, the approach implemented by ZjsComponent does not require build-steps, transpiling, pre-compilation, any specific ecosystem or any other dependency. All that is required is that the browser can load and execute Javascript as needed by Web Components. ZjsComponent allows dynamic loading and isolation of HTML+JS fragments, offering developers a simple way to build reusable interfaces with ease. This approach is dependency-free, provides significant DOM and code isolation, and supports simple lifecycle hooks as well as traditional methods expected of an instance of a class.

I'm old enough to remember when Google released AJAXSLT in 2005. It was a JS implementation of XSLT so that you could consistently use XSLT in the browser.

The funny thing is that the concept of AJAX was fairly new at the time, and so for them it made sense that the future of "fat" web pages (that's the term they use in their doc) was to use AJAX to download XML and transform it. But then people quickly learned that if you could just use JS to generate content, why bother with XML at all?

Back in 2005 I was evaluating some web framework concepts from R&D at the company I worked, and they were still very much in an XML mindset. I remember they created an HTML table widget that loaded XML documents and used XPATH to select content to render in the cells.

This elides a huge advantage to this approach: your blog (or whatever) is just raw data. Consuming it with a browser applies the linked stylesheet and spit out HTML. But you can consume the endpoint with anything.

For instance you could share a music playlist as an XSPF document. In the browser your style sheet could make it into a nice web page with audio tags to play the content. But that exact same endpoint opened with VLC would just treat it as a normal playlist.

You can just publish raw data (with robust schema validation) and each user agent will handle it appropriately. Even a bare bones style sheet could just say "open this URL with some particular application.

Since the XSLT engine is built into browsers you get a free transformation engine without any JavaScript.

I’m disappointed that this uses a custom XML format, rather than RSS (tolerable) or Atom (better). Then you could just drop it into a feed reader fine.

A few years ago, I decided to style my own feeds, and ended up with this: https://chrismorgan.info/blog/tags/fun/feed.xml. https://chrismorgan.info/atom.xsl is pretty detailed, I don’t think you’ll find one with more comprehensive feature support. (I wrote a variant of it for RSS too, since I was contemplating podcasts at the time and almost all podcast software is stupid and doesn’t support Atom, and it’s all Apple’s fault: https://temp.chrismorgan.info/2022-05-10-rss.xsl.)

At the time, I strongly considered making the next iteration of my website serve all blog stuff as Atom documents—post lists as feeds, and individual pages as entries. In the end, I’ve decided to head in a completely different direction (involving a lot of handwriting!), but I don’t think the idea is bad.

In the early 2000s, XSLT allowed me as a late teenager with some HTML experience but without real coding skills (I could copy some lines of PHP from various forums and get it to work) to build a somewhat fancy intranet for a local car shop, complete with automatic styling of a feed of car info from a nationwide online sales portal.

Somehow it took me many years, basically until starting uni and taking a proper programming class, before I started feeling like I could realize my ideas in a normal programming language.

XSLT was a kind of tech that allowed a non-coder like me to step by step figure out how to get things to show on the screen.

I think XSLT really has some strong points, in this regard at least.

I have last used XSLT probably about 2 decades ago. Back then XML was king. Companies were transferring data almost always using XML and translating it to a visual web-friendly format with XSLT was pretty neat. Cool tech and very impressive.

Funnily back in the 90s working as a webdesigner in my high school years (whatever you would call web design these days), I remember building a DSSSL- dialect based pipeline to generate websites from a newsfeed published. I still like XSLT transformations. I even used the bananas XI reader [0] to transform actual text using XSLT for transforming and templating . I have, however, met few people that also appreciated this. Often such tooling was replaced once someone else took over the job...

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

I had done a couple of nontrivial projects with XSLT at the time and the problem with it is its lack of good mnemonics, discoverability from source code, and other ergonomics coupled with the fact that it's only used rarely so you find yourself basically relearning after having not used it for a couple of weeks. Template specifity matching is a particularly bad idea under those circumstances.

XSLT technically would make sense the more you're using large amounts of boilerplate XML literals in your template because it's using XML itself as language syntax. But even though using XML as language meta-syntax, it has lots of microsyntax ie XPath, variables, parameters that you need to cram into XML attributes with the usual quoting restrictions and lack of syntax highlighting. There's really nothing in XSLT that couldn't be implemtented better using a general-purpose language with proper testing and library infrastructure such as Prolog/Datalog (in fact, DSSSL, XSLT's close predecessor for templating full SGML/HTML and not just the XML subset, was based on Scheme) or just, you know, vanilla JavaScript which was introduced for DOM manipulation.

Note maintainance of libxml2/libxslt is currently understaffed [1], and it's a miracle to me XSLT (version v1.0 from 1999) is shipping as a native implementation in browsers still unlike eg. PDF.js.

[1]: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913

There is a classic DailyWTF about this technique: https://thedailywtf.com/articles/Sketchy-Skecherscom

> [...] the idea of building a website like this in XML and then transforming it using XSL is absurd in and of itself [...]

In the comments the creators comment on it, like that it was a mess to debug. But I could not find anything wrong with the technique itself, assuming that it is working.

Man, I'm sure this is good and all, but I still have ptsd from trying to understand XSLT back in my uni days 15 years ago...

XSLT was many people’s first foray into functional programming (usually unwilling, because their company got a Google Search Appliance or something). I can’t imagine ever reaching for it again personally, but it was useful and somewhat mind-expanding in its heyday.

I still have PTSD from XSLT in college.

Recently I need a solution for a problem and what XSLT promises is a big part of the solution, so I'm in an existential and emotional crisis.

Early in my career I worked on a carrier's mobile internet portal in the days before smartphones. It was XSLT all the way down, including individual XSLT transforms for every single component the CMS had for every single handset we supported (hundreds) as they all had different capabilities and browser bugs. It was not that fun to write complex logic in haha but was kind of an interesting thing to work on, before iPhone etc came along and everything could just render normal websites.

Just my two cents - the worst pieces of tech I ever worked with in my 40+ year career were Hibernate (second) and XSLT templating for an email templating system around 2005. Would not touch it with a stick if I can avoid it.

I use XSLT to generate a markdown README from a Zotero export XML file. It works well, but some simple things become much harder - sorting, counting, uniqueness.

https://github.com/captn3m0/boardgame-research

It also feels very arcane - hard to debug and understand unfortunately.

Grug-speak is really not that endearing, could do without it entirely, maybe that’s just me. But exploration of old-ish ideas years after their hype cycles can be worthwhile indeed!

We've come full circle again. Yes this works great since many years, XML is just so much clutter.

Many, many years back I used Symphony21[0] for an events website. It’s whole premise was build an XML structure via blueprints and then your theme is just XSLT templates for pages.

Gave it up because it turns out the little things are just a pain. Formatting dates, showing article numbers and counts etc.

[0] https://www.getsymphony.com/

I know XML and XSLT gets a lot of hate. To some extent, the hate for XSLT is warranted. But I have to work with XML files for my job, and it was pretty refreshing to not have to install any libraries to work with them in a web app. We use XML as the serialization format for a spaceflight mission planning app, so there's a lot of complex data that would be trickier to represent with JSON. At the end of the day, HTML is spicy XML, so you can use all the native web APIs to read/write/query/manipulate XML files and even apply XSLT transformations.

I suspect some of the hate towards XML from the web dev community boils down to it being "old". I'll admit that used to have the same opinion until I actually started working with it. It's a little bit more of a PITA than working with JSON, but I think I'm getting a much more expressive and powerful serialization format for the cost of the added complexity.

I remember that I did the same in 2005-2006, just combine XML with XSL(T) to let the browser transform the XML into HTML. After that, also combined XML with XSL(T) with PHP. At that time modern way of working, separate concerns in the frontend. Around 2008-2009 I stopped with this method, and start using e.g. smarty. I still like the idea of using all native methods from browsers, that are described at the W3c. No frameworks or libraries needed, keep it simple and robust.

I think there are just a few that know XSL(T) these days, or need some refresh (like me).

It’s weird to see the hate for xslt. I loved it, but maybe I just like stack based languages.

me busy fixing asan, "illegal instruction", blah blah blah, me sad and frustrated, much scowling.

me come to hn, see xml build system, me happy, much smiling, me hit up arrow, me thank good stranger.

Still maintaining an e-commerce site using XML/xslt and Java/servlet... Passed easily each wave of tech and survived 2 databases migrations (mainframe/db2 => sqlserver => ERP)

You don't even need XML anymore to do XML, "thanks" to iXML where you can provide a grammer of any language and have that work as if you are working with XML. Not saying that is a good idea though.

Me simple man. Me see caveman readme, me like. Sometimes me feel like caveman hitting keyboard to make machine do no good stuff. But sometimes, stuff good. Me no do websites or web things, but me not know about XSLT. Me sometimes hack XML. Me sometimes want show user things. Many many different files format makes head hurt. Me like pretty things though. Me might use this.

Thank you reading specs.

Thank you making tool.

Long time ago somebody wanted to put a searchable directory of products on a CD. It was maybe 100MB. There was no sqlite back then and the best browser you could count on your client having was probably IE 5.5

JS was waay too slow, but it turned out that even back then XSLT was blazing fast. So I basically generated XML with all the data, wrote a simple XSLT with one clever XPath that generated search input form, did the search and displayed the results, slapped the xml file in CD auto-run and called it a day. It was finding results in a second or less. One of my best hacks ever.

Since then I always wanted to make a html templating system that compiles to XSLT and does the HTML generation on client side. I wrote some, but back then Firefox didn't support displaying XML+XSLT directly and the workaround I came up with I didn't like. Then the AJAX came and then JS got faster and client side rendering with JS became viable. But I still think it's a good idea, to send just dynamic XMLs with static XSLTs preloaded and cached, if we ever want to come back to purely server driven request-response flow. Especially if binary format for XML catches on.

https://en.wikipedia.org/wiki/Efficient_XML_Interchange

It's sad how the bloat of '00s enterprise XML made the tech seem outdated and drove everyone to 'cleaner' JSON, because things like XSLT and XPath were very mature and solved a lot of the problems we still struggle with in other formats.

I'm probably guilty of some of the bad practice: I have fond memories of (ab)using XSLT includes back in the day with PHP stream wrappers to have stuff like `<xsl:include href="mycorp://invoice/1234">`

This may be out-of-date bias but I'm still a little uneasy letting the browser do the locally, just because it used to be a minefield of incompatibility

XSLT is probably the #1 reason people get turned off from XML and swear it off as a mistaken technology. I actually quite like XML, so I have been trying lately to tease out exactly what it is that makes XSLT a mistake.

XML is a semi-structured format, which (apart from & < >) includes plain text as a more or less degenerate case. I don't think we have any other realistic format for marking up plain text with arbitrary semantics. You can have, for example, a recipe format with <ingredient> as part of its schema, and it's trivial to write an Xpath to pull out all the <ingredient>s (to put them in your shopping list, or whatever).

Obviously, XSLT is code. Nobody denies this really. One thing about code is that it's inherently structured. Only the craziest of literate programmers would try to embed executable code inside of text. But I don't think that's the biggest problem. Code is special in that special purpose programming languages always leak outside the domain they're designed for. If you try and write a little language that's really well-scoped to transforming XML, you are definitely going to want to call stuff outside it sooner or later.

Combined with the fact that there really isn't any value in ever parsing or processing a stylesheet, it seems like it was doomed never to pan out.

A long time ago, in a dystopic project far, far, away:

Depressed and quite pessimistic about the team’s ability to orchestrate Java development in parallel with the rapid changes to the workbook, he came up with the solution: a series of XSLT files that would automatically build Java classes to handle the Struts actions defined by the XML that was built by Visual Basic from the workbook that was written in Excel.

https://raganwald.com/2008/02/21/mouse-trap.html

HN Discussions:

https://news.ycombinator.com/item?id=120379 · https://news.ycombinator.com/item?id=947952

When I a teenager around 2002, I made what one might call a blogging platform today, and it was using asp, xhtml, xslt, and xml. It worked well in browsers at that time. When I look back on it, it depresses me that I didn't even realize someone could make money hacking together web applications until like a decade later.

To show how wild things got w/ XML and XSLT in the early 2000s, I worked for a company that built an ASIC to parse XML at wire speed and process XSLT natively in the chip - because the anticipated future of the internet was all XML/XSLT. Intel bought the company and the guts made their way into the SSE accelerators.

People love to complain about verbosity of XML, and it looks complicated from a distance, but I love how I can create a good file format based on XML, validate with a DTD and format with XSLT if I need to make it very human readable.

XML is the C++ of text based file formats if you ask me. It's mature, batteries included, powerful and can be used with any language, if you prefer.

Like old and mature languages with their own quirks, it's sadly fashionable to complain about it. If it doesn't fit the use case, it's fine, but treating it like an abomination is not.

Ok, so it might be a long shot, but I would say that

1. the browsers were inconsistent in 1990-2000 so we started using JS to make them behave the same

2. meanwhile the only thing we needed were good CSS styles which were not yet present and consistent behaviour

3. over the years the browsers started behaving the same (mainly because Highlander rules - there can be only one, but Firefox is also coping well)

4. but we already got used to having frameworks that would make the pages look the same on all browsers. Also the paradigm was switched to have json data rendered

5. at the current technology we could cope with server generated old-school web pages because they would have low footprint, work faster and require less memory.

Why do I say that? Recently we started working on a migration from a legacy system. Looks like 2000s standard page per HTTP request. Every action like add remove etc. requires a http refresh. However it works much faster than our react system. Because:

1. Nowadays the internet is much faster

2. Phones have a lot of memory which is wasted by js frameworks

3. in the backend all's almost same old story - CRUD CRUD and CRUD (+ pagination, + transactions)

I looked into this a while ago and concluded that it works fine but browsers are making stroppy noises about deprecating it, so ended up running the transform locally to get html5. Disappointing.

What is this "XSLT works natively in the browser" sourcery? The last time I used XSLT was like 20 years ago- but I used it A LOT, FOR YEARS. In those days you needed a massive wobbly tower of enterprise Java to make it work which sort of detracted from the elegance of XSLT itself. But if XSLT actually works in the browser- has the holy grail of host-anywhere static templating actually been sitting under our noses this whole time?

A (very) relevant post from 3 months ago:

Xee: A Modern XPath and XSLT Engine in Rust

https://news.ycombinator.com/item?id=43502291

In my first job, when .net didn't yet exist, xml + xslt was the templating engine we used for html and (html) e-mail and sometimes csv. I'd write queries in sql server using "for xml" and it would output all data needed for a page and feed it to an xsl template (all server side) which would output html. Microsoft had a caching xsl parser that would result in less than 10ms to load such a page. Up until we though "hey, let's start using xml namespaces, that sounds like a good idea!". Was a bit less fun after that! Looking back it was a pretty good stack, and it would still work fine today imho. I never started disliking it, but after leaving that job I never wrote another stylesheet.

> how I can run it? open XML file > open blog.xml -a Safari

This didn't work for me on my browsers (FF/Chrome/Safari) on Mac, apparently XSLT only works there when accessed through HTTP:

    $ python3 -m http.server --directory .
    $ open http://localhost:8000/blog.xml

I remember long hours using XSLT to transform custom XML formats into some other representation that was used by WXWindows in the 2000s, maybe I should give it a shot again for Web :)

I worked with XSLT almost from the beginning of my career and it was a blessing in disguise. Shoutout to Michael Kay.

XML needs a renaissance because it solves problems modern formats still fumble with. Robust schema validation, namespaces, mixed content, and powerful tooling like XPath/XSLT. It's verbose, yes. It's can be made to look like shit and make you wanna throw up, but also battle-tested and structured for complexity. We ditched it too soon chasing simplicity.

Whoa, I just realized how much Zope’s page templates were basically XSLT that looked slightly different.

This gives me new appreciation for how powerful XSLT is, and how glad I am that I can use almost anything else to get the same end results. Give me Jinja or Mustache any day. Just plain old s-exprs for that matter. Just please don’t ever make me write XML with XML again.

Throw in php in the mix and you have a wonderful solution for templating with bullet proof standards:

// XML $xml_doc = new DOMDocument(); $xml_doc->load("file1.xml");

// XSL $xsl_doc = new DOMDocument(); $xsl_doc->load("file.xsl");

// Proc $proc = new XSLTProcessor(); $proc->importStylesheet($xsl_doc); $newdom = $proc->transformToDoc($xml_doc);

print $newdom->saveXML();

XSLT lacks functionality? No problem, use php functions in xslt: https://www.php.net/manual/en/xsltprocessor.registerphpfunct...

RTFM

All that fuss just to deploy a static website on Vercel? :p

This gist page uses "me not know, but me know now" to express even a cave man can do it (no offense to cavemen).

I learned one thing: Apply XSL to an XML by editing the XML. But can we flip it?

The web works in MVC ways. Web servers are controllers that output the view populated with data.

(XML) Data is in the backend. (XSLT) View page is the front end. (XPath) Query filters is requesting (XML) data like controllers do.

You call XML-based transformation "zero-config", I feel old.

I wonder when browsers are going to start dropping support for old-web stuff.

Cant take it seriously with that language, sorry

Abandoning XML tech is was and forever will be the webs biggest mistake. The past 20 years has been just fumbling about trying to implement things that it would have provided easily.

Thanks, I've been wanting this for 25 years.

internet Explorer also had the ability to render XML directly into HTML tables without using any JS using the datasrc attribute. I had to deal with this nonsense early in my career in the early 2000s, along with people regularly complaining that it did not work in Firefox.

https://learn.microsoft.com/en-us/previous-versions/windows/...

no more xml

me have make vomit from seeing xml

Blizzard uses/used XSLT for WoW.

Huh? If I have to write XML why bother. I would do HTML directly.

> can use HTML import? nope not exist

Well, Apache says hi: https://httpd.apache.org/docs/2.4/howto/ssi.html (Look for "include")

Anyone with recent real-world experience?

From talking to AI, it seems the main issues would be:

- SEO (googlebot)

- Social Media Sharing

- CSP heavy envs could be trouble

Is this right?

- article schema - page schema - non-technical users can author & upload

And the browser takes care of the rendering.

Good times.

Good old xslt. Was quite in the center of attention when strict xml was still a next standard candidate. html5 won.

i have a static website with a menu. keeping the menu synchronized over the half dozen pages is a pain.

my only option to fix this are javascript, xslt or a server side html generator. (and before you ask, static site generators are no better, they just make the generation part manual instead of automatic.)

i don't actually care if the site is static. i only care that maintenance is simple.

build tools are not simple. they tend to suffer from bitrot because they are not bundled with the hosting of the site or the site content.

server side html generators (aka content management systems, etc.) are large and tie me to a particular platform.

frontend frameworks by default require a build step and of course need javascript in the browser. some frameworks can be included without build tools, and that's better, but also overkill for large sites. and of course then you are tied to the framework.

another option is writing custom javascript code to include an html snippet from another file.

or maybe i can try to rig include with xslt. will that shut up the people who want to view my site without javascript?

at some point there was discussion for html include, but it has been dropped. why?

XML is great, one just need to have the appropriate tooling. XSLT, like XSD, is XML too, so the same tooling apply to those as well.

If you're manually writing the <>-stuff in an editor you're doing it wrong, do it programmatically or with applications that abstract it away.

Use things like JAXB or other mature libraries, eXist-db (http://exist-db.org), programs that can produce visualisations and so on.

Blast from the past:

"XSLT is a failure wrapped in pain"

original article seems offline but relevant HN discussion: https://news.ycombinator.com/item?id=8708617

A trip down memory lane to the Museum of Obsolete Technology (with video demos):

Here's how use XSLT to make Punkemon Pie Menus! [ WARNING: IE 5 required! ;) ]

The "htc" files are ActiveX components written in JScript, aka "Dynamic HTML (DHTML) behaviors":

https://en.wikipedia.org/wiki/HTML_Components

>HTML Components (HTCs) are a legacy technology used to implement components in script as Dynamic HTML (DHTML) "behaviors" in the Microsoft Internet Explorer web browser. Such files typically use an .htc extension and the "text/x-component" MIME type.

JavaScript Pie Menus, using Internet Explorer "HTC" components, xsl, and xml:

https://www.youtube.com/watch?v=R5k4gJK-aWw

>Pie menus for JavaScript on Internet Explorer version 5, configured in XML, rendered with dynamic HTML, by Don Hopkins.

punkemonpiemenus.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

punkemon.xsl: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

punkemon.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

punkemonpiemenus.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenu.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

Also an XML Schema driven pie menu editor:

piemenuschemaeditor.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenuschemaeditor.xsl: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenuschema.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenuschemaeditor.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenuxmlschema-1.0.xsd: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

Here's an earlier version that uses ActiveX OLE Control pie menus, xsl, and xml, not as fancy or schema driven:

ActiveX Pie Menus:

https://www.youtube.com/watch?v=nnC8x9x3Xag

>Demo of the free ActiveX Pie Menu Control, developed and demonstrated by Don Hopkins.

ActiveXPieMenuEditor.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenueditor.xsl: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenueditor.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenueditor.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenumetadata.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

Fasteroids (Asteroids comparing Pie Menus -vs- Linear Menus):

fasteroids.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

fasteroids.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

If that wasn't obsolete enough, here is the "ConnectedTV Skin Editor". It was a set of HTC components, XML, and XML Schemas, and a schema driven wysiwyg skin editor for ConnectedTV: a Palm Pilot app that turned your Palm into a personalized TV guide + smart remote.

Full fresh lineup of national and local broadcast + TiVo + Dish TV guides with customized channel groups, channel and show filtering and favorites, hot sync your custom tv guide with just the shows you watch, weeks worth of schedules you could download and hot sync nightly with the latest guide updates.

Integrated with trainable consumer IR remote controller with custom touch screen user interfaces (with 5-function "finger pie menus" that let you easily tap or stroke up/down/left/right to stack up multiple gesture controls on each button (conveniently opposite and orthogonal for volume up/down, channel next/previous, page next/previous, time forward/back, show next/previous, mute/unmute, favorite/ignore, etc -- finger pies are perfect for the kind of opposite and directionally oriented commands on remote controls, and you need a lot fewer 5-way buttons than single purpose physical buttons on normal remotes, so you could pack a huge amount of functionality into one screen, or have any number of less dense screens, customized for just the devices you have and features you use. Goodbye TiVo Monolith Monster remote controls, since only a few of the buttons were actually useful, and ConnectedTV could put 5x the number of functions per gesture activated finger pie menu button.

The skin editor let you make custom user interfaces by wysiwyg laying out and editing out any number of buttons however you liked and bind tap/left/right/up/down page navigation, tv guide time and channel and category navigation, sending ir commands to change the channel (sends multi digits per tap on station or show so you can forget the numbers), volume, mute, rewind/skip tivo, etc.

Also you could use finger pies easily and reliably on the couch in a dark room with your finger instead of the stylus. Users tended to lose their Palm stylus in the couch cushions (which you sure don't wanna go fishing around for if JD Vance has been visiting) while eating popcorn and doing bong hits and watching tv and patting the dog and listening to music and playing video games in their media cave, so non-stylus finger gesture control was crucial.

Finger pies were was like iPhone swipe gestures, but years earlier, much cheaper (you could get a cheap low end Palm for dirt cheap and dedicate it to the tv). And self revealing (prompt with labels and give feedback (with nice clicky sounds) and train you to use the gestures efficiently) instead of invisible mysterious iPhone gestures you have to discover and figure out without visual affordances. After filtering out all the stuff you never watch and favoriting the ones you do, it was much easier to find just the shows you like and what was on right now.

More on the origin of the term "Finger Pie" for Beatles fans (but I digress ;) :

https://news.ycombinator.com/item?id=16615023

https://donhopkins.medium.com/gesture-space-842e3cdc7102

It was really nice to have the TV guide NOT on the TV screen taking you away from watching the current show, and NOT to have to wait 10 minutes while it slowly scrolled the two visible rows to through 247 channels to finally see the channel you wanted to watch (by that time you'll miss a lot of the show, but be offered lots of useless shit and psychic advice to purchase from an 800 number with your credit card!).

Kids these days don't remember how horrible and annoying those slow scrolling TV guides with ads for tele-psychics and sham wows and exercise machines used to be.

I can objectively say that it was much better than the infamous ad laden TV Guide Scroll:

https://www.youtube.com/watch?v=JkGR29TSueM

Using those slow scrolling non-interactive TV guides with obnoxious ads was so painful that you needed to apply HEAD ON directly to the forehead again and again and again to ease the pain.

https://www.youtube.com/watch?v=Is3icfcbmbs

You could use the skin editor to create your own control panels and buttons for whatever TV, TiVO, DVR, HiFi, Amplifier, CD, DVD, etc players you wanted to use together. And we had some nice color hires skins for the beautiful silver folding Sony Clie.

https://en.wikipedia.org/wiki/Sony_CLI%C3%89_PEG-TG50

It was also nice to be able to curate and capture just the buttons you wanted for the devices that you actually use together, and put them all onto one page, or factor them out into different pages per device. You could ignore the 3 digit channel number and never peck numbers again, just stroke up on your favorite shows to switch the channel automatically.

We ran out of money because it was so expensive to license the nightly feed of TV guide (downloading a huge sql dump every night of the latest schedules as they got updated), and because all of our competitors were just stealing their data by scraping it from TV guide web sites instead of licensing it legally. (We didn't have Uber or OpenAI to look up to for edgy legal business practice inspiration.)

Oh well, it was fun while it lasted, during the days that everybody was carrying a Palm Pilot around beaming their contacts back and forth with IR. What a time that was, right before and after 9/11 2001. I remember somebody pointedly commented that building a Palm app at that time in history was kind of like opening a flower shop at the base of the World Trade Center. ;(

https://github.com/SimHacker/ConnectedTVSkinEditor

https://www.pencomputing.com/palm/Pen44/connectedTV.html

https://uk.pcmag.com/first-looks/29965/turn-your-palm-into-a...

Connected TV User Guide:

Overview: https://donhopkins.com/home/ConnectedTVUserGuide/Guide1-Over...

Setting Up: https://donhopkins.com/home/ConnectedTVUserGuide/Guide2-Sett...

Using: https://donhopkins.com/home/ConnectedTVUserGuide/Guide3-Usin...

Memory: https://donhopkins.com/home/ConnectedTVUserGuide/Guide4-Memo...

Sony: https://donhopkins.com/home/ConnectedTVUserGuide/Guide5-Sony...

I built an actual shipping product that used this approach over 25 years ago. The server would have the state of every session, that would be serialized to xml, and then xslt templates would be used to render html. Idea was that this would allow customers to customize the visual appearance of the webpages, but xslt was too difficult. Not a success.

https://packages.grpc.io is an XML page styled with XSLT updated by a bash script in CI

I worked with XSLT a few companies ago. They had several XSLT documents as a transformation to various output formats (this was a pretty minor part of the overall product).

I'm not sure I've ever seen something less popular. Feature requests and the odd bug would build up, eventually an engineer would be assigned to it for a week and they'd fix a bunch of things, then essentially would rather quit than keep doing it, so next time it'd be someone else's turn.

I don't even think it was particularly bad. It seemed like it was just always like that. Thank goodness it isn't so popular any more so it doesn't turn up jammed into random places as it did then.

TBH if we were going with old, bad standards, I would rather write m4 macros. It’s preinstalled everywhere too, unlike a browser.

I remember learning XSLT from this:

https://zvon.org/xxl/XSLTutorial/Books/Output/contents.html

Still a great resource.

--

I would say CSS selectors superseeded XPath for the web. If one could do XSLT using CSS selectors instead, it would feel fresh and modern.

I used XSLT in the past for trade message transformation from one format of XML (produced by an upstream system) to another (used by the downstream consuming system). It works reasonably well for not overly complex stuff but debugging things are a pain once the complexity increases. Prefer to not do that again.