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

241–250 of 337 posts

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

#241

Post by homebrewer »

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.

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

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

#242

Post by noisy_boy »

I used XSLT in the past for trade message transformation from one format of XML (produced by an upstream system) to another (used by the downstream consuming system). It works reasonably well for not overly complex stuff but debugging things are a pain once the complexity increases. Prefer to not do that again.

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

#243

Post by bmacho »

kbolino wrote: post #237
alganet wrote: post #219

Earlier quoted context omitted.

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

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

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

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

#244

Post by dragonwriter »

ChrisMarshallNY wrote: post #238
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.o…

Are you saying it is specified that you literally cannot implement it other than on top of, or by mimicing bug-for-bug, that library (the way it was impossible to implement WebQSL without a particular version of SQLite) or is Saxon XSLT just the only existing implementation of the spec?

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

#245

Post by nolok »

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.

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.

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

#246

Post by kbolino »

bmacho wrote: post #243
kbolino wrote: post #237

Earlier quoted context omitted.

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…

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

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

#247

Post by alganet »

kbolino wrote: post #237
alganet wrote: post #219

Earlier quoted context omitted.

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

You can see frames in action on the POSIX spec:

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.

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

#248

Post by kbolino »

alganet wrote: post #247
kbolino wrote: post #237

Earlier quoted context omitted.

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…

You can see frames in action on the POSIX spec: 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 worke…

An iframe is inherently subordinate. This solves one of the major issues with classic frames.

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?

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

#249

Post by jraph »

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.

- Browsers are XSLT (1.0) processors.

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

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

#250

Post by bmacho »

What an incoherent writing lol. I'm not sure if grug = incoherent necessarily, but I'm sure that there is the type of genius that every sentence of them is painfully clear. Wouldn't it be better to cater towards that?

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.

Post reply on HN