Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XSLT – Native, zero-config build system for the Web

github.com

Post reply on HN
Print view View original

291–300 of 337 posts

Re: XSLT – Native, zero-config build system for the Web

#291

Post by bokchoi »

sam_lowry_ wrote: post #170
nithril wrote: post #146

Earlier quoted context omitted.

XSLT/XPath have evolved since XSLT 1.0. Features are now available like key (index) to greatly speedup the processing. Good XSLT implementation like Saxon definitively helps as well on the perf aspect. When it comes to transform XML to something else, XSLT is quite handy by structuring the logic.

Keys were a thing in XSLT 1.x already. XSLT 2+ was more about side effects. I never really grokked later XSLT and XPath standards though. XSLT 1.0 had a steep learning curve, but it was elegant in a way poetry is elegant because of extra restrictions imposed on it compared to prose. You really had to stretch your mind to do useful stuff with it. Anyone remembers Muenchian grouping? It was gorgeous. Newer standards lo…

I haven't tried it yet, but I came across this alternate syntax for XSLT which is much more friendly:

https://github.com/Juniper/libslax/wiki/Intro

It looks like it was developed by Juniper and has shipped in their routers?

Re: XSLT – Native, zero-config build system for the Web

#292

Post by bokchoi »

yoz wrote: post #269
jerf wrote: post #205

Earlier quoted context omitted.

"Newer standards lost elegance and kept the ugly syntax." My biggest problem with XSLT is that I've never encountered a problem that I wouldn't rather solve with an XPath library and literally any other general purpose programming language. When XSLT was the only thing with XPath you could rely on, maybe it had an edge, but once everyone has an XPath library what's left is a very quirky and restrictive language that…

Serious question: would it be worth the effort to treat XSLT as a compilation target for a friendlier language, either extant or new? There's clearly value in XSLT's near-universal support as a web-native system. It provides templating out of the box without invoking JavaScript, and there's demand for that[1]. But it still lacks decent in-browser debugging which JS has in spades. [1] https://justinfagnani.com/2025/06…

I just posted this in another comment: https://github.com/Juniper/libslax/wiki/Intro

Re: XSLT – Native, zero-config build system for the Web

#293

Post by bokchoi »

echelon wrote: post #212
nithril wrote: post #146

Earlier quoted context omitted.

XSLT/XPath have evolved since XSLT 1.0. Features are now available like key (index) to greatly speedup the processing. Good XSLT implementation like Saxon definitively helps as well on the perf aspect. When it comes to transform XML to something else, XSLT is quite handy by structuring the logic.

XSLT just needs a different, non-XML serialization. XML (the data structure) needs a non-XML serialization. Similar to how Semantic Web's Owl has four different serializations, only one of them being the XML serialization. (eg. Owl can be represented in Functional, Turtle, Manchester, Json, and N-triples syntaxes.)

I just posted this in another comment: https://github.com/Juniper/libslax/wiki/Intro

Re: XSLT – Native, zero-config build system for the Web

#294

Post by ndriscoll »

imtringued wrote: post #273
smartmic wrote: post #82

Earlier quoted context omitted.

I'm also more concerned about depreciation risk. However, you can still do a lot with XSLT 1.0. There is also SaxonJS, which allows you to run XSLT 3.0. However, embedding JavaScript to use XSLT defeats the purpose of this exercise.

It doesn't really defeat the purpose. It just shows how much fuss about avoiding JS is a sign of insisting on ideological purity rather than accomplishing any particular goal. What exactly is the difference between generating HTML using the browser's XLST 1.0 runtime and SaxonJS's XLST 3.0 runtime? Before you say the goal is to not have to deal with JS, then you've already accomplished that goal. You don't need to to…

> What exactly is the difference between generating HTML using the browser's XLST 1.0 runtime and SaxonJS's XLST 3.0 runtime?

Several hundred kB (compressed) of runtime, for one. It could make sense for browsers to have something like that built-in like they did with pdf.js, though Saxon is proprietary so it would not be that thing.

Re: XSLT – Native, zero-config build system for the Web

#295

Post by thechao »

jraph wrote: post #249
thechao wrote: post #199

Earlier quoted context omitted.

Can you name a non-Saxon XSLT processor? I'd really like one. Preferably, open-source.

- Browsers are XSLT (1.0) processors. - Xee: https://github.com/Paligo/xee - xrust: https://docs.rs/xrust/latest/xrust/xslt/ - XJSLT (compiles XSLT to JS): https://github.com/egh/xjslt Xee is WIP AFAIK and I don't know the maturity of xrust and XJSLT.

Yeah... I posted too quickly: I want XSLT 3. The 1 & 2 specs are good first attempts, but are very difficult to use, effectively. As another poster also commented: it'd be nice if the implementation wasn't tied to XML, as well!

Also, I want a cookie & a pony.

Re: XSLT – Native, zero-config build system for the Web

#296

Post by bogeholm »

homebrewer wrote: post #241
0x445442 wrote: post #182

Earlier quoted context omitted.

IDK, the XML hysteria is similar by comparison to the dynamic and functional languages hysterias. And it pales in comparison to the micro services, SPA and the current AI hysterias.

IMHO it's pretty comparable, the difference is only in the magnitude of insanity. After all, the industry did crap out these hardware XML accelerators that were supposed to improve performance of doing massive amounts of XML transformations — is it not the GPU/TPU craze of today? https://en.wikipedia.org/wiki/XML_appliance E.g. https://www.serverwatch.com/hardware/power-up-xml-data-proce...

From your first link

> An XML appliance is a special-purpose network device used to secure, manage and mediate XML traffic.

Holy moly

Re: XSLT – Native, zero-config build system for the Web

#297

Post by p0w3n3d »

kbolino wrote: post #237
alganet wrote: post #219

Earlier quoted context omitted.

> full page reloads grug remember ancestor used frames then UX shaman said frame bad all sour faced frame ugly they said, multiple scrollbar bad then 20 years later people use fancy js to emulate frames grug remember ancestor was right https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Classic frames were quite bad. Every frame on a page was a separate, independent, coequal instance of the browser engine. This is almost never what you actually want. The header/footer/sidebar frames are subordinate and should not navigate freely. Bookmarks should return me to the frameset state as I left it, not the default for that URL. History should contain the frameset state I saw, not separate entries for each…

Iframes are no longer the thing? I must have slept over this scene

Re: XSLT – Native, zero-config build system for the Web

#298

Post by SoftTalker »

vjvjvjvjghv wrote: post #282
nolok wrote: post #115

Earlier quoted context omitted.

It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them, doesn't matter if XSLT or SOAP or even XHTML in a way ... Those were defined as machine language meant for machine talking to machine, and invariably something go south and it's not really made for us to intervene in the middle; it can be done but it's way more work than it s…

Now we have "JSON as savior". I see it way too often where new people come into a project and the first thing they want to do is to replace all XML with JSON, just because. Never mind that this solves basically nothing and often introduces its own set of problems. I am not a big fan of XML but to me it's pretty low in the hierarchy of design problems.

The only problem with XML is the verbosity of the markup. Otherwise it's a nice way to structure data without the bizarre idiosyncracies of YAML or JSON.

Re: XSLT – Native, zero-config build system for the Web

#299

Post by alganet »

kbolino wrote: post #284
alganet wrote: post #277

Earlier quoted context omitted.

Your history is off, and you are mixing different eras and browser standards with other initiatives. Frames gave place to (the incorrect use of) tables. The table era was way worse than it is today. Transparent gif spacers, colspan... it was all hacks. The table era gave birth to a renewal of web standards. This ran mostly separately from the semantic web (W3C is a consortium, not a single central group). The table e…

I feel like we're mostly in violent agreement. The key point about frames in the original context of this thread as I understood it was that they allowed a site to only load the content that actually changes. So accounting for the table-layout era doesn't really change my perspective: frames were so bad, that web sites were willing to regress to full-page-loads instead, at least until AJAX came along -- though that a…

> I feel like we're mostly in violent agreement.

Probably, yes!

> So accounting for the table-layout era doesn't really change my perspective: frames were so bad, that web sites were willing to regress to full-page-loads instead

That's where we disagree.

From my point of view, what brought sites to full page loads were designers. Design folk wanted to break out of the "left side navigation, right content" mold and make good looking visual experiences.

This all started with sites like this:

https://www.spacejam.com/1996/

This website is a interstitial fossil between frames and full table nightmare. The homepage represents what (at the time) was a radical way of experiencing the web.

It still carries vestiges of frames in other sections:

https://www.spacejam.com/1996/cmp/jamcentral/jamcentralframe...

However, the home is their crown jewel and it is representative of the years that followed.

This new visual experience was enough to discard partial loading. And for a while, it stayed like this.

JS up to this point was still a toy. DHTML, hover tricks, trinkets following the mouse cursor. It was unthinkable to use it to manage content.

It was not until CSS zen garden, in 2003, that things started to shift:

https://csszengarden.com/pages/about/

Now, some people were saying that you could do pretty websites without tables. By this time, frames were already forgotten and obsolete.

So, JS never killed frames. There was a whole generation in between that never used frames, but also never used JS to manage content (no AJAX, no innerHTML shinenigans, nothing).

Today, websites look more like the POSIX spec (in structure and how content is loaded) than the SpaceJam website that defined a generation. The frames idea is kind of back in town. It doesn't matter that we don't use the same 90s tech, they were right about content over style, right about partial loading, right about a lot of structural things.

Re: XSLT – Native, zero-config build system for the Web

#300

Post by kbolino »

p0w3n3d wrote: post #297
kbolino wrote: post #237

Earlier quoted context omitted.

Classic frames were quite bad. Every frame on a page was a separate, independent, coequal instance of the browser engine. This is almost never what you actually want. The header/footer/sidebar frames are subordinate and should not navigate freely. Bookmarks should return me to the frameset state as I left it, not the default for that URL. History should contain the frameset state I saw, not separate entries for each…

Iframes are no longer the thing? I must have slept over this scene

By "classic frames", I mean not . Though iframes have some of the same problems, they don't have all of the same problems. They also tend to be used differently, though you can certainly create a frameset-like experience using only iframes.
Post reply on HN