I haven't finished reading the article yet. I am a fan of Svelte, though, and have switched to using it by default for new projects - coming from a React background.
And you know what? No matter the browser, no matter the OS it all worked and rendered the same.
Probably Adobe Flash was like that also.
First app we rewrote to AngularJS. You know what happened to it. So then we rewrote it to Vue.
The same effing app just to keep the stack “modern”.
I don’t know what is wrong with all these people.
God I wish something like Silverlight returned in a way that is mobile battery friendly.
Not exactly the same, but there is Blazor, it is using html instead of xaml. Also there are third party solutions (I have no experience with) like Uno and Avalonia, both are xaml-based.
> mobile battery friendly
Do you have some specific framework in mind that is not battery friendly? Probably anything is built on js/wasm isn't battery friendly.
See “Thoughts on Flash” by Steve Jobs
https://web.archive.org/web/20170615060422/https://www.apple...
—
As for Blazor, we ain’t fools to rewrite the RIA app the fourth time.
I just wish these “innovation” MF stopped reinventing the wheel.
The code from 2008 was perfectly fine and should have worked in 2025 if all these guys stopped making web frameworks like hot cakes. Some of us with an actual job have products that last more than a couple years (15+ in my case)
WPF was great for desktop, albeit Windows only.
So that was wrecked after .net framework became .net core (and thus needed crossplatform).
Then some shitheads at Microsoft got the “release new UI framework to get a promotion” annual bug: winui, maui, etc.
All that instead of making WPF crossplatform.
That’s why C# succumbed to server API only (and games of course, but those blokes suffer as most great C# features are not supported in Unity).
That was the grandeur of Windows Vista: not the OS but completely new dev stack (wpf, linq, wcf, etc.) that was feature rich for a few decades to come. And they fucked most of it up instead of building further on the same foundation.
And after you keep abandoning the technologies devs will say FU and go to something more stable to build a business.
Even now, .net is keep getting rewritten (meaning existing features being abandoned) because board wants those sweet-sweet money from the cloud functions and what have you instead of you being self-hosted and not vendor-locked
Avalonia (https://avaloniaui.net/) and Uno (https://platform.uno/) are cross platform UI frameworks for .NET.
Both work in the browser with WebAssembly. Avalonia renders to canvas. Uno can render to canvas or the DOM. Here are a couple of Avalonia demos:
The core library of React seems well managed, but the accompanying ecosystem of 3rd-party tools for styling, routing, state management, etc seem to be constantly changing.
Meanwhile in Vue land, the critical packages have remained fairly stable and are all maintained by the core team. You get support for styling and transitions out of the box; for most other things (routing, state management, etc) there is one well-maintained library (as opposed to a bunch of options of varying quality that you need to sift through).
I've been using Vue.js for 10 years at this point, and have been using the composition API for the last 5. The older options API is still viable as well.
Typescript is not a language that is good for making basic comprehensive abstractions in.
JSX is not a language that is good for making basic comprehensive abstractions in.
It's still got some baggage left over from Javascript, to be sure. But the typing is genuinely very good, and more than sufficient for "basic comprehensive abstractions".
JSX is just Javascript with syntactic sugar for HTML. It's not really intended as a general-purpose language. TSX is a fine language, but I wouldn't use it for "basic comprehensive abstractions".
Like if you want to make a basic dashboard, things like alpine/htmx should make more sense to you and you should definitely go for it
But I have found that if you are writing ever so slightly complex code, you might be then forced to write js code (not sure about blazor but even that suffers a little in benchmarks but the fact that somebody can fully stop to never touch js sounds a bit intriguing even though it maybe slow but sure)
So when you are forced to use js to write complex software, frameworks especially frameworks like svelte / maybe solid could definitely help you out
Honestly, sveltekit is just html css js and some opinionated stuff and I kinda feel like that this might be the sane thing but maybe that's because I was there when svelte 3 was launched and I was 15 so svelte was something sooo interesting to me (still is! but golang is also love, man I know that svelte and go could be integrated and maybe I would), I never really went around learning pure js dom manipulation / ts / jsx if I am being honest so I am not that much of an expert
For writing a web server library, like oak or flask or etc etc:
First, resources own the methods, methods don't own the resources, so the path comes first, easy enough, its just a string with potentially placeholders whose values need to be shunted down the line
Next is the method, for some reason a lot of libraries like to hardcode these? Immediately jumping away from comprehensive, unless you have a language that makes identifier-like things possible, e.g. symbols in ruby, or `__getattr__` in python, or proxies in javascript, of the 3, proxies are probably the most cumbersome in implementation.
then the request handling, that is fine for all languages
Templating is more of a bother: Either you use JSX, which in most cases is not XML, but instead DOM, subtle but a pain, additionally requires a compilation step before you can run the code, and also requires a DOM or DOM-lite library. Or you do chained calls with an ending call, e.g. https://sonnet.js.org/, or you do something like lit-html which is quite practical. You can't do something like title("hi") vs title({attr:123}, "hi"), as everything is an object and {} are objects, so you need to have fixed function signatures unless you want to have a lot of bother in implementing things. This is all less of a problem in other languages (e.g. Python, Ruby, Raku)
In short, Javascript does not flex when you push on it, that is great for a lot of tasks, but not so much for building frameworks where instead of having systematic ways of extending the language, either tricks are used which break other things down the line ( https://news.ycombinator.com/item?id=45472119 ), or you have opinionated narrow frameworks, which results in more churn as instead of frameworks, its more, frame-specific-use-cases.
For the part where you're describing what's possible or not in TypeScript/JS, though, you're incorrect:
You can't do something like title("hi") vs title({attr:123}, "hi")
Yes, you can. In JS it's trivial; in TypeScript, you can even do it while preserving type safety. Here's the function in TypeScript:
// First define which signatures are allowed
function title(content: string): string;
function title(attrs: Record<string, any>, content: string): string;
// Then, implement the function, handling the two possible cases:
function(contentOrAttrs: string | Record<string, any>, maybeContent?: string) {
const content = typeof contentOrAttrs === "string" ? contentOrAttrs : maybeContent!;
const attrs = typeof contentOrAttrs === "string" ? {} : contentOrAttrs;
// now use content and attrs as you please
}
I should not have used "can't" at that point, correct
To be more clear, you "can't" have a difference between an arbitrary object and a record, unless you know the type of the object and a way to disambiguate that from a record.
Of course, you "can" have a difference, a record "is" `typeof record === 'object' && Object.getPrototypeOf(record) === Object.getPrototypeOf({})` (At least as long as no one uses plain objects as non-recordy things), but, this isn't something I've ever had to care about in any other language. In some you have multiple dispatch built into the language, in some you can just pass named arguments arbitrarily. Javascript and Typescript are very inflexible in this aspect.
Like, here's the thing, sure it can create the code but LLM's stop so early in things like svelte atleast that's my opinion. I never really learnt react and didn't ever use react with any LLM
fun fact: Chatgpt 3 could write perfectly well sveltekit, that's how I "vibecoded" in the start
Like, sure I would copy paste but deep down I just felt like most of this is just plain html css js and nothing too much to worry about and that soothed me that sure this may be vibe coded but I was a real noob of svelte but the vibe coding was a bit of a successful :p
I have stopped it / atleast reminded myself 100 times to stop it because I want to feel even more confident with svelte and really learn it even more to the point that I can be 100% confident to write complex software in svelte myself and well only using AI for the boilerplate part or the tedious parts I am not sure, there is a lure to ask LLM's more and more and to depend on them more or maybe its just me I am not sure.
I live and work in London. I’ve basically not seen this culture of constant churn and rewrites that people on HN bemoan since about 2018.
Also, I'm not a huge fan of synthetic benchmarks like in the article such as "render a static list of 25000 elements". This never happens in the real world, you would use some implementation of a virtual list instead.