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

231–240 of 337 posts

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

#231

Post by evanelias »

jbaiter wrote: post #29

Does anybody remember Cocoon? It was an XSLT Web Framework that built upon Spring. It was pretty neat, you could do the stuff XSLT was great at with stylesheets that were mapped to HTTP routes, and it was very easy to extend it with custom functions and supporting Java code to do the stuff it wasn't really great at. Though I must say that as the XSLT stylesheets grew in complexity, they got *really* hard to understan…

Yes! In the mid 00's, two places I worked (major US universities) used Cocoon heavily. It was a good fit for reporting systems that had to generate multiple output formats, such as HTML and PDF.

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

#232

Post by tclancy »

rwmj wrote: post #84
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…

XML is fine. A bit wordy, but I appreciate its precision and expressiveness compared to YAML. 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.

That's funny, I would reverse those. I loved XSLT though it took me a long time for it to click; it was my gateway drug to concepts like functional programming and idempotency. XPath is pretty great too. The problem was XML, but it isn't inherent to it -- it empowered (for good and bad) lots of people who had never heard of data normalization to publish data and some of it was good but, like Irish Alzheimer's, we only remember the bad ones.

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

#234

Post by [deleted] »

ako wrote: post #221
colejohnson66 wrote: post #209

Earlier quoted context omitted.

A controversial opinion, but JSON is that too. Not as bad as XML was (̶t̶h̶e̶r̶e̶'̶s̶ ̶n̶o̶ ̶"̶J̶S̶L̶T̶"̶)̶, but wasting cycles to manifest structured data in an unstructured textual format has massive overhead on the source and destination sides. It only took off because "JavaScript everywhere" was taking off — performance be damned. Protobufs and other binary formats already existed, but JSON was appealing because…

There is JSLT: https://github.com/schibsted/jslt and it can be useful if you need to transform a json document into another json structure.

[deleted]

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

#235

Post by mdaniel »

xg15 wrote: post #93

I remember Blizzard actually using this concept for their battle.net site like, 10 years ago. I found it always really cool, but at some point I think they replaced it with a "regular" SPA stack. 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…

> like XQuery

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
  };

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

#236

Post by g8oz »

deanebarker wrote: post #163
fergie wrote: post #32

What is this "XSLT works natively in the browser" sourcery? The last time I used XSLT was like 20 years ago- but I used it A LOT, FOR YEARS. In those days you needed a massive wobbly tower of enterprise Java to make it work which sort of detracted from the elegance of XSLT itself. But if XSLT actually works in the browser- has the holy grail of host-anywhere static templating actually been sitting under our noses thi…

> massive wobbly tower of enterprise Java to make it work ?? I was transforming XML with, like, three lines of VBScript in classic ASP.

The MSXML parser was pretty darn solid.

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

#237

Post by kbolino »

alganet wrote: post #219
ozim wrote: post #107

Earlier quoted context omitted.

AJAX and updating DOM wasn't there just to "make things faster" it was implemented there to change paradigm of "web sites" or "web documents" — because web was for displaying documents. Full page reload makes sense if you are working in a document paradigm. 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…

> full page reloads 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/...

Classic frames were quite bad. Every frame on a page was a separate, independent, coequal instance of the browser engine. This is almost never what you actually want. The header/footer/sidebar frames are subordinate and should not navigate freely. Bookmarks should return me to the frameset state as I left it, not the default for that URL. History should contain the frameset state I saw, not separate entries for each individual frame.

Even with these problems, classic frames might have been salvageable, but nobody bothered to fix them.

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

#238

Post by ChrisMarshallNY »

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,…

> Even though there are newer XSLT standards, XSLT 1.0 is still dominant.

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.

[0] https://en.wikipedia.org/wiki/Saxon_XSLT

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

#239

Post by xorcist »

0x445442 wrote: post #182
colonwqbang wrote: post #167

Earlier quoted context omitted.

There have been many such cycles, but the XML hysteria of the 00s is the worst I can think of. It lasted a long time and the square peg XML was shoved into so many round holes.

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.

Agreed. Also, Docker.

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

#240

Post by badmintonbaseba »

thechao wrote: post #199
nithril wrote: post #146

Earlier quoted context omitted.

XSLT/XPath have evolved since XSLT 1.0. 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.

Can you name a non-Saxon XSLT processor? I'd really like one. Preferably, open-source.

I only know libxslt, but it's XSLT 1.0 and some of EXSLT. I don't recommend.
Post reply on HN