Top
Best
New

Posted by _kush 5 days ago

XSLT – Native, zero-config build system for the Web(github.com)
389 points | 324 commentspage 4
petesergeant 5 days ago|
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...

bmacho 5 days ago|
Files are missing from the repo(?). What about util-map.xsl, test-map.xsl, util-serialize.xsl
petesergeant 5 days ago||
I've updated this, as well as included instructions on running the built-in unit tests, which are of course also written in XSLT.
mattbis 4 days ago||
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
w3news 5 days ago||
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).

bmacho 4 days ago||
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.

tomduncalf 5 days ago||
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.
calmbonsai 5 days ago|
Same. I was part of the mobile media messaging (WAP) roll-out at Vodafone. Oh man, XSLT was one of those "theoretical" W3C languages that (rightfully) aged like milk. Never again.
tomduncalf 5 days ago||
Ha! I was at Orange. I suspect all the carriers had similar setups. Yeah I don’t miss working with that lol
enqk 5 days ago||
I worked in the same period for a finnish startup (iobox.fi) that ended up being acquired by telefonica.

Our mobile and web portal was made of j2ee services producing XML which were then transformed by XSLT into HTML or WAP

At the time it blew me away that they expected web designers to work in an esoteric language like that

But it was also nicely separated

mlok 4 days ago||
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.
jbaiter 5 days ago||
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.
evanelias 4 days ago|
Yes! In the mid 00's, two places I worked (major US universities) used Cocoon heavily. It was a good fit for reporting systems that had to generate multiple output formats, such as HTML and PDF.
cess11 5 days ago||
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.

pjmlp 5 days ago||
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,...

windowsworkstoo 5 days ago||
Agree, when MS moved their office file formats to xml, I made plenty of money building extremely customizable templating engines all based on a very small amount of XSLT - it worked great given all the structure and metadata available in xml
masklinn 5 days ago||
> many developers always had issues understanding the FP approach of its design, looking beyond the XML.

It would probably help if xslt was not a god-awful language even before it was expressed via an even worse syntax.

pjmlp 5 days ago||
The root cause is that many failed to grasp XML isn't to be manually written by hand on vi, rather it is a tool oriented format.

Now ironically, we have to reach for tooling to work around the design flaws of json and yaml.

masklinn 5 days ago||
> The root cause is that many failed to grasp XML isn't to be manually written by hand on vi, rather it is a tool oriented format.

That reads like an indictment of using XML for a programming language.

Not that it has anything to do with the semantics of XSLT.

pjmlp 5 days ago||
I don't see why separate both.

XML is tooling based, and there have been plenty of tools to write XSLT on, including debugging and processing example fragments, naturally not something vi crowd ever became aware of amid their complaints.

em-bee 5 days ago|
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?

rsolva 5 days ago||
I recently tried building a website using Server Side Includes (SSI) with apache/nginx to make templates for the head, header and footer. Then I found myself missing the way Hugo does things, using a base template and injecting the content into the base template instead.

This was easy do achieve with PHP with a super minimal setup, so I thought, why not? Still no build steps!

PHP is quite ubiquitous and stable these days so it is practically equivalent to making a static site. Just a few sprinkles of dynamism to avoid repeting HTML all over the place.

bambax 5 days ago|||
> i have a static website with a menu. keeping the menu synchronized over the half dozen pages is a pain

You can totally do that with PHP? It can find all the pages, generate the menu, transform markdown to html for the current page, all on the fly in one go, and it feels instantaneous. If you experience some level of traffic you can put a CDN in front but usually it's not even necessary.

em-bee 4 days ago||
that's the server side html generator i already mentioned. ok, this one is not large, but it still ties me to a limited set of server platforms that support running php. and if i have to write code i may as well write javascript and get a platform independent solution.

the point is, none of the solutions are completely satisfactory. every approach has its downsides. but most critically, all this complaining about people picking the wrong solution is just bickering that my chosen solution does not align with their preference.

my preferred solution btw is to take a build-less frontend framework, and build my site with that. i did that with aurelia, and recently built a proof of concept with react.

ndriscoll 4 days ago||
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 <my-menu> in the page, and then the template just gives a rule to expand that to your menu.

em-bee 4 days ago||
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)
ndriscoll 4 days ago||
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):

    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
      <xsl:output method="html"/>
      <xsl:template match="nav-menu">
        <nav>
          <ul>
            <li><a href="page1.xhtml">Page 1</a></li>
            <li><a href="page2.xhtml">Page 2</a></li>
            <li><a href="contact.xhtml">Contact</a></li>
          </ul>
        </nav>
      </xsl:template>

      <xsl:template match="*">
        <xsl:copy><xsl:apply-templates/></xsl:copy>
      </xsl:template>
    </xsl:stylesheet>
Then here's a page to use it:

    <?xml version="1.0" encoding="UTF-8"?>
    <?xml-stylesheet type="text/xsl" href="templates.xsl"?>
    <html>
      <head>
        <title>Welcome to my page</title>
      </head>
      <body>
        <nav-menu/>
        <h1>Welcome to the page!</h1>
        <p>This is the content</p>
      </body>
    </html>
Anywhere you want more templates, you add another

    <xsl:template match="my-element">
      <!-- HTML for my custom element -->
    </xsl:template>
And now you can use your custom <my-element/> 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.

em-bee 3 days ago||
you are right. xslt is not that bad. especially not for simple cases. your example would be just about enough for my website. thanks for that. i have used xslt before, but that was a long time ago.

however if you read through the comments there are a lot of people complaining, so they definitely see a downside to using xslt. as for longevity, well, a search led me to a chrome proposal to remove it that was made 10 years ago and ultimately rejected at the time. so maybe you are right about that too.

rossant 5 days ago||
Frames. Use frames. They're the future. Definitely.
em-bee 4 days ago||
on stackoverflow on the question how to include html, one answer does indeed suggest frames...
More comments...