Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's a lot of people saying "All we need to do is maintain libxslt" and a distinct lack of people actually stepping up to maintain libxslt.

I, for one, won't. Not for the purpose of keeping it in the browser. There are just too many other ways to do what it does for me to want that (and that's before we get into conversations about whether I want to be working with XML in the first place on the input side).

> not being lazy developers

Laziness is one of the three great virtues of programming. Every second not spent maintaining libxslt is a second we can spend on something more people care about.

It's a rule for writers, but it applies to software architecture also: kill your darlings.



Sure. But since this announcement I’ve been planning ways to support xslt. Here are the projects I’m considering:

- iced-ui browser with xslt + servo

- contribute to xslt xrust project

- investigate sandboxing xslt in firefox and implementing xrust

- same as the previous but for Chrome

- have an llm generate 1000s of static websites built in xslt and deploy them across the internet

- promote and contribute to the recent Show HN post of an xslt framework

I figure if I can generate enough effort to spam the web with xslt sites then they can’t remove it. Ultimately the first goal is to delay the removal from Chrome. This will delay the removal in other browsers. I don’t care if it’s ineffective. It’s better than doing nothing.

So you can take your lazy tenants of software engineering and your “hyuck Google knows best” eslewhere.


These are all great ideas and I support you pursuing what you are passionate about.


No you don’t because my passions are for a open technically varied unbroken web and you’ve spent the entire time trying to paint me as crazy for wanting any of that just because not all technology is equally popular or profitable for Google.


With respect: I've never called you crazy, nor did I imply it, nor did I mean to imply it.

I think your cost / benefit analysis on maintaining a native in-browser implementation of an old, niche declarative transformation language for a hard-to-read data format that hasn't been the dominant model of sending data to browser clients for at least fifteen years is flawed, but it's not crazy. Reasonable people can certainly put their priorities in different places, and I respect our priorities don't align on this topic and you have a right to your opinion.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: