Top
Best
New

Posted by _kush 4 days ago

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

pornel 4 days ago|
Zope was cool in that you couldn't generate ill-formed markup, and optionally wrapping something in `<a>` didn't need repeating the same condition for `</a>`.

However, it was much simpler imperative language with some macros.

XSLT is more like a set of queries competing to run against a document, and it's easy to make something incomprehensibly complex if you're not careful.

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

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

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

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

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

anentropic 4 days ago|
I remember doing the same around 25 years ago...!

all in VBScript, god help me

It felt like a great idea at the time, but it was incredibly slow to generate all the HTML pages that way.

Looking back I always assumed it was partly because computers back then were too weak, although reading other comments in this thread it seems like even today people are having performance problems with XSLT.

murukesh_s 4 days ago||
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..
mike_hearn 4 days ago||
The XSL:T equivalent for JSON is React.

Let's not romanticize XML. I wrote a whole app that used XSL:T about 25 years ago (it was a military contract and for some reason that required the use of an XML database, don't ask me). Yes it had some advantages over JSON but XSL:T was a total pain to work with at scale. It's a functional language, so you have to get into that mindset first. Then it's actually multiple functional languages composed together, so you have to learn XPath too, which is only a bit more friendly than regular expressions. The language is dominated by hacks working around the fact that it uses XML as its syntax. And there are (were?) no useful debuggers or other tooling. IIRC you didn't even have any equivalent of printf debugging. If you screwed up in some way you just got the wrong output.

Compared to that React is much better. The syntax is much cleaner and more appropriate, you can mix imperative and FP, you have proper debugging and profiling tools, and it supports incremental re-transform so it's actually useful for an interactive UI whereas XSL:T never was so you needed JS anyway.

bravesoul2 4 days ago||
The XSL:T equivalent for JSON is jq

https://github.com/jqlang/jq

Learn it. It is insanely useful for mungling json in day to day work.

ahofmann 4 days ago|||
I just had to explain to some newbies that SOAP is a protocol with rigid rules; REST is an architectural style with flexibility. The latter means that you have to work and document really well and consumers of the API need tools like Postman etc. to be even able to use the API. With SOAP, you get most of that for free.
Kwpolska 4 days ago||
Postman is just a terrible GUI for making HTTP requests. Using a REST API can be as simple as `curl https://api.github.com/repos/torvalds/linux`, and you can even open that link in a browser. SOAP requires sending a ton of XML [0] - it is not very usable without a dedicated SOAP-aware tool.

[0] https://en.wikipedia.org/wiki/SOAP#Example_message_(encapsul...

n_plus_1_acc 4 days ago||
I agree wholeheartedly, but the XML library in them JS ecosystem is shit.
JimDabell 4 days ago||
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.

darwi 4 days ago||
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

pyuser583 4 days ago|
Thank you! I've been looking for python support for XSLT 3.0! Not looking very hard, but this is still saved me some time!
giantrobot 4 days ago|
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.

More comments...