XSLT – Native, zero-config build system for the Web
github.com
github.com
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, with performance very much abstracted away. There are XSLT templates that worked fine for most documents, but then one document came in with a ~100 row table and it blew up. Turns out that the template that processed the table is O(N^2) or worse, without any obvious way to optimize it (it might even have an XPath on each row that itself is O(N) or worse). I don't exactly know how it manifested, but as I recall the document was processed by XSLT for more than 7 minutes.
A couple of blue chip websites I‘ve seen that could be completely taken down just by requesting the sitemap (more than once per minute).
PS: That being said it is an implantation issue. But it may speak for itself that 100% of the XSLT projects I‘ve seen had it.
But in the end the core problem is XSLT, the language. Despite being a complete programming language, your options are very limited for resolving performance issues when working within the language.
I worked with a guy who knew all about complexity analysis, but was quick to assert that "n is always small". That didn't hold - but he'd left the team by the time this became apparent.
It looks great, then you design your stuff and it goes great, then you deploy to the real world and everything catches on fire instantly and everytime you stop one another one starts.
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. Soon "X is not for Y" blogposts appear, and usage finally starts to decrease as people rediscover "use the right tool for the right problem". Wait yet some more time, and a new technology appears, and the same cycle begins again.
Seen it with so many things by now that I think "we'll" (the software community) forever be stuck in this cycle and the only way to win is to explicitly jump out of the cycle and watch it from afar, pick up the pieces that actually make sense to continue using and ignore the rest.
https://en.wikipedia.org/wiki/XML_appliance
E.g.
https://www.serverwatch.com/hardware/power-up-xml-data-proce...
> An XML appliance is a special-purpose network device used to secure, manage and mediate XML traffic.
Holy moly
We eventually said, "what if we made databases based on JSON" and then came MongoDB. Worse performance than a relational database, but who cares! It's JSON! People have mostly moved away from document databases, but that's because they realized it was a bad idea for the majority of usecases.
I think the only left out part is about people currently believing in the current hyped way, "because this time it's right!" or whatever they claim. Kind of the way TypeScript people always appear when you say that TypeScript is currently one of those hyped things and will eventually be overshadowed by something else, just like the other languages before it, then soon sure enough, someone will share why TypeScript happen to be different.
>wasting cycles to manifest structured data in an unstructured textual format
JSON IS a structured textual format you dofus. What you're complaining about is that the message defines its own schema.
>has massive overhead on the source and destination sides
The people that care about the overhead use MessagePack or CBOR instead.
I personally hope that I will never have to touch anything based on protobufs in my entire life. Protobuf is a garbage format that fails at the basics. You need the schema one way or another, so why isn't there a way to negotiate the schema at runtime in protobuf? Easily half or more of the questionable design decisions in protobuffers would go away if the client retrieved the schema at runtime. The compiler based workflow in Protobuf doesn't buy you a significant amount of performance in the average JS or JVM based webserver since you're copying from a JS object or POJO to a native protobuf message anyway. It's inviting an absurd amount of pain for essentially zero to no benefits. What I'm seeing here is a motte-bailey justification for making the world a worse place. The motte being the argument that text based formats are computationally wasteful, which is easily defended. The bailey being the implicit argument that hard coding the schema the way protobuf does is the only way to implement a binary format.
Note that I'm not arguing particularly in favor of MessagePack here or even against protobuf as it exists on the wire. If anything, I'm arguing the opposite. You could have the benefits of JSON and protobuf in one. A solution so good that it makes everything else obsolete.
Please avoid snark.
I think part of the problem is focusing on the wrong aspect. In the case of XSLT, I'd argue its most important properties are being pure, declarative, and extensible. Those can have knock-on effects, like enabling parallel processing, untrusted input, static analysis, etc. The fact it's written in XML is less important.
Its biggest competitor is JS, which might have nicer syntax but it loses those core features of being pure and declarative (we can implement pure/declarative things inside JS if we like, but requiring a JS interpreter at all is bad news for parallelism, security, static analysis, etc.).
When fashions change (e.g. XML giving way to JS, and JSON), we can end up throwing out good ideas (like a standard way to declare pure data transformations).
(Of course, there's another layer to this, since XML itself was a more fashionable alternative to S-expressions; and XSLT is sort of like Lisp macros. Everything old is new again...)
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.
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.
I would say that the main benefit of XML is that it has a very mature ecosystem around it that JSON is still very much catching up with.
JSON has its own set of problems like lack of comments and for some reason no date type.
But in the end they are just data file formats. We have bigger things to worry about.
Streaming is not supported until later version.
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 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 lost elegance and kept the ugly syntax.
No wonder they lost mindshare.
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 I really don't like. And I speak Haskell, so the critic reaching for the reply button can take a pass on the "Oh you must not like functional programming" routine... no, Haskell is included in that set of "literally any other general purpose programming language" above.
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/26/the-time-is-right-for-a...
XML world is full of ugly standards and failed contenders. None remembers RelaxNG. But had reacher expressive power than XMLSchema and a human-readable syntax.
https://github.com/Juniper/libslax/wiki/Intro
It looks like it was developed by Juniper and has shipped in their routers?
- 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.
Also, I want a cookie & a pony.
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.)
That's YAML, and it is arguibly worse. Here's a sample YAML 1.2 document straight from their spec:
%TAG !e! tag:example.com,2000:app/
---
- !local foo
- !!str bar
- !e!tag%21 baz
--
Some notes:
- SemWeb also has JSON-LD serialization. It's a good compromise that fits modern tooling nicely.
- XML is still a damn good compromise between human readable and machine readable. Not perfect, but what is perfect anyway?
- HTML5 is now more complex than XHTML ever was (all sorts of historical caveats in this claim, I know, don't worry).
- Markup beauty is relative, we should accept that.
KDL is a very interesting attempt, but my impression is that people are already trying to shove way too much unnecessary complexity into it.
IMO, the KDL's document transformation is not a really good example of a better XSLT, tough. I mean, it's better, but it probably can still be improved a lot.
But the fundamental problem here is the same: no matter what new things are added to the spec, the best you can hope for in browsers is XSLT 1.0, even though we've had XSLT 3.0 for 8 years now.
Trying to close the gap often ends up creating more complexity than intended, or maybe even more than XML in some hands.
It definitely would be an interesting piece.
Just to frame this people, imagine a JSON-based programming language for transforming JSON files into other JSON files and the program is also in JSON and turing complete. Now imagine it's not JSON but XML! Now any program can read it! Universal code, magic!
The idea behind XXSLT is now, we actually have a program whose job it is to specify a program. So we have a XML file which specifies a second XML file, which is the program, whose job it is to transform XML to XML. As we all know, layers of abstraction are always good, and common formats such as XML are especially good, so what we have now is the ability to generate a whole family and diverse ontology of programs, all of them XML, all of them by and for XML. Imagine the compiling with your favourite XML-based compilation chain!
How, where? In 2013 I was still working a lot with XSLT and 1.0 was completely dead everywhere one looked. Saxon was free for XSLT 2 and was excellent.
I used to do transformation of both huge documents, and large number of small documents, with zero performance problems.
In the early days the xsl was all interpreted. And was slow. From ~2004 or so, all the xslt engines came to be jit compiled. XSL benchmarks used to be a thing, but rapidly declined in value from then onward because the perf differences just stopped mattering.
Obviously, that means there's a lot of legacy processes likely still using it.
The easiest way to improve the situation seems to be to upgrade to a newer version of XSLT.
I'm pretty sure that's because implementing XSLT 2.0 needs a proprietary library (Saxon XSLT[0]). It was certainly the case in the oughts, when I was working with XSLT (I still wake up screaming).
XSLT 1.0 was pretty much worthless. I found that I needed XSLT 2.0, to get what I wanted. I think they are up to XSLT 3.0.
I think the guy behind Saxon may be one of the XSLT authors.
That said, Saxon does (or at least did) have an open source version. It doesn't have all the features, e.g. no schema validation or query optimization, but all within the boundaries of the spec. The bigger problem there is that Saxon is written in Java, and browsers understandably don't want to take a dependency on that just for XSLT 2+.
Besides XML is not universally loved.
It's not my first choice, but I won't rule it out because I know how relatively flexible and capable it can be.
XSLT might just need a higher abstraction level on top of it?
The idea behind XSLT is genial, but the real essence of it is XPath which makes it possible. And we've seen XPath evolve into CSS Selectors, and being useful on its own.
So in essence there are two sides of the transformation:
- selection - when you designate which parts of the tree match
- transformation - when building the new three
But one can argue the transformation is possible with jq, it is just that I definitely don't like its overly-engineered syntax. IMHO the champion of the transformation syntax is yet undecided, even though in 2025 XSLT is still more or less king. Which is fascinating as XML is long not a usual choice of preference.
Don’t get me wrong, XPath is by far the best thing to come out of the xml ecosystem, but the actual idea at the core of xslt is the match/patch during traversal, and talking about it in terms of selection misses that boat entirely. Select / update is how you manipulate a tree with jQuery, or really the average xml library.
1. the browsers were inconsistent in 1990-2000 so we started using JS to make them behave the same
2. meanwhile the only thing we needed were good CSS styles which were not yet present and consistent behaviour
3. over the years the browsers started behaving the same (mainly because Highlander rules - there can be only one, but Firefox is also coping well)
4. but we already got used to having frameworks that would make the pages look the same on all browsers. Also the paradigm was switched to have json data rendered
5. at the current technology we could cope with server generated old-school web pages because they would have low footprint, work faster and require less memory.
Why do I say that? Recently we started working on a migration from a legacy system. Looks like 2000s standard page per HTTP request. Every action like add remove etc. requires a http refresh. However it works much faster than our react system. Because:
1. Nowadays the internet is much faster
2. Phones have a lot of memory which is wasted by js frameworks
3. in the backend all's almost same old story - CRUD CRUD and CRUD (+ pagination, + transactions)
unless you have a high latency internet connection: https://news.ycombinator.com/item?id=44326816
-- edit --
by the way in 2005 I programmed using very funny PHP framework PRADO that was sending every change in the UI to the server. Boy it was slow and server heavy. This was the direction we should have never gone...
not a good example. i can't find it now, but there was a story/comment about a realtor app that people used to sell houses. often when they were out with a potential buyer they had bad internet access and loading new data and pictures for houses was a pain. it wasn't until they switched to using a frontend framework to preload everything with the occasional updates that the app became usable.
low latency affects any interaction with a site. even hackernews is a pain to read over low latency and would improve if new comments where loaded in the background. the problem creeps up on you faster than you think.
It can also be imposed by the client, e.g. via a https://en.wikipedia.org/wiki/Web_accelerator
By the way, GWT did it before.
Then again, it was a long time. Maybe it's me misremembering.
This was maybe 2008?
2002, I was using “JSRS”, and returning http 204/no content, which causes the browser to NOT refresh/load the page.
Just for small interactive things, like a start/pause button for scheduled tasks. The progress bar etc.
But yeah, in my opinion we lost about 15 years of proper progress.
The network is the computer came true
The SUN/JEE model is great.
It’s just that monopolies stifle progress and better standards.
Standards are pretty much dead, and everything is at the application layer.
That said.. I think XSLT sucks, although I haven’t touched it in almost 20 years. The projects I was on, there was this designer/xslt guru. He could do anything with it.
XPath is quite nice though
Internet Explorer 6 was released in 2001 and didn’t drop below 3% worldwide until 2015. So that’s a solid 14 years of paralysis in browser compatibility.
Internet Explorer didn’t support DOM events, so addEventListener wasn’t cross-browser compatible. A lot of people put work in to come up with an addEvent that worked consistently cross-browser.
The DOMContentLoaded event didn’t exist, only the load event. The load event wasn’t really suitable for setting up things like event handlers because it would wait until all external resources like images had been loaded too, which was a significant delay during which time the user could be interacting with the page. Getting JavaScript to run consistently after the DOM was available, but without waiting for images was a bit tricky.
These kinds of things were iterated on in a series of blog posts from several different web developers. One blogger would publish one solution, people would find shortcomings with it, then another blogger would publish a version that fixed some things, and so on.
This is an example of the kind of thing that was happening, and you’ll note that it refers to work on this going back to 2001:
https://robertnyman.com/2006/08/30/event-handling-in-javascr...
When jQuery came along, it was really trying to achieve two things: firstly, incorporating things like this to help browser compatibility; and second, to provide a “fluent” API where you could chain API calls together.
DOM manipulation of that sort is JS dependent, of course, but I think considering language features and the environment, like the DOM, to be separate-but-related concerns is valid. There were less kitchen-sink-y libraries that only concentrated on language features or specific DOM features. Some may even consider a few parts in a third section: the standard library, though that feature set might be rather small (not much more than the XMLHTTPRequest replacement/wrappers?) to consider its own thing.
> For stuff which didn't need JS at all, there also shouldn't be much need for JQuery.
That much is mostly true, as it by default didn't do anything to change non-scripted pages. Some polyfills for static HTML (for features that were inconsistent, or missing entirely in, usually, old-IE) were implemented as jQuery plugins though.
--------
[1] Though I don't think they were called that back then, the term coming later IIRC.
[2] Method chaining³, better built-in searching and filtering functions⁴, and so forth.
[3] This divides opinions a bit though was generally popular, some other libraries did the same, others tried different approaches.
[4] Which we ended up coding repeatedly in slightly different ways when needed otherwise.
jQuery took over very quickly though for all of those.
Almost sure it was available on IE6. But even if not, you could emulate it using hidden iframes to call pages which embedded some javascript interacting with the main page. I still have fond memories of using mootools for lightweight nice animations and less fond ones of dojo.
Kuro5hin had a dynamic commenting system based on iframes like you describe.
HTML was the original standard, not JS. HTML was evolving early on, but the web was much more standard than it was today.
Early-mid 1990s web was awesome. HTML served HTTP, and pages used header tags, text, hr, then some backgound color variation and images. CGI in a cgi-bin dir was used for server-side functionality, often written in Perl or C: https://en.m.wikipedia.org/wiki/Common_Gateway_Interface
Back then, if you learned a little HTML, you could serve up audio, animated gifs, and links to files, or Apache could just list files in directories to browse like a fileserver without any search. People might get a friend to let them have access to their server and put content up in it or university, etc. You might be on a server where they had a cgi-bin script or two to email people or save/retrieve from a database, etc. There was also a mailto in addition to href for the a (anchor) tag for hyperlinks so you could just put you email address there.
Then a ton of new things were appearing. PhP on server-side. JavaScript came out but wasn’t used much except for a couple of party tricks. ColdFusion on server-side. Around the same time was VBScript which was nice but just for IE/Windows, but it was big. Perl then PhP were also big on server-side. If you installed Java you could use Applets which were neat little applications on the page. Java Web Server came out serverside and there were JSPs. Java Tomcat came out on server-side. ActionScript came out to basically replace VBScript but do it on serverside with ASPs. VBScript support went away.
During this whole time, JavaScript had just evolved into more party tricks and thing like form validation. It was fun, but it was PhP, ASP, JSP/Struts/etc. serverside in early 2000s, with Rails coming out and ColdFusion going away mostly. Facebook was PhP mid-2000s, and LAMP stack, etc. People breaking up images using tables, CSS coming out with slow adoption. It wasn’t until mid to later 2000s until JavaScript started being used for UI much, and Google’s fostering of it and development of v8 where it was taken more seriously because it was slow before then. And when it finally got big, there was an awful several years where it was framework after framework super-JavaScript ADHD which drove a lot of developers to leave web development, because of the move from server-side to client-side, along with NoSQL DBs, seemingly stupid things were happening like client-side credential storage, ignoring ACID for data, etc.
So- all that to say, it wasn’t until 2007-2011 before JS took off.
The thing was that it was really hard to write code that did the same DOM + placement on all the browsers, and if a framework could do that, this was becoming great help. I started my webpage development in 2000-ish with if (`document.forms /* is ie */`) ... and was finding a way to run IE on my Linux computer to test the webpage rendering there. And CSS 2 was released on 1998 and could change everything and was the Deus Ex Machine everyone expected, except for it didn't work, especially on IE (which had majority of market, and especially if you developed a business application, you had to count it as the majority of all your clients, if not the only ones). So in CSS 2 you could __allegedly__ do things you really needed, like placing things together or in a related position, instead of calculating browser's sizes etc., but it didn't work correctly, so you had to fallback to javascript `document.getElementById().position = screenWidth/2 etc`.
So according to my memory, (1) these were the dark times mainly because of m$ being lazy and abusing their market position (2) we used javascript to position elements, colorize them, make complicated bevels, borders etc (3) this created gap for Google that they could use to gain power (which we admired at that time as the saviours of the web) (4) Opera was the thing and Resistance icon (boasting themselves of fulfilling all standards and being fast, but they failed a few times too)
also DSL, LAN internet sharing and AOL (in Poland 0202122 ppp/ppp), tshshshshshs, tidutidumtidum, tshshshshshsh ...
I've got a .NET/Kestrel/SQLite stack that can crank out SSR responses in no more than ~4 milliseconds. Average response time is measured in hundreds of microseconds when running release builds. This is with multiple queries per page, many using complex joins to compose view-specific response shapes. Getting the data in the right shape before interpolating HTML strings can really help with performance in some of those edges like building a table with 100k rows. LINQ is fast, but approaches like materializing a collection per row can get super expensive as the # of items grows.
The closer together you can get the HTML templating engine and the database, the better things will go in my experience. At the end of the day, all of that fancy structured DOM is just a stream of bytes that needs to be fed to the client. Worrying about elaborate AST/parser approaches when you could just use StringBuilder and clever SQL queries has created an entire pointless, self-serving industry. The only arguments I've ever heard against using something approximating this boil down to arrogant security hall monitors who think developers cant be trusted to use the HTML escape function properly.
Unfortunately, they're not actually wrong though :-(
Still, there are ways to enforce escaping (like preventing "stringly typed" programming) which work perfectly well with streams of bytes, and don't impose any runtime overhead (e.g. equivalent to Haskell's `newtype`)
It works well here on HN for example as it is quite simple.
There are a lot of other examples where people most likely should do a simple website instead of using JS framework.
But "we could all go back to full page reloads" is not true, as there really are proper "web applications" out there for which full page reloads would be a terrible UX.
To summarize there are:
"websites", "web documents", "web forms" that mostly could get away with full page reloads
"web applications" that need complex stuff presented and manipulated while full page reload would not be a good solution
Let's face it, most uses of JS frameworks are for blogs or things that with full page reload you not even notice: nowadays browsers are advanced and only redraw the screen when finished loading the content, meaning that they would out of the box mostly do what React does (only render DOM elements who are changes), meaning that a page reload with a page that only changes one button at UI level does not result in a flicker or loading of the whole page.
BTW, even React now is suggesting people to run the code server-side if it is possible (it's the default of Next.JS), since it makes the project easier to maintain, debug, test, as well as get better score in SEO from search engines.
I'm still a fan of the "old" MVC models of classical frameworks such as Laravel, Django, Rails, etc. to me make overall projects that are easier to maintain for the fact that all code runs in the backend (except maybe some jQuery animation client side), model is well separated from the view, there is no API to maintain, etc.
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/...
Even with these problems, classic frames might have been salvageable, but nobody bothered to fix them.
Most frames are used for menu, navigation, frame for data, frame for additional information of data. And they are great for that. I don't think that frames are different instances of the browser engine(?) but that doesn't matter the slightest(?). They are fast and lightweight.
> The header/footer/sidebar frames are subordinate and should not navigate freely.
They have the ability to navigate freely but obviously they don't do that, they navigate different frames.
History doesn't work right
Bookmarks don't work right -- this applies to link sharing and incoming links too
Back button doesn't work right
The concept is good. The implementation is bad.
Take the POSIX specs linked in a sibling comment.
Or take the classic Javadocs. I am currently looking at the docs for java.util.ArrayList. Here's a link to it from my browser's URL bar: https://docs.oracle.com/javase/8/docs/api/
But you didn't go to the docs for java.util.ArrayList, you went to the starting page. Ok, fine, I'll link you directly to the ArrayList docs, for which I had to "view frame source" and grab the URL: https://docs.oracle.com/javase/8/docs/api/java/util/ArrayLis...
Ok, but now you don't see any of the other frames, do you? And I had one of those frames pointing at the java.util class. So none of these links show you what I saw.
And if I look in my history, there is no entry that corresponds to what I actually saw. There are separate entries for each frame, but none of them load the frameset page with the correct state.
These are strongly hyperlinked reference documents. Classic use of HTML. No JavaScript or even CSS needed.
> Ok, fine, I'll link you directly to the ArrayList docs, for which I had to "view frame source" and grab the URL:
You could've just right click on the "frames" link, and copy the URL: https://docs.oracle.com/javase/8/docs/api/index.html?java/ut... . They use javascript to navigate based on the search params in the URL. It's not great, it should update the URL as you navigate, maybe you can send them a PR for that. (And to change state of the boxes on the left too.)
Also browser history handling is really messy and hard to get right, regardless of frames.
> And if I look in my history, there is no entry that corresponds to what I actually saw.
? If you write a javascript +1 button that updates a counter, there won't be a corresponding entry in your history for the actual states of your counter. I don't see how that is a fundamental problem with javascript(?).
I don't understand how pre-HTML5, non-AJAX reference docs qualify as an "SPA". This is just an ordinary web site.
> Bookmarks don't work right -- this applies to link sharing and incoming links too
> Back button doesn't work right
Statements that apply to many JS webpages too.
pushState/popState came years after frames lost popularity. These issues are not related to their downfall.
Relax, dude. I'm not claiming we should use frames today. I'm saying they were simple good tools for the time.
And, ironically, the best way to fix these problems with frames is to use JavaScript.
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 for use today. That's not what I'm doing.
Many websites follow a "left navigation, center content" overall layout, in which the navigation stays somehow stationary and the content is updated. Frames were broken, but were in the right direction. You're nitpicking on the ways they were broken instead of seeing the big picture.
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.
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.
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 also coincides with the rise of the (still ongoing) div-layout era.
I agree wholeheartedly that the concept of partial page reloading in a rectilinear grid is alive and well. Doing that with JavaScript and CSS is the whole premise of an SPA as I understand it, and those details are key to the difference between now and the heyday of frames. But there was also a time when full-page-loading was the norm between the two eras, reflecting the disillusionment with frames as they were implemented and ossified.
The W3C (*) spent a good few years working on multiple things most of which didn't pan out. Maybe I'm being too harsh, but it feels like a lot of their working groups just went off and disconnected from practice and industry for far too long. Maybe that was tangential to the ~decade-long stagnation of web standards, but that doesn't really change the point of my criticism.
* = Ecma has a part in this too, since JavaScript was standardized by them instead of W3C for whatever reason, and they also went off into la-la land for roughly the same period of time
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.
I should clarify. I don't think JS killed frames, that's not what I meant. If anything, I think JS could have saved frames. But the failure of frames left a gap that eventually JS (esp. with AJAX) filled. Lots of other stuff was going on at this time too, including alternative tech like Java, Flash, and ActiveX, all of which were trying to do more by bypassing the "standard" tech stack entirely.
I think the ossification of web standards from ca. 1999 to 2012, combined with the rapidly growing user base, and with web developers/designers aggressively pushing the envelope of what the tech could do, put the standard stuff on the back foot pretty badly. Really, I'm talking about the whole ecosystem and not just the standards bodies themselves; there was an era where e.g. improving HTML itself was just not the active mentality. Both inside and outside of W3C (etc.), it seemed that nobody cared to make the standard stuff better. W3C focused on unproductive tangents; web devs focused on non-standard tech or "not the intended use" (like tables for layout).
So I think we can say that <frameset> frames died a somewhat unfair death, caused partly by their initial shortcomings, partly by people trying to break outside of the (literal) boxes they imposed, and partly by the inability of the standard tech to evolve and address those shortcomings in a timely fashion. But just as there was a reason they failed, there was a reason they existed too.
https://pubs.opengroup.org/onlinepubs/9799919799/
They can navigate targeting any other frame. For example, clicking "System Interfaces" updates the bottom-left navigation menu, while keeping the state of the main document frame.
It's quite simple, just uses the `target` attribute (target=blank remains popular as a vestigial limb of this whole approach).
This also worked with multiple windows (yes, there were multi-window websites that could present interactions that handled multiple windows).
The popular iframe is sort of salvaged from frame tech, it is still used extensively and not deprecatred.
Classic frames are simple. Too simple. Your link goes to the default state of that frameset. Can you link me any non-default state? Can I share a link to my current state with you?
I'm probably guilty of some of the bad practice: I have fond memories of (ab)using XSLT includes back in the day with PHP stream wrappers to have stuff like `<xsl:include href="mycorp://invoice/1234">`
This may be out-of-date bias but I'm still a little uneasy letting the browser do the locally, just because it used to be a minefield of incompatibility
If your document has namespaces, xpath has to reflect that. You can either tank it or explicitly ignore namespaces by foregoing the shorthands and checking `local-name()`.
/*bookstore/*book/*title
its been some godawful mess like
/*[name()='bookstore']/*[name()='book']/*[name()='title']
... I guess because they couldn't bear to have it just match on tags as they are in the file and it had to be tethered to some namespace stuff that most people dont bother with. A lot of XML is ad-hoc without a namespace defined anywhere
Its like
Me: Hello Xpath, heres an XML document, please find all the bookstore/book/title tags
Xpath: *gasps* Sir, I couldn't possibly look for those tags unless you tell me which namespace we are in. Are you some sort of deviant?
Me: oh ffs *googles xpath name() syntax*
/*:bookstore/*:book/*:titlemy:book is a different thing from your:book and you generally don't want to accidentally match on both. Keeping them separate is the entire point of namespaces. Same as in any programming language.
Is not actually relevant and is not an information the average XML processor even receives. If the file uses a default namespace (xmlns), then the elements are namespaced, and anything processing the XML has to either properly handle namespaces or explicitly ignore namespaces.
> A lot of XML is ad-hoc without a namespace defined anywhere
If the element is not namespaced xpath does not require a prefix, you just write
//bookstore/book/titleUntil some joker decided to employ xml namespaces, then everything turns ugly real fast. I am not sure I can articulate why it is so unpleasant, something about how everything gets super verbose and api now needs all sorts of extra state.
XML is a markup language system. You typically have a document, and various parts of it can be marked up with metadata, to an arbitrary degree.
JSON is a data format. You typically have a fixed schema and things are located within it at known positions.
Both of these have use-cases where they are better than the other. For something like a web page, you want a markup language that you progressively render by stepping through the byte stream. For something like a config file, you want a data format where you can look up specific keys.
Generally speaking, if you’re thinking about parsing something by streaming its contents and reacting to what you see, that’s the kind of application where XML fits. But if you’re thinking about parsing something by loading it into memory and looking up keys, then that’s the kind of application where JSON fits.
XPath is kind of fine. It's hard to remember all the syntax but I can usually get there with a bit of experimentation.
XSLT is absolutely insane nonsense and needs to die in a fire.
Last thing I really did with XML was a technology called EXI, a transfer method that converted an XML document into a compressed binary data stream. Because translating a data structure to ASCII, compressing it, sending it over HTTP etc and doing the same thing in reverse is a bit silly. At this point protobuf and co are more popular, but imagine if XML stayed around. It's all compatible standards working with each other (in my idealized mind), whereas there's a hard barrier between e.g. protobuf/grpc and JSON APIs. Possibly for the better?
For a transport tech XML was OK. Just wasted 20% of your bandwidth on being a text encoding. Plus wrapping your head around those style sheets was a mind twister. Not surprised people despise it. As it has the ability to be wickedly complex for no real reason.
I was curious about how it is implemented and I found the spec easy to read and quite elegant: https://www.w3.org/TR/exi/
True, and it's even more sad that XML was originally just intended as a simplified subset of SGML (HTML's meta syntax with tag inference and other shortforms) for delivery of markup on the web and to evolve markup vocabularies and capabilities of browsers (of which only SVG and MathML made it). But when the web hype took over, W3C (MS) came up with SOAP, WS-this and WS-that, and a number of programming languages based on XML including XSLT (don't tell HNers it was originally Scheme but absolutely had to be XML just like JavaScript had to be named after Java; such was the madness).
https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...
It works surprisingly well, the only issue I ever ran into was a decades old bug in Firefox that doesn't support rendering HTML content directly from the XML document. I.e. If the blog post content is HTML via cdata, I needed a quick script to force Firefox to render that text to innerHTML rather than rendering the raw cdata text.
I learned quickly to leave this particular experience off of my resume as sundry DoD contractors contacted me on LinkedIn for my "XML expertise" to participate in various documentation modernization projects.
The next time you sigh as you use JSX to iterate over an array of Typescript interfaces deserialized from a JSON response remember this post - you could be me doing the same in XSLT :-).
Thank you reading specs.
Thank you making tool.
XML is the C++ of text based file formats if you ask me. It's mature, batteries included, powerful and can be used with any language, if you prefer.
Like old and mature languages with their own quirks, it's sadly fashionable to complain about it. If it doesn't fit the use case, it's fine, but treating it like an abomination is not.
Just imagine how fast websites would have rendered if we went that route
I updated an XSLT system to work with then latest Firefox a couple of years ago. We have scripts in a different directory to the documents being transformed which requires a security setting to be changed in Firefox to make it work, I don't know if an equivalent thing is needed for Chrome.
I would rather that they introduced support for v3, as that would make it easier to serving static webpages with native support for templating.
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.
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!
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.
It wasn't that bad. We used tomcat and some apache libraries for this. Worked fine.
Our CMS was spitting out XML files with embedded HTML that were very cachable. We handled personalization and rendering to HTML (and js) server side with a caching proxy. The XSL transformation ran after the cache and was fast enough to keep up with a lot of traffic. Basically the point of the XML here was to put all the ready HTML in blobs and all the stuff that needed personalization as XML tags. So the final transform was pretty fast. The XSL transformer was heavily optimized and the trick was to stream its output straight to the response output stream and not do in memory buffering of the full content. That's still a good trick BTW. that most frameworks do wrong out of the box because in memory buffering is easier for the user. It can make a big difference for large responses.
These days, you can run whatever you want in a browser via wasm of course. But back then javascript was a mess and designers delivered photoshop files, at best. Which you then had to cut up into frames and tables and what not. I remember Google Maps and Gmail had just come out and we were doing a pretty javascript heavy UI for our CMS and having to support both Netscape and Internet Explorer, which both had very different ideas about how to do stuff.
You needed the jvm and saxon and that was about it...
??
I was transforming XML with, like, three lines of VBScript in classic ASP.
Plug: here is a small project to get the basic information about the XSLT processor and available extensions. To use with a browser find the 'out/detect.xslt' file there and drag it into the browser. Works with Chrome and Firefox; didn't work with Safari, but I only have an old Windows version of it.
It was exactly because of the "holy grail of host-anywhere static templating". But somehow everybody that knew about it made a vow of silence and was forbidden from actually saying it.
Depressed and quite pessimistic about the team’s ability to orchestrate Java development in parallel with the rapid changes to the workbook, he came up with the solution: a series of XSLT files that would automatically build Java classes to handle the Struts actions defined by the XML that was built by Visual Basic from the workbook that was written in Excel.
https://raganwald.com/2008/02/21/mouse-trap.html
HN Discussions:
https://news.ycombinator.com/item?id=120379 · https://news.ycombinator.com/item?id=947952
XML is a semi-structured format, which (apart from & < >) includes plain text as a more or less degenerate case. I don't think we have any other realistic format for marking up plain text with arbitrary semantics. You can have, for example, a recipe format with <ingredient> as part of its schema, and it's trivial to write an Xpath to pull out all the <ingredient>s (to put them in your shopping list, or whatever).
Obviously, XSLT is code. Nobody denies this really. One thing about code is that it's inherently structured. Only the craziest of literate programmers would try to embed executable code inside of text. But I don't think that's the biggest problem. Code is special in that special purpose programming languages always leak outside the domain they're designed for. If you try and write a little language that's really well-scoped to transforming XML, you are definitely going to want to call stuff outside it sooner or later.
Combined with the fact that there really isn't any value in ever parsing or processing a stylesheet, it seems like it was doomed never to pan out.
JS was waay too slow, but it turned out that even back then XSLT was blazing fast. So I basically generated XML with all the data, wrote a simple XSLT with one clever XPath that generated search input form, did the search and displayed the results, slapped the xml file in CD auto-run and called it a day. It was finding results in a second or less. One of my best hacks ever.
Since then I always wanted to make a html templating system that compiles to XSLT and does the HTML generation on client side. I wrote some, but back then Firefox didn't support displaying XML+XSLT directly and the workaround I came up with I didn't like. Then the AJAX came and then JS got faster and client side rendering with JS became viable. But I still think it's a good idea, to send just dynamic XMLs with static XSLTs preloaded and cached, if we ever want to come back to purely server driven request-response flow. Especially if binary format for XML catches on.
This didn't work for me on my browsers (FF/Chrome/Safari) on Mac, apparently XSLT only works there when accessed through HTTP:
$ python3 -m http.server --directory .
$ open http://localhost:8000/blog.xml
Huh, neat! Did’t know it supported that. (python3 -m http.server will default to current directory anyway though)
python3 -m http.server -d _site/
// XML $xml_doc = new DOMDocument(); $xml_doc->load("file1.xml");
// XSL $xsl_doc = new DOMDocument(); $xsl_doc->load("file.xsl");
// Proc $proc = new XSLTProcessor(); $proc->importStylesheet($xsl_doc); $newdom = $proc->transformToDoc($xml_doc);
print $newdom->saveXML();
XSLT lacks functionality? No problem, use php functions in xslt: https://www.php.net/manual/en/xsltprocessor.registerphpfunct...
RTFM
Xee: A Modern XPath and XSLT Engine in Rust
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.
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.
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.
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.
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.
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.
[0] https://en.wikipedia.org/wiki/SOAP#Example_message_(encapsul...
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.
Learn it. It is insanely useful for mungling json in day to day work.
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.
It has worked amazingly well for us, and the generated files are already merged in the Linux Kernel.
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...
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.
I think there are just a few that know XSL(T) these days, or need some refresh (like me).
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
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.
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>
<?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>
<xsl:template match="my-element">
<!-- HTML for my custom element -->
</xsl:template>
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.
a more elaborate example has the same results. chromium is empty. firefox works except that it looks like attributes to tags in the main content are ignored, which prevents css classes or links from working and images from loading. both work in the menu that is included from the template.
found it: the problem was that <xsl:copy><xsl:apply-templates/></xsl:copy> doesn't copy attributes. it needs to be:
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
XSLT technically would make sense the more you're using large amounts of boilerplate XML literals in your template because it's using XML itself as language syntax. But even though using XML as language meta-syntax, it has lots of microsyntax ie XPath, variables, parameters that you need to cram into XML attributes with the usual quoting restrictions and lack of syntax highlighting. There's really nothing in XSLT that couldn't be implemtented better using a general-purpose language with proper testing and library infrastructure such as Prolog/Datalog (in fact, DSSSL, XSLT's close predecessor for templating full SGML/HTML and not just the XML subset, was based on Scheme) or just, you know, vanilla JavaScript which was introduced for DOM manipulation.
Note maintainance of libxml2/libxslt is currently understaffed [1], and it's a miracle to me XSLT (version v1.0 from 1999) is shipping as a native implementation in browsers still unlike eg. PDF.js.
A few years ago, I decided to style my own feeds, and ended up with this: https://chrismorgan.info/blog/tags/fun/feed.xml. https://chrismorgan.info/atom.xsl is pretty detailed, I don’t think you’ll find one with more comprehensive feature support. (I wrote a variant of it for RSS too, since I was contemplating podcasts at the time and almost all podcast software is stupid and doesn’t support Atom, and it’s all Apple’s fault: https://temp.chrismorgan.info/2022-05-10-rss.xsl.)
At the time, I strongly considered making the next iteration of my website serve all blog stuff as Atom documents—post lists as feeds, and individual pages as entries. In the end, I’ve decided to head in a completely different direction (involving a lot of handwriting!), but I don’t think the idea is bad.
https://zvon.org/xxl/XSLTutorial/Books/Output/contents.html
Still a great resource.
--
I would say CSS selectors superseeded XPath for the web. If one could do XSLT using CSS selectors instead, it would feel fresh and modern.
The funny thing is that the concept of AJAX was fairly new at the time, and so for them it made sense that the future of "fat" web pages (that's the term they use in their doc) was to use AJAX to download XML and transform it. But then people quickly learned that if you could just use JS to generate content, why bother with XML at all?
Back in 2005 I was evaluating some web framework concepts from R&D at the company I worked, and they were still very much in an XML mindset. I remember they created an HTML table widget that loaded XML documents and used XPATH to select content to render in the cells.
It never broke, ever.
It could have bugs, of course! -- but only "programmer bugs" (behavior coded in a certain way that should have been coded in another); it never suddenly stopped working for no reason like everything does nowadays.
I'm not sure I've ever seen something less popular. Feature requests and the odd bug would build up, eventually an engineer would be assigned to it for a week and they'd fix a bunch of things, then essentially would rather quit than keep doing it, so next time it'd be someone else's turn.
I don't even think it was particularly bad. It seemed like it was just always like that. Thank goodness it isn't so popular any more so it doesn't turn up jammed into random places as it did then.
Somehow it took me many years, basically until starting uni and taking a proper programming class, before I started feeling like I could realize my ideas in a normal programming language.
XSLT was a kind of tech that allowed a non-coder like me to step by step figure out how to get things to show on the screen.
I think XSLT really has some strong points, in this regard at least.
Turns out you can do a lot with the RegEx-support in XSLT 2.0!
https://saml.rilspace.com/exercise-in-xslt-regex-partial-gal...
The result? A Java-based tools for creating CLI commands via a wizard:
I think one big problem with popularizing that approach is that XSLT as a language frankly sucks. As an architecture component, it's absolutely the right idea, but as long as actually developing in it is a world of pain, I don't see how people would have any incentive to adopt it.
The tragic thing is that there are other pure-functional XML transformation languages that are really well-designed - like XQuery. But there is no browser that supports those.
My favorite thing about XQuery is that it supports logically named functions, not just templates that happen to work upon whatever one provides it as with XSLT. I think golang's text/template suffers from the same problem - good luck being disciplined enough to always give it the right context, or you get bad outcomes
An example I had lying around:
declare function local:find-outline-num( $from as element(), $num as xs:integer ) as element()* {
for $el in $from/following-sibling::h:div[@class=concat('outline-', $num)]/*[local-name()=concat('h', $num)]
return $el
};"XSLT is a failure wrapped in pain"
original article seems offline but relevant HN discussion: https://news.ycombinator.com/item?id=8708617
> [...] the idea of building a website like this in XML and then transforming it using XSL is absurd in and of itself [...]
In the comments the creators comment on it, like that it was a mess to debug. But I could not find anything wrong with the technique itself, assuming that it is working.
I’ve kinda gotten to a point and curious if others feel same: it’s all just strings. You get some strings from somewhere, write some more strings to make those strings show other strings to the browser. Sometimes the strings reference non strings for things like video/audio/image. But even those get sent over network with strings in the http header. Sometimes people have strong feelings about their favorite strings, and there are pros and cons to various strings. Some ways let you write less strings to do more. Some are faster. Some have angle brackets, some have curly brackets, some have none at all! But at the end of the day- it’s just strings.
Gave it up because it turns out the little things are just a pain. Formatting dates, showing article numbers and counts etc.
I suspect some of the hate towards XML from the web dev community boils down to it being "old". I'll admit that used to have the same opinion until I actually started working with it. It's a little bit more of a PITA than working with JSON, but I think I'm getting a much more expressive and powerful serialization format for the cost of the added complexity.
https://github.com/captn3m0/boardgame-research
It also feels very arcane - hard to debug and understand unfortunately.
This is the first I've seen it. Interesting...
me come to hn, see xml build system, me happy, much smiling, me hit up arrow, me thank good stranger.
And the browser takes care of the rendering.
Good times.
XSLT controls the styling, Lua the running functions. When Lua adjusts a visible thing, it generates XSLT.
"FrameXML" is a thin Lua wrapper around the base XSLT.
me have make vomit from seeing xml
I learned one thing: Apply XSL to an XML by editing the XML. But can we flip it?
The web works in MVC ways. Web servers are controllers that output the view populated with data.
(XML) Data is in the backend. (XSLT) View page is the front end. (XPath) Query filters is requesting (XML) data like controllers do.
https://learn.microsoft.com/en-us/previous-versions/windows/...
Well, Apache says hi: https://httpd.apache.org/docs/2.4/howto/ssi.html (Look for "include")
Here's how use XSLT to make Punkemon Pie Menus! [ WARNING: IE 5 required! ;) ]
The "htc" files are ActiveX components written in JScript, aka "Dynamic HTML (DHTML) behaviors":
https://en.wikipedia.org/wiki/HTML_Components
>HTML Components (HTCs) are a legacy technology used to implement components in script as Dynamic HTML (DHTML) "behaviors" in the Microsoft Internet Explorer web browser. Such files typically use an .htc extension and the "text/x-component" MIME type.
JavaScript Pie Menus, using Internet Explorer "HTC" components, xsl, and xml:
https://www.youtube.com/watch?v=R5k4gJK-aWw
>Pie menus for JavaScript on Internet Explorer version 5, configured in XML, rendered with dynamic HTML, by Don Hopkins.
punkemonpiemenus.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
punkemon.xsl: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
punkemon.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
punkemonpiemenus.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
piemenu.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
Also an XML Schema driven pie menu editor:
piemenuschemaeditor.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
piemenuschemaeditor.xsl: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
piemenuschema.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
piemenuschemaeditor.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
piemenuxmlschema-1.0.xsd: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
Here's an earlier version that uses ActiveX OLE Control pie menus, xsl, and xml, not as fancy or schema driven:
ActiveX Pie Menus:
https://www.youtube.com/watch?v=nnC8x9x3Xag
>Demo of the free ActiveX Pie Menu Control, developed and demonstrated by Don Hopkins.
ActiveXPieMenuEditor.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
piemenueditor.xsl: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
piemenueditor.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
piemenueditor.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
piemenumetadata.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
Fasteroids (Asteroids comparing Pie Menus -vs- Linear Menus):
fasteroids.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
fasteroids.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...
If that wasn't obsolete enough, here is the "ConnectedTV Skin Editor". It was a set of HTC components, XML, and XML Schemas, and a schema driven wysiwyg skin editor for ConnectedTV: a Palm Pilot app that turned your Palm into a personalized TV guide + smart remote.
Full fresh lineup of national and local broadcast + TiVo + Dish TV guides with customized channel groups, channel and show filtering and favorites, hot sync your custom tv guide with just the shows you watch, weeks worth of schedules you could download and hot sync nightly with the latest guide updates.
Integrated with trainable consumer IR remote controller with custom touch screen user interfaces (with 5-function "finger pie menus" that let you easily tap or stroke up/down/left/right to stack up multiple gesture controls on each button (conveniently opposite and orthogonal for volume up/down, channel next/previous, page next/previous, time forward/back, show next/previous, mute/unmute, favorite/ignore, etc -- finger pies are perfect for the kind of opposite and directionally oriented commands on remote controls, and you need a lot fewer 5-way buttons than single purpose physical buttons on normal remotes, so you could pack a huge amount of functionality into one screen, or have any number of less dense screens, customized for just the devices you have and features you use. Goodbye TiVo Monolith Monster remote controls, since only a few of the buttons were actually useful, and ConnectedTV could put 5x the number of functions per gesture activated finger pie menu button.
The skin editor let you make custom user interfaces by wysiwyg laying out and editing out any number of buttons however you liked and bind tap/left/right/up/down page navigation, tv guide time and channel and category navigation, sending ir commands to change the channel (sends multi digits per tap on station or show so you can forget the numbers), volume, mute, rewind/skip tivo, etc.
Also you could use finger pies easily and reliably on the couch in a dark room with your finger instead of the stylus. Users tended to lose their Palm stylus in the couch cushions (which you sure don't wanna go fishing around for if JD Vance has been visiting) while eating popcorn and doing bong hits and watching tv and patting the dog and listening to music and playing video games in their media cave, so non-stylus finger gesture control was crucial.
Finger pies were was like iPhone swipe gestures, but years earlier, much cheaper (you could get a cheap low end Palm for dirt cheap and dedicate it to the tv). And self revealing (prompt with labels and give feedback (with nice clicky sounds) and train you to use the gestures efficiently) instead of invisible mysterious iPhone gestures you have to discover and figure out without visual affordances. After filtering out all the stuff you never watch and favoriting the ones you do, it was much easier to find just the shows you like and what was on right now.
More on the origin of the term "Finger Pie" for Beatles fans (but I digress ;) :
https://news.ycombinator.com/item?id=16615023
https://donhopkins.medium.com/gesture-space-842e3cdc7102
It was really nice to have the TV guide NOT on the TV screen taking you away from watching the current show, and NOT to have to wait 10 minutes while it slowly scrolled the two visible rows to through 247 channels to finally see the channel you wanted to watch (by that time you'll miss a lot of the show, but be offered lots of useless shit and psychic advice to purchase from an 800 number with your credit card!).
Kids these days don't remember how horrible and annoying those slow scrolling TV guides with ads for tele-psychics and sham wows and exercise machines used to be.
I can objectively say that it was much better than the infamous ad laden TV Guide Scroll:
https://www.youtube.com/watch?v=JkGR29TSueM
Using those slow scrolling non-interactive TV guides with obnoxious ads was so painful that you needed to apply HEAD ON directly to the forehead again and again and again to ease the pain.
https://www.youtube.com/watch?v=Is3icfcbmbs
You could use the skin editor to create your own control panels and buttons for whatever TV, TiVO, DVR, HiFi, Amplifier, CD, DVD, etc players you wanted to use together. And we had some nice color hires skins for the beautiful silver folding Sony Clie.
https://en.wikipedia.org/wiki/Sony_CLI%C3%89_PEG-TG50
It was also nice to be able to curate and capture just the buttons you wanted for the devices that you actually use together, and put them all onto one page, or factor them out into different pages per device. You could ignore the 3 digit channel number and never peck numbers again, just stroke up on your favorite shows to switch the channel automatically.
We ran out of money because it was so expensive to license the nightly feed of TV guide (downloading a huge sql dump every night of the latest schedules as they got updated), and because all of our competitors were just stealing their data by scraping it from TV guide web sites instead of licensing it legally. (We didn't have Uber or OpenAI to look up to for edgy legal business practice inspiration.)
Oh well, it was fun while it lasted, during the days that everybody was carrying a Palm Pilot around beaming their contacts back and forth with IR. What a time that was, right before and after 9/11 2001. I remember somebody pointedly commented that building a Palm app at that time in history was kind of like opening a flower shop at the base of the World Trade Center. ;(
https://github.com/SimHacker/ConnectedTVSkinEditor
https://www.pencomputing.com/palm/Pen44/connectedTV.html
https://uk.pcmag.com/first-looks/29965/turn-your-palm-into-a...
Connected TV User Guide:
Overview: https://donhopkins.com/home/ConnectedTVUserGuide/Guide1-Over...
Setting Up: https://donhopkins.com/home/ConnectedTVUserGuide/Guide2-Sett...
Using: https://donhopkins.com/home/ConnectedTVUserGuide/Guide3-Usin...
Memory: https://donhopkins.com/home/ConnectedTVUserGuide/Guide4-Memo...
Sony: https://donhopkins.com/home/ConnectedTVUserGuide/Guide5-Sony...
From talking to AI, it seems the main issues would be:
- SEO (googlebot)
- Social Media Sharing
- CSP heavy envs could be trouble
Is this right?