They don't care. The big selling point besides being able to run on every platform is that users understand there is no reasonable expectation of quality when it comes to the web. If a desktop application freezes up and crashes, users will gnash their teeth and curse your name while they are pressing ctrl-alt-del and trying to get their system going again. A massive pile of react slop? Just shrug and refresh the page.
> If a desktop application freezes up and crashes, users will gnash their teeth and curse your name while they are pressing ctrl-alt-del and trying to get their system going again.
Nowadays: Electron slop that will also eat a bunch of their RAM.
Personally I think that’s due to the failure of native development properly taking off: you know, actually being good and easy instead of a long line of dead or half dead attempts; alongside platform vendors hating each other and each having a vastly different GUI framework instead of some inter-OS WG to come up with at least good common standards.
Imagine if you could ship your desktop app in a natively running virtual machine, that is as perfect as it gets from sandboxing code and running a lightning fast JIT compiler instead of virtualization. It delivers a common user experience, digital accessibility, endless customization while being secure, it's free for developers and users, constantly updated and it delivers an absurdly powerful, while also perfectly printable markup and styling engine.
It is wild to look back at XHTML and see that the W3C were entirely correct about XML. They envisaged a world of schemas, client side templating, custom elements, dynamic forms, the works.
Alas, for laughably bad reasons we had to scrap all that for HTML5, Javascript and CSS; a stack so awful that most devs doing anything on the frontend immediately scramble to React, TypeScript, Tailwind, whatever it takes to avoid the underlying garbage.
A horrid state of affairs that will only get worse as time goes on.
The XHTML/XML/XSLT tooling was bad, and XSLT was hard to reason about. That meant that amateurs had no way to learn it, and those amateurs went to school and became the workforce.
The web became a winner because it was easy to get something working. And then Google made it a mission to make great developer tools in everyone's hands for free.
I think in 2026 we could build the tooling around a better experience, but it would require thinking about the developer experience first.
You could do some awesome things with XML/XSL. My favorite was RSS feeds or OPML collections of RSS feeds (both flavors of XML) calling an XSL transformation when viewed in a web browser instead of mined by computers for data; same with TEI files, although that was a bit more arcane. The idea was that you'd have one data file for machine use and a way to present that data to humans as a web page.
But, as a stack, the XML/XSL/XPath/etc combination was weak because XSLT was hard to comprehend and never updated. No browser supports XSLT 2 or 3; they froze support with 1. XSLT 2 was 2007, a year before HTML 5 was a thing, yet it never got picked up by browsers. Javascript was just easier to understand than XSLT. Development of XHTML was also glacial, and people wanted new tags, especially for video.
> XSLT 2 was 2007, a year before HTML 5 was a thing, yet it never got picked up by browsers. Javascript was just easier to understand than XSLT.
Turns out that tasks easily done by programming languages are best done by programming languages. Who knew?
JSON allowing frontends and backends to communicate in a way analogous to the "smart endpoints, dumb pipes" model for networking saved the Web. The XML adherents wanted the inverted model, which was always insanely difficult to reason about and led to entirely XML-specific security threats.
I can't help but agree, and sometimes I think about the alternate version of the web where XML realized its full potential as the dominant technology. The obvious problem with XML is that the syntax is so verbose and redundant that it's only barely human-writable, but this is 100% a solvable problem.
Is that really accurate? In a world where HTML5 never happened, how would XHTML/XSLT solve the same problems that modern front-end Javascript frameworks do (interactive data-driven websites)? I say this as someone who thinks XSLT is a really useful technology, and doesn't want it to be deprecated.
That browser world would of been glorious without HTML5. Where Javascript wasn't in the browser and Tcl was (it was a contender); we would be working with plugin based browsers rather than built-in to the hood. That in turn would enable you to process incoming documents based in XSLT however you desired.
It would of been glorious having any programming language usable within the browser. Craft your own features rather than what's given to you now. It's only now that we're gaining the ability to use other languages via WASM.
Tcl was a contender to Javascript in the browser but Javascript won because it didn't require a plugin. And as Tcl never became the browser's default scripting environment juxtaposition Flash eventually lost because the browser platform evolved to make its proprietary plug-in unnecessary
> ...we would be working with plugin based browsers rather than built-in to the hood...
How is that different from sites using Java applets, which were pretty much universally loathed when we had them?
> ...Tcl...
How is Tcl better than Javascript?
> ...Flash...
I'm not sure I really understand what point you're making here. Are you saying that the native browser APIs evolving to make Flash obsolete is a bad thing? If I'm reading you correctly you're saying that websites being free to use their own proprietary plugins is somehow better than HTML5/Javascript?
You can't claim the JavaScript technologies of now and apply them to Tcl of the 90's. Tcl is an ace language and well suited for the web.
What shows is that the old stigma of programming held everything back and most of that was Oracle. Still the same today with Google, Facebook and so.
Java Applets were phenomenal and way ahead of their time. It just got caught up in the swamp and broadband wasn't available to enable the technology to flourish. I never loathed them, I loved them. 3D graphics in the browser; we still struggle with that today.
Everything back then was a pain but is anything easier now? Tried using Windows 11? Even Linux has lost its charm.
WebGL isn't mature enough and Apple is cutting OpenGL from their OS. Where is the HTML5 equivalent of Flash? I have yet to see it other than Ruffle.
If the plugins were adopted, and browsers were adaptable to the plugins that would decuffed the browser rather than the current trend of the internet where the schematics are now vastly dominated and ruled by Google & co cuffing the browser and any other future browser for that matter in to nose dive spiral.
Firefox is the only major alternative and is only floundering because of Google.
If plugins were the browser from the get-go then any shift of plugins could rock the boat.
> Are you saying that the native browser APIs evolving to make Flash obsolete is a bad thing?
Pretty much yes. HTML 5 was Googles push for dominance, JavaScript was too. Not sure if intentionally but they sure at it now. "Don't be evil" I seem to recall.
Without it's merits, it would too have it's own problems but I would wager that the internet ecosystem would be broader and more united than what it is now.
Extensions don't count as it's difficult to use another programming language in the browser unless it's tied to WASM or built in. And even then you're further restricted where features are torn out.
XSLT however has an absurdly steep learning curve, on top of it (like XML) being utterly verbose. There is a reason neither technology ever caught on outside of big enterprise or government projects.
If it weren't for the huge efforts put into it by china to make solar and batteries so cheap and capable we wouldn't be nearly as far along in the solar transition as we are. Solar is growing in spite of US policy, not because of it.
I was poking people a little with that statement. Can't help myself.
But really, there is growth under the policies, so saying "despite" doesn't work. You could try to argue that the policy makers tried to kill solar but achieved the opposite result. But at the end of the day the current policy environment led to a positive result. Correlation isn't causation but if I was writing a policy and I wanted to guarantee the opposite outcome I'll bet ya I could.
I happen to know some Americans who have worked really hard to advance renewable energies and have made an impact. To just view the US with one lens is not right is maybe the point I am making, without poking.
China makes cheap solar panels because there's a market for them. Panels aren't the only component in a solar system either. A lot of the technology comes from the US and American companies as well. Germany apparently gets some credit as does Australia. The Chinese did what they do best- low cost manufacturing. We got there together.
First the UK, then leadership of Europe via behind-closed-doors politics, then a gentle colonization of both the east and the west using our amazing cheese, bread that is baked rather than synthesized from fossil fuels, and 30 days of paid vacations per year. The path forward is clear.
> I hated the question of teachers asking: What does the author wanted to tell us with this story." Because -> The author never wrote that down. And deriving their intentions from a fictional text felt just like making shit up.
Then why does anyone write anything? Why did Orwell write 1984 instead of just making a 2 page bulleted list about how authoritarian regimes are bad?
Sure, an author can write something that is interpreted totally differently from what they meant, but that doesn't detract from the fact that they did have some intention behind what they wrote and it's worth exploring that.
reply