←back to thread

116 points vgr-land | 1 comments | | HN request time: 0.21s | source

A few weeks ago a friend sent me grug-brain XSLT (1) which inspired me to redo my personal blog in XSLT.

Rather than just build my own blog on it, I wrote it up for others to use and I've published it on GitHub https://github.com/vgr-land/vgr-xslt-blog-framework (2)

Since others have XSLT on the mind, now seems just as good of a time as any to share it with the world. Evidlo@ did a fine job explaining the "how" xslt works (3)

The short version on how to publish using this framework is:

1. Create a new post in HTML wrapped in the XML headers and footers the framework expects.

2. Tag the post so that its unique and the framework can find it on build

3. Add the post to the posts.xml file

And that's it. No build system to update menus, no RSS file to update (posts.xml is the rss file). As a reusable framework, there are likely bugs lurking in CSS, but otherwise I'm finding it perfectly usable for my needs.

Finally, it'd be a shame if XSLT is removed from the HTML spec (4), I've found it quite eloquent in its simplicity.

(1) https://news.ycombinator.com/item?id=44393817

(2) https://github.com/vgr-land/vgr-xslt-blog-framework

(3) https://news.ycombinator.com/item?id=44988271

(4) https://news.ycombinator.com/item?id=44952185

(Aside - First time caller long time listener to hn, thanks!)

Show context
stmw ◴[] No.45009206[source]
It's nice to see this. Things used to be simple! (XSLT itself should've been simpler of course).

BTW, as I commented on earlier HN threads re: removal of XSLT support from HTML spec and browswers, IBM owns a high-performance XSLT implementation that they may want to consider contributing to one or more browsers. (It is a JIT that generates machine code directly from XSLT and several other data transformation and policy languages, and then executes it).

replies(2): >>45009901 #>>45013010 #
bawolff ◴[] No.45009901[source]
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.
replies(2): >>45011705 #>>45014299 #
stmw ◴[] No.45014299[source]
I don't think that follows, esp. since when we're talking about a mature, actively commercially maintained JIT engine.
replies(1): >>45020280 #
bawolff ◴[] No.45020280[source]
Why not? JIT engines are inherently risky. They are great for performance but terrible for security.
replies(1): >>45028571 #
1. stmw ◴[] No.45028571[source]
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.