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

71–80 of 337 posts

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

#71

Post by rsolva »

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…

Browsers support XSLT v1.0 only, and from what I understand, there has been talk of depricating it.

I would rather that they introduced support for v3, as that would make it easier to serving static webpages with native support for templating.

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

#72

Post by masklinn »

codeulike wrote: post #40
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…

Xpath would have been nice if you didnt have to pedantically namespace every bit of every query

That… has nothing to do with xpath?

If your document has namespaces, xpath has to reflect that. You can either tank it or explicitly ignore namespaces by foregoing the shorthands and checking `local-name()`.

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

#76

Post by masklinn »

pjmlp wrote: post #52

I love XSLT, that is what I ported my site to after the CGI phase. Unfortunately it is not a sentiment that is shared by many, and many developers always had issues understanding the FP approach of its design, looking beyond the XML. 25 years later we have JSON and YAML formats reinventing the wheel, mostly badly, for that we already had nicely available on the XML ecosystem. Schemas, validation, graphical transforma…

> many developers always had issues understanding the FP approach of its design, looking beyond the XML.

It would probably help if xslt was not a god-awful language even before it was expressed via an even worse syntax.

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

#77

Post by susam »

notpushkin wrote: post #61
elcapitan wrote: post #38

> how I can run it? open XML file > open blog.xml -a Safari This didn't work for me on my browsers (FF/Chrome/Safari) on Mac, apparently XSLT only works there when accessed through HTTP: $ python3 -m http.server --directory . $ open http://localhost:8000/blog.xml I remember long hours using XSLT to transform custom XML formats into some other representation that was used by WXWindows in the 2000s, maybe I should give…

> --directory . Huh, neat! Did’t know it supported that. (python3 -m http.server will default to current directory anyway though)

Yes! I often use a command like this to test my statically generated website locally using a command like this:

  python3 -m http.server -d _site/
Example: https://github.com/susam/susam.net/blob/0.3.0/Makefile#L264-...

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

#78

Post by rsolva »

em-bee wrote: post #46

i have a static website with a menu. keeping the menu synchronized over the half dozen pages is a pain. my only option to fix this are javascript, xslt or a server side html generator. (and before you ask, static site generators are no better, they just make the generation part manual instead of automatic.) i don't actually care if the site is static. i only care that maintenance is simple. build tools are not simple…

I recently tried building a website using Server Side Includes (SSI) with apache/nginx to make templates for the head, header and footer. Then I found myself missing the way Hugo does things, using a base template and injecting the content into the base template instead.

This was easy do achieve with PHP with a super minimal setup, so I thought, why not? Still no build steps!

PHP is quite ubiquitous and stable these days so it is practically equivalent to making a static site. Just a few sprinkles of dynamism to avoid repeting HTML all over the place.

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

#79

Post by JimDabell »

jonwinstanley wrote: post #62
viraptor wrote: post #56

Earlier quoted context omitted.

That timeline doesn't sound right to me. JS was rarely used to standardise behaviour - we had lots of user agent detection and relying on quirks ordering to force the right layout. JS really was for the interactivity at the beginning - DHTML and later AJAX. I don't think it even had easy access to layout related things? (I may be mistaken though) CSS didn't really make things more consistent either - once it became c…

For me, JQuery was the thing that fixed the browser inconsistencies. If you used JQuery for everything, your code worked in all the browsers. This was maybe 2008?

jQuery in ~2008 was when it kinda took off, but jQuery was itself an outgrowth of work done before it on browser compatibility with JavaScript. In particular, events.

Internet Explorer didn’t support DOM events, so addEventListener wasn’t cross-browser compatible. A lot of people put work in to come up with an addEvent that worked consistently cross-browser.

The DOMContentLoaded event didn’t exist, only the load event. The load event wasn’t really suitable for setting up things like event handlers because it would wait until all external resources like images had been loaded too, which was a significant delay during which time the user could be interacting with the page. Getting JavaScript to run consistently after the DOM was available, but without waiting for images was a bit tricky.

These kinds of things were iterated on in a series of blog posts from several different web developers. One blogger would publish one solution, people would find shortcomings with it, then another blogger would publish a version that fixed some things, and so on.

This is an example of the kind of thing that was happening, and you’ll note that it refers to work on this going back to 2001:

https://robertnyman.com/2006/08/30/event-handling-in-javascr...

When jQuery came along, it was really trying to achieve two things: firstly, incorporating things like this to help browser compatibility; and second, to provide a “fluent” API where you could chain API calls together.

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

#80

Post by benediktwerner »

jonwinstanley wrote: post #62
viraptor wrote: post #56

Earlier quoted context omitted.

That timeline doesn't sound right to me. JS was rarely used to standardise behaviour - we had lots of user agent detection and relying on quirks ordering to force the right layout. JS really was for the interactivity at the beginning - DHTML and later AJAX. I don't think it even had easy access to layout related things? (I may be mistaken though) CSS didn't really make things more consistent either - once it became c…

For me, JQuery was the thing that fixed the browser inconsistencies. If you used JQuery for everything, your code worked in all the browsers. This was maybe 2008?

Wasn't it more about inconsistencies in JS though? For stuff which didn't need JS at all, there also shouldn't be much need for JQuery.
Post reply on HN