Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I Built a XSLT Blog Framework

vgr.land

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Show HN: I Built a XSLT Blog Framework

#61

Post by b_e_n_t_o_n »

qcnguy wrote: post #31

Disclaimer: it's possible XSLT got better over time, although I doubt it. I actually wrote a whole app that used XSLT back 25 years ago, even backed by an XML database! Super hip (tech stack wasn't my choice). XSLT is bad tech and you shouldn't use it. The modern equivalent is React+JSON which implements many of the same ideas in a much better way. And I say that as someone who isn't a big React fan but who has used…

Yeah it seems a bit nuts to me. Zero type safety, zero debugging story, no libraries, unusual syntax, it's not expressive like Javascript or other "real" programming languages, no interactivity, bad performance...I just don't get why people love it.

Re: Show HN: I Built a XSLT Blog Framework

#62

Post by riehwvfbk »

b_e_n_t_o_n wrote: post #14
riehwvfbk wrote: post #11

Earlier quoted context omitted.

It did make all those requests, but only because the author set up caching incorrectly. If the cache headers were to be corrected, site.xsl, pages.xml, and posts.xml would only need to be downloaded once.

The cache headers are correct, you can't indefinitely cache those because they might change. Maybe you could get away with a short cache time but you can't cache them indefinitely like you can a javascript bundle. Not to mention on a more involved site, each page will probably include a variety of components. You could end up with deeper nesting than just 4, and each page could reveal unique components further increa…

There are cache times other than 0 and infinity. Ideally the XSLT would change rarely, as would things like nav menus. So "relatively short" could mean several minutes to an hour. And with ETags the resource could be revalidated before expiry and never have to be re-downloaded.

Re: Show HN: I Built a XSLT Blog Framework

#63

Post by mpyne »

asteroidburger wrote: post #17
mpyne wrote: post #10

Earlier quoted context omitted.

> I don't foresee any equivalent native framework for styling JSON ever coming into being though. Well yeah I hope not! That's what a programming language is for, to turn data into documents.

XSLT 2.0 is Turing complete.

So are many esoteric languages, but I doubt people would appreciate me comparing XSLT to Brainfuck or FORTRAN 66.

Re: Show HN: I Built a XSLT Blog Framework

#64

Post by _heimdall »

IshKebab wrote: post #59
_heimdall wrote: post #44

Earlier quoted context omitted.

JSON is less complex because it only solves some of the problems that XML solves. That doesn't make it better or worse, but adding schema support or attempting to make REST APIs with JSON because complex, and IMO fragile, quickly.

It solves the important problems that XML solved, without the mistakes. What is it missing? I think only namespacing, but that isn't really necessary in JSON because it isn't a document format where arbitrary elements can appear in arbitrary places. I have never once needed namespacing in JSON. Schemas... well there's JSON schema which is ok I guess. But in reality you probably don't want that either. Schemas are use…

Validating JSON with third party runtime libraries like zod is only necessary because JSON doesn't support schemas though. There's nothing wrong with those libraries, they solve a real problem but the problem is in JSON itself.

The whole point of REST was to allow visitors to not only see the response to a request but to also be able to understand both the semantics and the functionality of it.

Think HTML - it would be comparatively useless if HTML could only contain structured data with meaning, semantics, or schemas. Anchor tags, buttons, and forms are semantic and tell the user not only what a piece of text is but how they can interact with it.

With JSON you have to know the shape of requests supported, the shape of data returned, and how to use that data to make other requests.

Re: Show HN: I Built a XSLT Blog Framework

#65

Post by chrismorgan »

cxr wrote: post #52
chrismorgan wrote: post #18

One recommendation I’d make: replace RSS with Atom. Outside of podcasting, everything that supports RSS supports Atom, and Atom is just better , in various ways that actually matter for content correctness, and in this case in ways that make it easier to process. One of the ways that matters here: Atom uses RFC 3339 date-time, rather than the mess that is RSS’s pubDate. As it stands, you’re generating an invalid JSON…

> Outside of podcasting, everything that supports RSS supports Atom, and Atom is just better Is there something (besides (lack of) client support) that makes RSS better suited for podcasting?

Absolutely nothing. Technically, it’s strictly worse. People even added other namespaces to patch up some of its deficiencies, e.g. .

I think the reason that RSS is used can be summed up as: Apple is lousy at developer relations.

They didn’t invent podcasting (name or technology), but they were the first major player to do stuff with it. Although consensus was already strong that RSS was technically terrible and Atom had existed for over a year (though it was not finalised) and was even fairly popular, Google especially having embraced it⸻ Apple chose the old-and-inferior RSS as their foundation. And then stuck their heads in the sand and didn’t talk to anyone, ever. Because that’s Apple’s style: throw stuff out there, let people do what they want with it, don’t attempt to be a community leader.

So what did everyone else do? Feeds had to be RSS, of course, to appease Apple. And then other apps implemented RSS, just RSS, like Apple had done, because what’s even the point of using Atom if it won’t work on the biggest platform? General-purpose feed readers didn’t have much specialised functionality, and had a few major players and a long tail of other clients; it was a much more well-distributed field, all things considered. But podcasting was, as I understand it, much more only one player for a while, then only up to two or three; and it depended on more specialised functionality. So it was never as democratic as general web feeds.

Over time podcast feeds ended up a horrible mess of repeating the same logical field 3–6 times in differently-named elements for different platforms, as they all added their own namespaces and mostly-identical-but-sometimes-slightly-different data fields¹. Because people were using it as an actual data format with domain-specific fields, they were more likely to just use an XML parser and talk just RSS, rather than a feed library which would be RSS-/Atom-neutral.

I believe that at some point Apple did implement Atom (not sure when), but it was too late, too much other stuff didn’t support it and so no one used it and so they ripped it out again a couple of years ago, and podcasting is set in stone using the inferior RSS.

I should write this up further at some point: the tragedy of podcast feeds.

—⁂—

¹ This stupid pattern can be seen on the web too. , , , something in a JSON+LD block…

Re: Show HN: I Built a XSLT Blog Framework

#66

Post by whizzter »

_heimdall wrote: post #44
whizzter wrote: post #40

Earlier quoted context omitted.

Depends on the task, JSON won because it was so simple whilst XML is waaay to complex. Maybe an alternative to JSON with just a tad more complexity for sanity could have won 20 years ago, but alas it never happened.

JSON is less complex because it only solves some of the problems that XML solves. That doesn't make it better or worse, but adding schema support or attempting to make REST APIs with JSON because complex, and IMO fragile, quickly.

On the contrary I think they did the right thing in not supporting any schema it.

1: The "simpleness" made it easy for producers/consumers with unstructured languages (ie JS,Python,PHP,Ruby,etc) to participate in the ecosystem without feeling that things were "bloated" (technically a drawback perhaps but pushed popularity)

2: DTD was put into the standard, but from my recollection most stuff was defined with XSD in practice (so a separate standard), so now implementations needed to carry both deprecated stuff and another layer. (Then again, sure you could generate bindings with XSD).

3: We needed 3 versions of Swagger/OpenAPI to come to a somewhat good standardized binding API (it itself depends/extends JSON Schema), but it's there today and we don't need to consider deprecated libraries,etc and can just point our code-generators to the schema documents and get automatic bindings.

So in practice you basically have no fragility today even if there is binding generator bugs, but that feels more of an implementation issue than a systematic error, and if anything it shows that schema generators.

Now one could argue that the "free-ness" of the JSON Format made schema generators needlessly cumbersome, and maybe that's true to a certain extent but it's still not nearly as bad as trying to interpret ASN.1 files despite all the standards (there it is.. "good luck trying to find the correct IDL files").

Re: Show HN: I Built a XSLT Blog Framework

#67

Post by b_e_n_t_o_n »

riehwvfbk wrote: post #62
b_e_n_t_o_n wrote: post #14

Earlier quoted context omitted.

The cache headers are correct, you can't indefinitely cache those because they might change. Maybe you could get away with a short cache time but you can't cache them indefinitely like you can a javascript bundle. Not to mention on a more involved site, each page will probably include a variety of components. You could end up with deeper nesting than just 4, and each page could reveal unique components further increa…

There are cache times other than 0 and infinity. Ideally the XSLT would change rarely, as would things like nav menus. So "relatively short" could mean several minutes to an hour. And with ETags the resource could be revalidated before expiry and never have to be re-downloaded.

ETags still require a round trip. You could cache for longer but now you have to deal with the complexities and struggles of caching.

Re: Show HN: I Built a XSLT Blog Framework

#68

Post by IshKebab »

_heimdall wrote: post #64
IshKebab wrote: post #59

Earlier quoted context omitted.

It solves the important problems that XML solved, without the mistakes. What is it missing? I think only namespacing, but that isn't really necessary in JSON because it isn't a document format where arbitrary elements can appear in arbitrary places. I have never once needed namespacing in JSON. Schemas... well there's JSON schema which is ok I guess. But in reality you probably don't want that either. Schemas are use…

Validating JSON with third party runtime libraries like zod is only necessary because JSON doesn't support schemas though. There's nothing wrong with those libraries, they solve a real problem but the problem is in JSON itself. The whole point of REST was to allow visitors to not only see the response to a request but to also be able to understand both the semantics and the functionality of it. Think HTML - it would…

> Validating JSON with third party runtime libraries like zod is only necessary because JSON doesn't support schemas though.

No this is completely backwards. First of all, JSON Schema exists. Second libraries like Serde and Pydantic aren't schema validators; they are parsers. They parse strings (or sometimes dynamically typed JSON) into statically typed objects that you can actually use in your program. That's what you should use.

A program that uses a separate schema validator and then blindly trusts the result is badly designed. There's even a name for this mistake - "parse don't validate" (you can Google it).

> With JSON you have to know the shape of requests supported, the shape of data returned, and how to use that data to make other requests.

Obviously. XML doesn't magically avoid the need for API documentation! I'm wondering if you've ever actually used XML at this point....

Re: Show HN: I Built a XSLT Blog Framework

#69

Post by riehwvfbk »

b_e_n_t_o_n wrote: post #67
riehwvfbk wrote: post #62

Earlier quoted context omitted.

There are cache times other than 0 and infinity. Ideally the XSLT would change rarely, as would things like nav menus. So "relatively short" could mean several minutes to an hour. And with ETags the resource could be revalidated before expiry and never have to be re-downloaded.

ETags still require a round trip. You could cache for longer but now you have to deal with the complexities and struggles of caching.

With HTTP/2 multiplexing all of those requests can be made in a batch without round trips. And complexity of caching? An Etag done right is content-based. There's no logic to worry about.

It's really unfortunate that this style of architecture lost the battle. It's elegant. Data cleanly separated from presentation, small digestible entities, and it all kind of makes sense. But what killed it was the verbosity of XML, as well as its extreme pedantry that results in lack of robustness where a single error would kill the entire transform. Also transformation-based systems notoriously lack proper tools for debugging early on. Lastly, typically buggy implementations of pipelining in HTTP/1.1 made it so that you actually had to make those round trips. But conceptually we had all the pieces to make it work well back in the early 2000s.

Re: Show HN: I Built a XSLT Blog Framework

#70

Post by stmw »

bawolff wrote: post #60
stmw wrote: post #50

Earlier quoted context omitted.

I don't think that follows, esp. since when we're talking about a mature, actively commercially maintained JIT engine.

Why not? JIT engines are inherently risky. They are great for performance but terrible for security.

Briefly, because

overall risk = new inherent risk / (architecture * security reputation * ongoing maintenance investment)

Even without arguing over whether JIT engines are inherently risky or add much risk given the modern computing environment is full of them, from graphics to Javascript.

Post reply on HN