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

91–100 of 337 posts

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

#91

Post by arccy »

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…

it works, i think the most visible ones are where people style their atom / rss feeds instead of rendering separate xml / html pages https://rknight.me/blog/styling-rss-and-atom-feeds/

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

#92

Post by JimDabell »

maxloh wrote: post #63
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…

However, XML is actually a worse format to transfer over the internet. It's bloated and consumes more bandwidth.

XML is a great format for what it’s intended for.

XML is a markup language system. You typically have a document, and various parts of it can be marked up with metadata, to an arbitrary degree.

JSON is a data format. You typically have a fixed schema and things are located within it at known positions.

Both of these have use-cases where they are better than the other. For something like a web page, you want a markup language that you progressively render by stepping through the byte stream. For something like a config file, you want a data format where you can look up specific keys.

Generally speaking, if you’re thinking about parsing something by streaming its contents and reacting to what you see, that’s the kind of application where XML fits. But if you’re thinking about parsing something by loading it into memory and looking up keys, then that’s the kind of application where JSON fits.

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

#93

Post by xg15 »

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 don't see how people would have any incentive to adopt it.

The tragic thing is that there are other pure-functional XML transformation languages that are really well-designed - like XQuery. But there is no browser that supports those.

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

#94

Post by cess11 »

XML is great, one just need to have the appropriate tooling. XSLT, like XSD, is XML too, so the same tooling apply to those as well.

If you're manually writing the -stuff in an editor you're doing it wrong, do it programmatically or with applications that abstract it away.

Use things like JAXB or other mature libraries, eXist-db (http://exist-db.org), programs that can produce visualisations and so on.

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

#95

Post by meinersbur »

There is a classic DailyWTF about this technique: https://thedailywtf.com/articles/Sketchy-Skecherscom

> [...] the idea of building a website like this in XML and then transforming it using XSL is absurd in and of itself [...]

In the comments the creators comment on it, like that it was a mess to debug. But I could not find anything wrong with the technique itself, assuming that it is working.

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

#96

Post by [deleted] »

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…

[deleted]

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

#98

Post by woodpanel »

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

Same here.

A couple of blue chip websites I‘ve seen that could be completely taken down just by requesting the sitemap (more than once per minute).

PS: That being said it is an implantation issue. But it may speak for itself that 100% of the XSLT projects I‘ve seen had it.

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

#99

Post by bob1029 »

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 to compose view-specific response shapes. Getting the data in the right shape before interpolating HTML strings can really help with performance in some of those edges like building a table with 100k rows. LINQ is fast, but approaches like materializing a collection per row can get super expensive as the # of items grows.

The closer together you can get the HTML templating engine and the database, the better things will go in my experience. At the end of the day, all of that fancy structured DOM is just a stream of bytes that needs to be fed to the client. Worrying about elaborate AST/parser approaches when you could just use StringBuilder and clever SQL queries has created an entire pointless, self-serving industry. The only arguments I've ever heard against using something approximating this boil down to arrogant security hall monitors who think developers cant be trusted to use the HTML escape function properly.

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

#100

Post by bayindirh »

People love to complain about verbosity of XML, and it looks complicated from a distance, but I love how I can create a good file format based on XML, validate with a DTD and format with XSLT if I need to make it very human readable.

XML is the C++ of text based file formats if you ask me. It's mature, batteries included, powerful and can be used with any language, if you prefer.

Like old and mature languages with their own quirks, it's sadly fashionable to complain about it. If it doesn't fit the use case, it's fine, but treating it like an abomination is not.

Post reply on HN