[byearthithatius]

Things change so fast in web dev. Is it so hard to find a pattern that works and stick to it? I think the constant rewrites are honestly _worse_ for dev experience and security. Nobody knows whats standard and docs become outdated so quick a lot of frameworks just have outdated docs or multiple versions that contradict eachother.

[piskov]

My nation-wide C# Silverlight app lasted almost 12 years. And it had grid, animations, what have you in 2010 better than most html5 in 2018. Not to mention tooling.

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.

[stanac]

> 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.

[piskov]

Battery and mobile performance is what killed flash and silverlight as an aftermath in the first place.

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)

[cap11235]

I feel like flash could have been adapted to low battery quite easily (it isn't like JS has some super smart concurrency; it is literally the basic common denominator unless you are using a Z80). Rather, Macromedia was in the toilet, then purchased, and Youtube (and Vimeo and others) started to be useful, making a more appealing platform (and probably the first other than newgrounds) for animation. Having someone else host media was a big +++

[jslaby]

Silverlight was awesome, too bad Microsoft abandoned it. You think they could've done something with it like decoupling from the browser, instead of making all these different UI frameworks that are fizzling out.

[piskov]

The whole reason was working in the browser.

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

[breve]

> All that instead of making WPF crossplatform.

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:

https://solitaire.xaml.live/

https://bandysc.github.io/AvaloniaVisualBasic6/

[katabasis]

I think Vue.js has done a great job of avoiding a lot of the churn while staying competitive with other projects in terms of features and performance.

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.

[its-summertime]

Javascript is not a language that is good for making basic comprehensive abstractions in.

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.

[jfengel]

I concur about Javascript, but I don't think it's true for Typescript. Typescript is a remarkably powerful typing language.

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".

[Imustaskforhelp]

Depends...

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

[nawgz]

This is quite a large set of things to hand wave away with no additional justification. Makes it sound more like personal bias than meaningful insight

[its-summertime]

You are right, my reasoning is as follows (though still 100% personal bias).

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.

[reissbaker]

Not sure I follow the first part of what you're saying.

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
    }

This will be typechecked by the compiler so that if you call title("hi"), it'll know there are no more arguments, and if you call title({ attr: 123 }, "hi"), it'll validate that the first argument is a Record<string, any> and the second argument is a string.

[its-summertime]

that part was clarified later, "so you need to have fixed function signatures unless you want to have a lot of bother in implementing things"

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.

[fancyswimtime]

it feels like a fad to hate on js and js frameworks; esp from people who parrot what others are saying without any actual insight

[masfuerte]

A fad? People have been pointing out flaws in js for about thirty years. That's long enough to have become a tradition.

[Imustaskforhelp]

To be really honest. AI / LLM's can write svelte 5 runes code but Its a really really mixed bag and most of them probably write svelte 4 code

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.

[the_other]

I picked React over Angular in 2015 and havn’t looked back. I’ve never done, nor been asked to do a rewrite. I once interviewed for a role that would have involved a rewrite from Angular to React. My current employer has a design system and UI library to implemenet it. Some time before I joined, they decided to move from Stencil-driven support for React, Angular and one other framework, to pure React support. From 50-60 applications I made late 2024-2025 one used Lit one Svelt, maybe 10-15 Angular and the rest React. In previous rounds of job or contract hunting, I don’t recall seeing demand for anything other than the big two.

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.

[thousand_nights]

React has been pretty stable for many years now and is almost ubiquitous.

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.

[byearthithatius]

Main React has been pretty stable for a few years but the ecosystem to serve React bundles has not been.

[christophilus]

Yes, but it’s gone from a few, slow, clunky build tools. To things like Bun or Vite which are excellent. So, bring on the change, if that’s the kind of change we’re talking about.

[sixtyj]

Yes, don’t tell me this. I have to rewrite PHP based website because a framework doesn’t work with new PHP anymore. Back compatibility sucks in many software.

[jslaby]

It must be a pretty old framework if it doesn't work with new PHP.

[sixtyj]

12 years old untouched framework (Nette). It worked with PHP 5.4 but as hosting provider switched to PHP 8, I’d rather pay extra fee for 5.4 and slowly rebuild site to 8, because there are so many things you probably need to change… This is the reason why Fortran or COBOL people are so valued for banks…because you want continuity not breakups.