Nice!
I always wanted to build an XSLT that parses Markdown and outputs HTML, but was lacking the time. That would elevate your blog framework to a wider audience.
Show HN: I Built a XSLT Blog Framework
51–60 of 71 posts
Re: Show HN: I Built a XSLT Blog Framework
#52One 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?
Re: Show HN: I Built a XSLT Blog Framework
#53Suggestion, replace this:
Last Blog Post
I am Jack's XML Parser. I consume unclosed tags I kill jack.
https://xsltblogdemo.vgr.land/content/posts/20250707.xml
post-20250707
Mon, 7 Jul 2025 13:00:00 +0000
vgr.xsltbf@example.com (vgr)
Content of the post....
Re: Show HN: I Built a XSLT Blog Framework
#54Earlier quoted context omitted.
I think it would be very unlikely browsers would use a jit engine for xslt. They are removing it because they are afraid of the security footprint. A JIT engine would make that footprint much worse.
Not necessarily. The security issues are with the libxml implementation, a different one might be more secure even with JIT. That's part of what makes the whole situation so ridiculous.
Whether or not it is actually secure, as a factual matter, has nothing to do with its security footprint.
Re: Show HN: I Built a XSLT Blog Framework
#55Earlier quoted context omitted.
Emphasis on might be . Finding out whether it actually is is not a trivial process.
There are multiple CVEs in multiple Chrome-only non-standards that Chrome spits out by the hundreds in the past few years. They have no issues releasing those, supporting them, and fixing them. Somehow they have an issue with supporting, fixing (and updating to latest version) this particular one. Possibly because it doesn't result in promotions.
This often ends up as an anti-Google argument but all the major browser makers agree with this deprecation proposal.
Re: Show HN: I Built a XSLT Blog Framework
#56Suggestion, replace this: Last Blog Post I am Jack's XML Parser. I consume unclosed tags I kill jack. https://xsltblogdemo.vgr.land/content/posts/20250707.xml post-20250707 Mon, 7 Jul 2025 13:00:00 +0000 vgr.xsltbf@example.com (vgr) With this: Content of the post....
I don't know if this is intentionally hilarious or unintentionally hilarious, I guess it's the same result either way.
Re: Show HN: I Built a XSLT Blog Framework
#57Suggestion, replace this: Last Blog Post I am Jack's XML Parser. I consume unclosed tags I kill jack. https://xsltblogdemo.vgr.land/content/posts/20250707.xml post-20250707 Mon, 7 Jul 2025 13:00:00 +0000 vgr.xsltbf@example.com (vgr) With this: Content of the post....
I don't know if this is intentionally hilarious or unintentionally hilarious, I guess it's the same result either way.
[dead]
Re: Show HN: I Built a XSLT Blog Framework
#58Suggestion, replace this: Last Blog Post I am Jack's XML Parser. I consume unclosed tags I kill jack. https://xsltblogdemo.vgr.land/content/posts/20250707.xml post-20250707 Mon, 7 Jul 2025 13:00:00 +0000 vgr.xsltbf@example.com (vgr) With this: Content of the post....
Perfectly illustrating one of XML's stupidest flaws.
Re: Show HN: I Built a XSLT Blog Framework
#59Earlier 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.
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 useful for IDEs and linters but that's it. Normally you validate a JSON file by parsing it, e.g. with Pydantic or Serde or Zod.
The biggest missing feature from XML that JSON should have had is comments! Yes it was a mistake to omit them.
Re: Show HN: I Built a XSLT Blog Framework
#60Earlier quoted context omitted.
I think it would be very unlikely browsers would use a jit engine for xslt. They are removing it because they are afraid of the security footprint. A JIT engine would make that footprint much worse.
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.