Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

261–270 of 337 posts

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

#261

Post by alganet »

kbolino wrote: post #246
bmacho wrote: post #243

Earlier quoted context omitted.

> Every frame on a page was a separate, independent, coequal instance of the browser engine. This is almost never what you actually want. 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. > Th…

With a frameset page: 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.

> 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

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.

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

#262

Post by CamouflagedKiwi »

I worked with XSLT a few companies ago. They had several XSLT documents as a transformation to various output formats (this was a pretty minor part of the overall product).

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.

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

#263

Post by kbolino »

bmacho wrote: post #260
kbolino wrote: post #254

Earlier quoted context omitted.

This has nothing to do with SPAs. 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 ha…

This is exactly what I wrote? But let me rephrase it: frames are not enough solely for an SPA, they can't keep state, you need javascript/dynamic webserver for that. > 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... . The…

It's cool that they have that link. Most frame sites didn't. JS actually isn't necessary to make that work, they could have just interpolated the requested page server-side. But it only correctly points to one frame. It's the most important frame, to be fair, but it doesn't do anything for the other two frames.

I don't understand how pre-HTML5, non-AJAX reference docs qualify as an "SPA". This is just an ordinary web site.

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

#264

Post by kbolino »

alganet wrote: post #261
kbolino wrote: post #246

Earlier quoted context omitted.

With a frameset page: 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.

> 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 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.

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

And, ironically, the best way to fix these problems with frames is to use JavaScript.

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

#265

Post by [deleted] »

kbolino wrote: post #263
bmacho wrote: post #260

Earlier quoted context omitted.

This is exactly what I wrote? But let me rephrase it: frames are not enough solely for an SPA, they can't keep state, you need javascript/dynamic webserver for that. > 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... . The…

It's cool that they have that link. Most frame sites didn't. JS actually isn't necessary to make that work, they could have just interpolated the requested page server-side. But it only correctly points to one frame. It's the most important frame, to be fair, but it doesn't do anything for the other two frames. I don't understand how pre-HTML5, non-AJAX reference docs qualify as an "SPA". This is just an ordinary web…

[deleted]

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

#266

Post by alganet »

kbolino wrote: post #264
alganet wrote: post #261

Earlier quoted context omitted.

> 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 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.

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

> They were never good

They were good enough.

> For some sites, it wasn't a big deal

Precisely my point.

> POSIX specs or Javadocs

Hey, they work for me.

> the best way to fix these problems with frames is to use JavaScript.

Some small amounts of javascript. Mainly, proxy the state for the main frame to the address bar. No need for virtual dom, babel, react, etc.

--

_Again_, you're arguing like I'm defending frames 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.

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

#267

Post by larodi »

badmintonbaseba wrote: post #81

I have worked for a company that (probably still is) heavily invested in XSLT for XML templating. It's not good, and they would probably migrate from it if they could. 1. Even though there are newer XSLT standards, XSLT 1.0 is still dominant. It is quite limited and weird compared to the newer standards. 2. Resolving performance problems of XSLT templates is hell. XSLT is a Turing-complete functional-style language,…

XSLt is not easy. It’s prologue on shrooms so to speak and it has a steep learning curve. Once mastered gives sudoku level satisfaction, but can hardly ever be a standard approach to built or templating as normally people need much less to achieve goals.

Besides XML is not universally loved.

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

#268

Post by soulofmischief »

homebrewer wrote: post #241
0x445442 wrote: post #182

Earlier quoted context omitted.

IDK, the XML hysteria is similar by comparison to the dynamic and functional languages hysterias. And it pales in comparison to the micro services, SPA and the current AI hysterias.

IMHO it's pretty comparable, the difference is only in the magnitude of insanity. After all, the industry did crap out these hardware XML accelerators that were supposed to improve performance of doing massive amounts of XML transformations — is it not the GPU/TPU craze of today? https://en.wikipedia.org/wiki/XML_appliance E.g. https://www.serverwatch.com/hardware/power-up-xml-data-proce...

At least arrays of numbers are naturally much closer to the hardware, we've definitely come a long way in that regard.

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

#269

Post by yoz »

jerf wrote: post #205
sam_lowry_ wrote: post #170

Earlier quoted context omitted.

Keys were a thing in XSLT 1.x already. 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 lo…

"Newer standards lost elegance and kept the ugly syntax." My biggest problem with XSLT is that I've never encountered a problem that I wouldn't rather solve with an XPath library and literally any other general purpose programming language. When XSLT was the only thing with XPath you could rely on, maybe it had an edge, but once everyone has an XPath library what's left is a very quirky and restrictive language that…

Serious question: would it be worth the effort to treat XSLT as a compilation target for a friendlier language, either extant or new?

There's clearly value in XSLT's near-universal support as a web-native system. It provides templating out of the box without invoking JavaScript, and there's demand for that[1]. But it still lacks decent in-browser debugging which JS has in spades.

[1] https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...

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

#270

Post by kllrnohj »

CiaranMcNulty wrote: post #19

It's sad how the bloat of '00s enterprise XML made the tech seem outdated and drove everyone to 'cleaner' JSON, because things like XSLT and XPath were very mature and solved a lot of the problems we still struggle with in other formats. 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 ` ` This may be out-of-da…

The game Rimworld stores all its game configuration data in XML and uses XPath for modding and it's so incredibly good. It's a seriously underrated combination for enabling relatively stable local modifications of data. I don't know of any other game that does this, probably because XML has a reputation of being "obsolete" or whatever. But it's just such a robust system for this use case.

https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...

Post reply on HN