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

181–190 of 337 posts

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

#181

Post by chriswarbo »

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…

> part of the problem with the entire "XML as a savior" mindset of that earlier era

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

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

#182

Post by 0x445442 »

colonwqbang wrote: post #167
diggan wrote: post #138

Earlier quoted context omitted.

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

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.

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

#183

Post by ndriscoll »

em-bee wrote: post #165
bambax wrote: post #132

Earlier quoted context omitted.

> i have a static website with a menu. keeping the menu synchronized over the half dozen pages is a pain 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.

that's the server side html generator i already mentioned. ok, this one is not large, but it still ties me to a limited set of server platforms that support running php. and if i have to write code i may as well write javascript and get a platform independent solution. the point is, none of the solutions are completely satisfactory. every approach has its downsides. but most critically, all this complaining about peo…

You didn't actually indicate a downside to using xslt, and yes it would fit your use case of a static include for a shared menu, though the better way to do it is to move all of the shared pieces of your site into the template and then each page is just its content. Sort of like using a shared CSS file.

To just do the menu, if your site is xhtml, IIRC you could link to the template, use a in the page, and then the template just gives a rule to expand that to your menu.

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

#184

Post by viraptor »

p0w3n3d wrote: post #180
sim7c00 wrote: post #171

Earlier quoted context omitted.

Realplayer. christ, forgot all about that one.... thanks... frozenface

ah the feelings. those were the times

If your site didn't have a flash animated menu, was it even a real website at that time?

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

#185

Post by tannhaeuser »

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…

> bloat of '00s enterprise XML

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

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

#186

Post by em-bee »

ndriscoll wrote: post #183
em-bee wrote: post #165

Earlier quoted context omitted.

that's the server side html generator i already mentioned. ok, this one is not large, but it still ties me to a limited set of server platforms that support running php. and if i have to write code i may as well write javascript and get a platform independent solution. the point is, none of the solutions are completely satisfactory. every approach has its downsides. but most critically, all this complaining about peo…

You didn't actually indicate a downside to using xslt, and yes it would fit your use case of a static include for a shared menu, though the better way to do it is to move all of the shared pieces of your site into the template and then each page is just its content. Sort of like using a shared CSS file. To just do the menu, if your site is xhtml, IIRC you could link to the template, use a in the page, and then the te…

the downside to xslt is xslt itself, and lack of maintenance of xslt support in the browser. (browsers only supports xslt 1.0 and it looks like even that may be dropped in the future, making its use not futureproof without server side support)

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

#187

Post by samuell »

In the early 2000s, XSLT allowed me as a late teenager with some HTML experience but without real coding skills (I could copy some lines of PHP from various forums and get it to work) to build a somewhat fancy intranet for a local car shop, complete with automatic styling of a feed of car info from a nationwide online sales portal.

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.

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

#188

Post by samuell »

samuell wrote: post #187

In the early 2000s, XSLT allowed me as a late teenager with some HTML experience but without real coding skills (I could copy some lines of PHP from various forums and get it to work) to build a somewhat fancy intranet for a local car shop, complete with automatic styling of a feed of car info from a nationwide online sales portal. Somehow it took me many years, basically until starting uni and taking a proper progra…

In later years, I returned to XSLT to try parsing a structured text format for tool definitions in the Galaxy bioinformatics platform.

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:

https://www.youtube.com/watch?v=WMjXsBVqp7s

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

#189

Post by chriswarbo »

bob1029 wrote: post #99
p0w3n3d wrote: post #34

Ok, so it might be a long shot, but I would say that 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…

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

> 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`)

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

#190

Post by em-bee »

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…

Those were defined as machine language meant for machine talking to machine

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.

Post reply on HN