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

281–290 of 337 posts

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

#281

Post by jimbokun »

echelon wrote: post #212
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.

XSLT just needs a different, non-XML serialization. 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.)

You're looking for S-expressions.

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

#282

Post by vjvjvjvjghv »

nolok wrote: post #115
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,…

It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them, doesn't matter if XSLT or SOAP or even XHTML in a way ... Those were defined as machine language meant for machine talking to machine, and invariably something go south and it's not really made for us to intervene in the middle; it can be done but it's way more work than it s…

Now we have "JSON as savior". I see it way too often where new people come into a project and the first thing they want to do is to replace all XML with JSON, just because. Never mind that this solves basically nothing and often introduces its own set of problems. I am not a big fan of XML but to me it's pretty low in the hierarchy of design problems.

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

#283

Post by vjvjvjvjghv »

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.

Exactly. Compared to microservices XML is a pretty minor problem.

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

#284

Post by kbolino »

alganet wrote: post #277
kbolino wrote: post #272

Earlier quoted context omitted.

Directionally correct but badly done can poison an idea. Frames sucked and never got better. 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 impro…

Your history is off, and you are mixing different eras and browser standards with other initiatives. 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 e…

I feel like we're mostly in violent agreement.

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

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

#285

Post by marcosdumay »

echelon wrote: post #212
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.

XSLT just needs a different, non-XML serialization. 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.)

> XML (the data structure) needs a non-XML serialization.

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.

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

#287

Post by marcosdumay »

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…

Do you remember when people started talking about XHTML?

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.

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

#288

Post by asa400 »

ako wrote: post #276
nolok wrote: post #245

Earlier quoted context omitted.

The people who made that are either very funny in a sarcastic, way or in severe lack of a history lesson of the area they're working in.

What is a better alternative if you just need to transform JSON from one structure to another JSON structure?

Load it into a full programming language runtime and use the great collections libraries available in almost all languages to transform it and then serialize it into your target format. I want to use maps and vectors and real integers and functions and date libraries and spec libraries. String to string processing is hell.

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

#289

Post by [deleted] »

nolok wrote: post #115
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,…

It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them, doesn't matter if XSLT or SOAP or even XHTML in a way ... Those were defined as machine language meant for machine talking to machine, and invariably something go south and it's not really made for us to intervene in the middle; it can be done but it's way more work than it s…

[deleted]

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

#290

Post by rorylaitila »

ako wrote: post #276
nolok wrote: post #245

Earlier quoted context omitted.

The people who made that are either very funny in a sarcastic, way or in severe lack of a history lesson of the area they're working in.

What is a better alternative if you just need to transform JSON from one structure to another JSON structure?

Imperative code. Easy to mentally parse, comment, log, splice in other data. Why add another dependency just to go from json>json? That'd need an exceptional justification.
Post reply on HN