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

311–320 of 337 posts

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

#311

Post by j45 »

larodi wrote: post #267
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,…

XSLt is not easy. It’s prologue on shrooms so to speak and it has a steep learning curve. Once mastered gives sudoku level satisfaction, but can hardly ever be a standard approach to built or templating as normally people need much less to achieve goals. Besides XML is not universally loved.

Universal love is one factor, best tool for a job may leave only a few choices including XML.

It's not my first choice, but I won't rule it out because I know how relatively flexible and capable it can be.

XSLT might just need a higher abstraction level on top of it?

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

#313

Post by tootie »

int_19h wrote: post #309
tootie wrote: post #307

Earlier quoted context omitted.

I never enjoyed XSLT. It always felt like a square peg for a round hole. I do miss XML though. It had so, so many power features that too few people knew how to use. XSD was incredibly good for domain modeling. It had an include systems for composing files. And nobody really made good use of mixed content, but it was a crazy powerful feature. You embed structured content in unstructured content inside structured cont…

The original idea was good: having a purely declarative language running on the client which just does the model -> view transformation, and having the server serve the models. XSLT as an implementation of that idea is pretty bad, but mostly because using XML as the underlying syntax for a PL is very unergonomic. If the initial version of XSLT looked more like XQuery does, I think it would have been a lot more popula…

Yeah, the idea makes sense. More sense than CSS which ended requiring years and years of refinement and pre-processors to be usable.

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

#314

Post by giantrobot »

This elides a huge advantage to this approach: your blog (or whatever) is just raw data. Consuming it with a browser applies the linked stylesheet and spit out HTML. But you can consume the endpoint with anything.

For instance you could share a music playlist as an XSPF document. In the browser your style sheet could make it into a nice web page with audio tags to play the content. But that exact same endpoint opened with VLC would just treat it as a normal playlist.

You can just publish raw data (with robust schema validation) and each user agent will handle it appropriately. Even a bare bones style sheet could just say "open this URL with some particular application.

Since the XSLT engine is built into browsers you get a free transformation engine without any JavaScript.

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

#315

Post by vjvjvjvjghv »

SoftTalker wrote: post #298
vjvjvjvjghv wrote: post #282

Earlier quoted context omitted.

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.

The only problem with XML is the verbosity of the markup. Otherwise it's a nice way to structure data without the bizarre idiosyncracies of YAML or JSON.

XML has its own set of idiosyncrasies like everything being a string. Or no explicit markup of arrays. The whole confusion around attributes vs values. And many others.

JSON has its own set of problems like lack of comments and for some reason no date type.

But in the end they are just data file formats. We have bigger things to worry about.

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

#316

Post by Lex-2008 »

chrismorgan wrote: post #30

I’m disappointed that this uses a custom XML format, rather than RSS (tolerable) or Atom (better). Then you could just drop it into a feed reader fine. A few years ago, I decided to style my own feeds, and ended up with this: https://chrismorgan.info/blog/tags/fun/feed.xml . https://chrismorgan.info/atom.xsl is pretty detailed, I don’t think you’ll find one with more comprehensive feature support. (I wrote a variant…

Hey, thanks a lot for the atom.xsl! Used it to learn a lot while converting main page of my blog to an Atom feed half a year ago.

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

#317

Post by p0w3n3d »

middleagedman wrote: post #104
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…

Old guy here. Agreed- the actual story of web development and JavaScript’s use was much different. HTML was the original standard, not JS. HTML was evolving early on, but the web was much more standard than it was today. Early-mid 1990s web was awesome. HTML served HTTP, and pages used header tags, text, hr, then some backgound color variation and images. CGI in a cgi-bin dir was used for server-side functionality, o…

I must contradict. 2005-6 was happening my PRADO development, which already was present on market as a framework that was exensively using javascript (mimicking Microsoft's ASP.NET forms) to make AJAX requests and regenerate states of components that were placed on the web page using DOM.

The thing was that it was really hard to write code that did the same DOM + placement on all the browsers, and if a framework could do that, this was becoming great help. I started my webpage development in 2000-ish with if (`document.forms /* is ie */`) ... and was finding a way to run IE on my Linux computer to test the webpage rendering there. And CSS 2 was released on 1998 and could change everything and was the Deus Ex Machine everyone expected, except for it didn't work, especially on IE (which had majority of market, and especially if you developed a business application, you had to count it as the majority of all your clients, if not the only ones). So in CSS 2 you could __allegedly__ do things you really needed, like placing things together or in a related position, instead of calculating browser's sizes etc., but it didn't work correctly, so you had to fallback to javascript `document.getElementById().position = screenWidth/2 etc`.

So according to my memory, (1) these were the dark times mainly because of m$ being lazy and abusing their market position (2) we used javascript to position elements, colorize them, make complicated bevels, borders etc (3) this created gap for Google that they could use to gain power (which we admired at that time as the saviours of the web) (4) Opera was the thing and Resistance icon (boasting themselves of fulfilling all standards and being fast, but they failed a few times too)

also DSL, LAN internet sharing and AOL (in Poland 0202122 ppp/ppp), tshshshshshs, tidutidumtidum, tshshshshshsh ...

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

#318

Post by p0w3n3d »

Tade0 wrote: post #89
catmanjan wrote: post #87

Earlier quoted context omitted.

Lol you'd hate to see what blazor is doing then

Or Phoenix.LiveView for that matter.

I have no hate/love relation to that matter. Tbh I don't care, but my phone gets hot when it has to load another 5/10/20/100MB Single Page Application that displays a few lines of nicely formatted text, an animated background and a button "subscribe"

By the way, GWT did it before.

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

#319

Post by riedel »

Funnily back in the 90s working as a webdesigner in my high school years (whatever you would call web design these days), I remember building a DSSSL- dialect based pipeline to generate websites from a newsfeed published. I still like XSLT transformations. I even used the bananas XI reader [0] to transform actual text using XSLT for transforming and templating . I have, however, met few people that also appreciated this. Often such tooling was replaced once someone else took over the job...

[0] http://www.ananas.org/xi/

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

#320

Post by SkiFire13 »

jimbokun wrote: post #281
echelon wrote: post #212

Earlier quoted context omitted.

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.

S-expressions only represent nested lists. You need some other convention _on top of them_ to represent other kind of data, and that's generally the hard part.
Post reply on HN