XSLT – Native, zero-config build system for the Web • Hacker News Board

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

#271

Post by soulofmischief » Fri, Jun 27, 2025, 5:06 PM UTC

em-bee wrote: post #190

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…

Those were defined as machine language meant for machine talking to machine i don't believe this is true. machine language doesn't need the kind of verbosity that xml provides. sgml/html/xml were designed to allow humans to produce machine readable data. so they were meant for humans to talk to machines and vice versa.

Yes, I think the main difference is having imperative vs declarative computation. With declarative computation, the performance of your code is dependent on the performance and expressiveness of the declarative layer, such as XML/XSLT. XSLT lacks the expressiveness to get around its own performance limitations.

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

#272

Post by kbolino » Fri, Jun 27, 2025, 5:09 PM UTC

alganet wrote: post #266

kbolino wrote: post #264

Earlier quoted context omitted.

They were never good. They were always broken in these ways. For some sites, it wasn't a big deal, because the only link that ever mattered was the main link. But a lot of places that used frames were like the POSIX specs or Javadocs, and they sucked for anything other than immediate, personal use. They were not deprecated because designers hated scrollbars (they do hate them, and that sucks too, but it's beside the…

> They were never good They were good enough. > For some sites, it wasn't a big deal Precisely my point. > POSIX specs or Javadocs Hey, they work for me. > the best way to fix these problems with frames is to use JavaScript. Some small amounts of javascript. Mainly, proxy the state for the main frame to the address bar. No need for virtual dom, babel, react, etc. -- _Again_, you're arguing like I'm defending frames f…

Directionally correct but badly done can poison an idea. Frames sucked and never got better.

Along with other issues, this gave rise to AJAX and SPAs and JS frameworks. A big part of how we got where we are today is because the people making the web standards decided to screw around with XHTML and "the semantic web" (another directionally correct but badly done thing!) and other BS for about a decade instead of improving the status quo.

So we can and often should return to ancestor but if we're going to lay blame and trace the history, we ought to do it right.

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

#273

Post by imtringued » Fri, Jun 27, 2025, 5:20 PM UTC

smartmic wrote: post #82

rsolva wrote: post #71

Earlier quoted context omitted.

Browsers support XSLT v1.0 only, and from what I understand, there has been talk of depricating it. I would rather that they introduced support for v3, as that would make it easier to serving static webpages with native support for templating.

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 touch NPM, webpack, React, JSX, etc.

Blocking first party JS is lunacy by the way.

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

#274

Post by ndriscoll » Fri, Jun 27, 2025, 5:29 PM UTC

em-bee wrote: post #186

ndriscoll wrote: post #183

Earlier quoted context omitted.

You didn't actually indicate a downside to using xslt, and yes it would fit your use case of a static include for a shared menu, though the better way to do it is to move all of the shared pieces of your site into the template and then each page is just its content. Sort of like using a shared CSS file. To just do the menu, if your site is xhtml, IIRC you could link to the template, use a in the page, and then the te…

the downside to xslt is xslt itself, and lack of maintenance of xslt support in the browser. (browsers only supports xslt 1.0 and it looks like even that may be dropped in the future, making its use not futureproof without server side support)

I'm not sure how xslt itself is a downside. It's a pretty natural template language to use if you already know HTML. You don't need more than 1.0 for your simple use-case. e.g. here's a complete example (tested in Firefox and Chrome):

Then here's a page to use it:

    
    
    
      
        Welcome to my page
      
      
        
        Welcome to the page!
        This is the content

Anywhere you want more templates, you add another

And now you can use your custom directly in your HTML. You can of course also have attributes and children for your custom elements and do all sorts of programming things like variables and conditionals with XSLT if you dip your toes in a little further.

As far as longevity goes, it's lasted 25 years now, so that's something. As far as I know, there are a bunch of government services out there that still use it (which is great! Governments should be making things cheap and simple, not chasing trends), so removing support for it is somewhat infeasible. If it were removed, you could always make a Makefile that runs `xsltproc` on all of your xhtml files to spit out html files, so worst case you have a build step, but it's the world's easiest build step.

One nice benefit of doing things this way is that just like with CSS files, the more you pull into the template, the smaller all of your pages can be since you have a single static file for most of the page, and each page is only its unique data. If you lean into it a little more and are building an application, you can also have each page be its own "API endpoint" by returning XML in your native domain model. Databases can also output such XML directly, so you can make highly efficient single queries to build entire pages.

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

#275

Post by jerf » Fri, Jun 27, 2025, 5:36 PM UTC

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…

It would at least be an interesting project. If someone put the elbow grease into it it is distinctly possible that an XSLT stylesheet could be not just converted to JS (which is obviously true and just a matter of effort), but converted to something that is at least on the edge of human usable and editable, and some light refactoring away from being decent code.

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

#276

Post by ako » Fri, Jun 27, 2025, 5:42 PM UTC

nolok wrote: post #245

ako wrote: post #221

Earlier quoted context omitted.

There is JSLT: https://github.com/schibsted/jslt and it can be useful if you need to transform a json document into another json structure.

The people who made that are either very funny in a sarcastic, way or in severe lack of a history lesson of the area they're working in.

What is a better alternative if you just need to transform JSON from one structure to another JSON structure?

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

#277

Post by alganet » Fri, Jun 27, 2025, 5:50 PM UTC

kbolino wrote: post #272

alganet wrote: post #266

Earlier quoted context omitted.

> They were never good They were good enough. > For some sites, it wasn't a big deal Precisely my point. > POSIX specs or Javadocs Hey, they work for me. > the best way to fix these problems with frames is to use JavaScript. Some small amounts of javascript. Mainly, proxy the state for the main frame to the address bar. No need for virtual dom, babel, react, etc. -- _Again_, you're arguing like I'm defending frames f…

Directionally correct but badly done can poison an idea. Frames sucked and never got better. Along with other issues, this gave rise to AJAX and SPAs and JS frameworks. A big part of how we got where we are today is because the people making the web standards decided to screw around with XHTML and "the semantic web" (another directionally correct but badly done thing!) and other BS for about a decade instead of impro…

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 era finally gave way to the jQuery era. Roughly around this time, browser standards got their shit together... but vendors didn't.

Finally, the jQuery era ended with the rise of full JS frameworks (backbone first, then ember, winjs, angular, react). Vendors operating outside standards still dominate in this era.

There's at least two whole generations between frames and SPAs. That's why I used the word "ancestor", it's 90s tech I barely remember because I was a teenager. All the other following eras I lived through and experienced first hand.

The poison on the frames idea wore off ages ago. The fact that websites not made with them resemble their use is a proof of that, they just don't share the same implementation. The "idea" is seen with kind eyes today.

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

#278

Post by jimbokun » Fri, Jun 27, 2025, 5:51 PM UTC

nolok wrote: post #115

badmintonbaseba wrote: post #81

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,…

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…

It was very odd that a simple markup language was somehow seen as the savior for all computing problems.

Markup languages are a fine and useful and powerful way for modeling documents, as in narrative documents with structure meant for human consumption.

XML never had much to recommend it as the general purpose format for modeling all structured data, including data meant primarily for machines to produce and consume.

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

#279

Post by rsolva » Fri, Jun 27, 2025, 5:52 PM UTC

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…

I speak only for my self, but I greatly value having no dependencies or build processes. Just put the files on a web server and have it run for the next 20 years.

It might not scale for larger businesses, but for regular people on the web who just want to put something out in the world and have minimal churn keeping it up, it can have great value!

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

#280

Post by jimbokun » Fri, Jun 27, 2025, 6:00 PM UTC

colejohnson66 wrote: post #209

diggan wrote: post #138

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 Generally speaking I feel like this is true for a lot of stuff in programming circles, XML included. New technology appears, some people play around with it. Others come up with using it for something else. Give it some time, and eventually people start putting it everywhere…

A controversial opinion, but JSON is that too. Not as bad as XML was (̶t̶h̶e̶r̶e̶'̶s̶ ̶n̶o̶ ̶"̶J̶S̶L̶T̶"̶)̶, but wasting cycles to manifest structured data in an unstructured textual format has massive overhead on the source and destination sides. It only took off because "JavaScript everywhere" was taking off — performance be damned. Protobufs and other binary formats already existed, but JSON was appealing because…

Both XML and JSON were poor replacements for s-expressions. Combined with Lisp and Lisp macros, a more powerful data manipulation text format and language has never been created.