Powerwash simulator is occasionally fun. There's shiny rewards, I don't have to deal with potential bad weather, and there's no random patches that take 20 times to get rid of. If I don't feel like powerwashing simulator, it will wait for me, forever, with no ill consequences or social judgement.
If I never wash my actual driveway, the same is not true. Therefore I will need to wash it at times when it's unpleasant or I don't want to, and it will take longer than powerwashing a driveway in Powerwash simulator.
The same day, a post on reddit was about: "We built 3B and 8B models that rival GPT-5 at HTML extraction while costing 40-80x less - fully open source" [1].
Not fully equivalent to what is doing Skyvern, but still an interesting approach.
Features are now available like key (index) to greatly speedup the processing.
Good XSLT implementation like Saxon definitively helps as well on the perf aspect.
When it comes to transform XML to something else, XSLT is quite handy by structuring the logic.
I never really grokked later XSLT and XPath standards though.
XSLT 1.0 had a steep learning curve, but it was elegant in a way poetry is elegant because of extra restrictions imposed on it compared to prose. You really had to stretch your mind to do useful stuff with it. Anyone remembers Muenchian grouping? It was gorgeous.
Newer standards lost elegance and kept the ugly syntax.
"Newer standards lost elegance and kept the ugly syntax."
My biggest problem with XSLT is that I've never encountered a problem that I wouldn't rather solve with an XPath library and literally any other general purpose programming language.
When XSLT was the only thing with XPath you could rely on, maybe it had an edge, but once everyone has an XPath library what's left is a very quirky and restrictive language that I really don't like. And I speak Haskell, so the critic reaching for the reply button can take a pass on the "Oh you must not like functional programming" routine... no, Haskell is included in that set of "literally any other general purpose programming language" above.
Serious question: would it be worth the effort to treat XSLT as a compilation target for a friendlier language, either extant or new?
There's clearly value in XSLT's near-universal support as a web-native system. It provides templating out of the box without invoking JavaScript, and there's demand for that[1]. But it still lacks decent in-browser debugging which JS has in spades.
SLAX is great, unfortunately it was released a bit too late.
XML world is full of ugly standards and failed contenders. None remembers RelaxNG. But had reacher expressive power than XMLSchema and a human-readable syntax.
It would at least be an interesting project. If someone put the elbow grease into it it is distinctly possible that an XSLT stylesheet could be not just converted to JS (which is obviously true and just a matter of effort), but converted to something that is at least on the edge of human usable and editable, and some light refactoring away from being decent code.
Just to add to this, we know have XXSLT which solves a lot of the original problems with XSLT.
Just to frame this people, imagine a JSON-based programming language for transforming JSON files into other JSON files and the program is also in JSON and turing complete. Now imagine it's not JSON but XML! Now any program can read it! Universal code, magic!
The idea behind XXSLT is now, we actually have a program whose job it is to specify a program. So we have a XML file which specifies a second XML file, which is the program, whose job it is to transform XML to XML. As we all know, layers of abstraction are always good, and common formats such as XML are especially good, so what we have now is the ability to generate a whole family and diverse ontology of programs, all of them XML, all of them by and for XML. Imagine the compiling with your favourite XML-based compilation chain!
XSLT just needs a different, non-XML serialization.
XML (the data structure) needs a non-XML serialization.
Similar to how Semantic Web's Owl has four different serializations, only one of them being the XML serialization. (eg. Owl can be represented in Functional, Turtle, Manchester, Json, and N-triples syntaxes.)
> XML (the data structure) needs a non-XML serialization.
KDL is a very interesting attempt, but my impression is that people are already trying to shove way too much unnecessary complexity into it.
IMO, the KDL's document transformation is not a really good example of a better XSLT, tough. I mean, it's better, but it probably can still be improved a lot.
XQuery is pretty close to "XSLT with sane syntax", if that's what you mean.
But the fundamental problem here is the same: no matter what new things are added to the spec, the best you can hope for in browsers is XSLT 1.0, even though we've had XSLT 3.0 for 8 years now.
S-expressions only represent nested lists. You need some other convention _on top of them_ to represent other kind of data, and that's generally the hard part.
Yeah... I posted too quickly: I want XSLT 3. The 1 & 2 specs are good first attempts, but are very difficult to use, effectively. As another poster also commented: it'd be nice if the implementation wasn't tied to XML, as well!
VSCode is really the primary platform for AI/agentic plugins, receiving priority over other IDEs such as IntelliJ, this is understandable as it is free, supporting many languages, and really good.
As a long-time IntelliJ user, I’m beginning to question whether it still makes sense to remain on this platform.
Perhaps I’m too impatient and agentic plugins may reach parity on IntelliJ within a year but a year is quite a long time to wait in this really fast-evolving landscape.
While your observation is generally true, and I share your overall concern about my IDE of choice, in this specific example it doesn’t apply as the Claude Code plugin for IntelliJ offers exactly the same integration as their plugin for VSCode.
Is your affirmation based on a testing of both plugin? I'm genuily wondering the plugin quality as IntelliJ plugin is still in beta and the VScode one not
I use IntelliJ (WebStorm) as my daily driver, and Claude Code is an integral part of my workflow. I didn’t check VSCode specifically, but I did read the link to that extension - everything they describe is precisely how the Claude Code works within WebStorm (despite being labeled “Beta”)
Appreciate your input, but if you haven’t actually tested the VSCode integration, it’s hard to compare. Reading a feature list isn’t the same as using the tool.
Okay, I just tried the Claude Code extension in VSCode - the experience is 100% identical to how it works within IntelliJ, even using the same icons and shortcuts to turn it on/off.
I was using webstorm some years ago, but after the switch to VS Code I never looked back. For me at least it was very laggy, UI bloated, and autocomplete would be unreliable for me due to constant "indexing".
I think what's at play here is the unusually palpable crowding out effects of tourism compared to any other industry. That is, when local stores get replaced by tourism shops, Landmarks etc. become more important than everyday amenities and the town becomes a sort of museum of itself.
Of course tourism can pipe in money and help a place invest in high quality services and amentaties compared to catering to industry.
However tourism often has a tremendous income distribution problem (see Hawaii or Colorado living conditions of service workers). This remains a fundamentally political problem to guarantee income distribution through living wage guarantees etc.
Most of the case it is because more building is simply not possible.
And anyway as long as there is no restrictions on the day-rental, investor will choose the option in their economical self-interest. Restriction must apply to force long term rentals.
In addition the graph "Massive VRAM Savings" graph states what looks like a tautology, reducing from 16 bits to 4 bits leads unsurprisingly to a x4 reduction in memory usage
reply