> For over a decade, Chrome has supported millions of organizations with more secure browsing – while pioneering a safer, more productive open web for all.
… and …
> Our commitment to Chromium and open philosophy to integration means Chrome works well with other parts of your tech stack, so you can continue building the enterprise ecosystem that works for you.
Per the current version of https://developer.chrome.com/docs/web-platform/deprecating-x..., by August 17, 2027, XSLT support is removed from Chrome Enterprise. That means even Chrome's enterprise-targeted, non-general-web browser is going to lose support for XSLT.
Most people who use xslt like the grandparent described were never using it on the client side but on the server side. Nothing google chrone does will effect the server side.
To clarify: initially, the first web browser evolved from a SGML-based documentation browser at CERN. This was the first vision of the web: well-structured content pages, connected via hyperlinks (the "hyper" part meaning that links could point beyond the current set of pages). So, something like a global library. Many people are still nostalgic to this past.
Surprisingly, the "hyperlinked documents" structure was universal enough to allow rudimentary interactive web applications like shops or reservation forms. The web became useful to commerce. At first, interactive functionality was achieved by what amounted to hacks: nav blocks repeated at every page, frames and iframes, synchronous form submissions. Of course, web participants pushed for more direct support for application building blocks, which included Javascript, client-side templates, and ultimately Shadow DOM and React.
XSLT is ultimately a client-side template language too (can be used at the server side just as well, of course). However, this is a template language for a previous era: non-interactive web of documents (and it excels at that). It has little use for the current era: web of interactive applications.
What makes XSLT inherently unsuitable for an interactive application in your mind? All it does is transform one XML document into another; there's no earthly reason why you can't ornament that XML output in a way that supports interactive JS-driven features, or use XSLT to built fragments of dynamically created pages that get compiled into the final rendered artifact elsewhere.
My only use of XSLT (2000-2003) was to make interactive e-learning applications. I'd have used it in 2014 too, for an interactive "e-brochure", if I could have worked out a cross-browser solution for runtime transformation of XML fragments. (I suspect it was possible then but I couldn't work it out in the time I had for the job...)
If you can use it to generate HTML, you can use it to generate an interactive experience.
I don't understand the point. The entire raison d'être of this project is that you self-host it and don't pay money for S3 and control your supply chain.
If you are denied this possibility — it is much easier just to use S3.
Ahem. Some people never heard of immigration/emigration?
(The system is valuable for adults too, if some of your relatives live in a country which blocks Whatsapp and other voice calling apps, like Russia or China).
Ah, the company where the models are unusable even with Pro subscription (start to hit the limit after 20 minutes of talking), and free models are not usable at all (currently can't even send a single message to Sonnet 4.5)...
I like modern C++ much better than Rust. I am 3 times more productive in it and don't have to fight the compiler for hours. And RAII is a simple idiom that prevents 95% of actual problems.
Modern Fortran is quite easy. It is learned overnight by most physics students. At this point, it is more a fast compiled DSL for numerical computations (like MATLAB but _much_ faster), than a universal programming language.
reply