[r_lee]

well that's any framework with vdom, the GC of web frameworks, so I'd imagine it's also a problem with vue etc..

I don't understand though why performance (I.e. using it properly) is not a consideration with these companies that are valued above $100 billion

like, do these poor pitiful big tech companies only have the resources to do so when they hit the 2 trillion mark or something?

[yurishimo]

Vue uses signals for reactivity now and has for years. Alien signals was discovered by a Vue contributor. Vue 3.6 (now in alpha/beta?) will ship a version that is essentially a Vue flavored Svelte with extreme fine grained reactivity based on a custom compiler step.

One of the reasons Vue has such a loyal community is because the framework continues to improve performance without forcing you to adopt new syntax every 18 months because the framework authors got bored.

[array_key_first]

It's not a problem with vue or svelte because they are, ironically, reactive. React greedily rerenders.

It's also not a problem with the react compiler.

[mike_hearn]

The React paradigm is just error prone. It's not necessarily about how much you spend. Well paid engineers can still make mistakes that cause unnecesssary re-renders.

If you look at older desktop GUI frameworks designed in a performance-oriented era, none of them use the React paradigm, they use property binding. A good example of getting this right is JavaFX which lets you build up functional pipelines that map data to UI but in a way that ensures only what's genuinely changed gets recomputed. Dependencies between properties are tracked explicitly. It's very hard to put the UI into a loop.

[tracker1]

Property binding and proxies really didn't work well in JS at all until relatively recently, and even then there is actually a much worse history of state management bugs in apps that do utilize those patterns. I've yet to actively use any Angular 1.x app or even most modern Angular apps that don't have bugs as a result of improper state changes.

While more difficult, I think the unidirectional workflows of Redux/Flux patterns when well-managed tend to function much better in that regard, but then you do suffer from potential for redraws... this isn't the core of the DOM overhead though... that usually comes down to a lot of deeply nested node structures combined with complex CSS and more than modest use of oversized images.

[vscode-rest]

Nobody gets promoted for improving web app performance.

[gspetr]

Yes, they do. OGs remember that Facebook circa 2012 had navigation take like 5-10 seconds.

Ben Horowitz recalled asking Zuck what his engineer onboarding process was when the latter complained to him about how it took them very long to make changes to code. He basically didn't have any.

[achenet]

From: https://hpbn.co/primer-on-latency-and-bandwidth/#speed-is-a-...

> Faster sites lead to better user engagement.

> Faster sites lead to better user retention.

> Faster sites lead to higher conversions.

If it's true that nobody is getting promoted for improving web app performance, that seems like an opportunity. Build an org that rewards web app performance gains, and (in theory) enjoy more users and more money.

[r_lee]

yep. I think this is the root problem, not the frameworks themselves

[cess11]

If it's slow people also stick around for longer if they have something they must accomplish before leaving.

[threetonesun]

They have no real competitors, so anything that makes the user even stickier and more likely to spend money (LinkedIn Premium or whatever LinkedIn sells to businesses) takes priority over any improvements.

[vaylian]

> well that's any framework with vdom

Is it time for vanilla.js to shine again with Element.setHTML()?

https://developer.mozilla.org/en-US/docs/Web/API/Element/set...

It's a bit unfortunate that several calls to .setHTML() can't be batched so that several .setHTML() calls get executed together to minimize page redraws.

[tracker1]

Well, their lowest tier devs, they have started firing and churn a lot... combined with mass layoffs... and on the higher end, they're more interested in devs that memorized all the leet code challenges over experienced devs/engineers that have a history of delivering solid, well performing applications.

Narcissism rises to the top, excess "enterprise" bloat seeps in at every level combined with too many sub-projects that are disconnected in ways that are hard to "own" as a whole combined with perverse incentives to add features over improving the user experience.