Posted by _kush 5 days ago
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 think there are just a few that know XSL(T) these days, or need some refresh (like me).
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.
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
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.
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.
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 would probably help if xslt was not a god-awful language even before it was expressed via an even worse syntax.
Now ironically, we have to reach for tooling to work around the design flaws of json and yaml.
That reads like an indictment of using XML for a programming language.
Not that it has anything to do with the semantics of XSLT.
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.
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?
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.
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.
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.
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.
<?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.
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.