[carshodev]

This title is very misleading, it should be "Why React is not compatible with long-term performance goals"

And I do agree generally. React uses an outdated rendering method that has now been surpassed by many better frameworks. Svelte/Sveltekit, Vue, and Qwik are the best examples.

People relying on bloated React packages is obviously not great but that is nothing to do with javascript itself.

The JS engines are all relatively fast now. And the document model of the current web provides major accessibility to both humans and search tools like SEO and GEO. JS is not my favorite language. I would rather the web was based on a statically typed language that had better error handling practices like Go. But this will most likely not happen any time soon as it would require every level of the ecosystem to adapt. Browsers, Frameworks, Developers etc.

Google would have to take the lead and implement this in chrome then enough developers would have to build sites using it and force safari and firefox to comply. It just isn't feasible.

If you want faster webapps just switch to sveltekit or vue or qwik. But often the ones choosing the framework for the project have not written much code in years, they know react is as safe option and used by everyone else so they follow along, if it gets slow its a "bug" causing it as they built apps that were "good enough" before using it.

[socalgal2]

> Google would have to take the lead and implement this in chrome then enough developers would have to build sites using it and force safari and firefox to comply. It just isn't feasible.

They already tried. It was called Dart and for a while there was an experimental flag to enable it directly in Chrome. It was cancelled and Dart was relegated to transpiling to JS/WASM.

[pjmlp]

There was a complete fork to support it, Dartium.

https://chromium.googlesource.com/dart/dartium/src/

Dart is only around because it was rescued by AdWords team, which had just migrated from GWT into AngularDart, and wasn't happy to do yet another transition.

Most of the key names from Smalltalk/Self background that were part of Dart 1.0 left the team at this point.

It managed to stay around long enough to get the attention of the Flutter team, originally their prototype was done in JavaScript, which is also the reason why Dart 2.0 was a complete reboot of its type system, from dynamically typed with optional typing, to strongly typed language with type inference.

And it isn't as if Flutter is a great success, Fuchsia never made it big, the Android team counter attacked with Kotlin's adoption, JetPack Compose, and Kotlin Multiplatform.

[wiseowise]

> JetPack Compose, and Kotlin Multiplatform

More like JetBrains dragged Google kicking and screaming into multiplatform, given how piece of a shit setup is.

[pjmlp]

Google is the only OS vendor that outsources all their development setup, I am surprised that by now they haven't yet acquired JetBrains.

[quietbritishjim]

> And it isn't as if Flutter is a great success, Fuchsia never made it big, the Android team counter attacked with Kotlin's adoption, JetPack Compose, and Kotlin Multiplatform.

Sorry but I can't find my way through the double negatives in this (does "isn't as if" apply just to Flutter or the whole sentence?), and I'm not so familiar with that ecosystem that I know myself. Are you saying that Flutter isn't a great success and has instead been superseded by Kotlin? Or that it was a success and that's why Android team counter attacked?

[quietbritishjim]

I think I figured out that the parent meant:

> Flutter is not a great success; Fuchsia never made it big, and the Android team counter attacked with Kotlin's adoption, JetPack Compose, and Kotlin Multiplatform.

(Despite being much derided when output by LLMs, a semicolon would've really helped me here!)

Partly my confusion came from having heard of both Flutter and Fuschia but having no idea they were connected. In fact I only knew of Flutter working on Android (and other non-Google OSs).

Anyway, it's true that Flutter is not as widely used as an Android replacement would be (if Fuchsia had turned out to be that) but for a UI framework it's reasonably well used and pretty great at cross mobile/desktop development.

[quietbritishjim]

Agreed that Dart was an effort to do exactly this.

To be a bit pedantic... "relegated to transpiling to JS" makes it sound like that was something they had to do later, but in fact that was up front part of the transition plan. The idea was, write your code in Dart and it would work natively in browsers that (eventually) support it but would still work in everything else via JS transpilation. You're right that it was relegated to only working that way once it was rejected.

The problem was (if the Wikipedia article is to be believed) that developers took offense to one company unilaterally deciding on the future scripting language of the web. A little ironic given that's how JS evolved in the first place, but fair enough. Later, WASM was created instead, with the idea that no particular language had to be chosen (and frozen) as the JS replacement. Dart compilation to WASM followed.

[hinkley]

The reason I'm a backend dev at the moment is that I looked at the React model and decided I didn't want anything to do with this insanity.

I've been appalled by how long and how broadly the mass hysteria lasted.

[carshodev]

And what's crazy is with ai the percentage of apps developed using react in comparison to all other frameworks has INCREASED over the last 3 years.

It is truly mass hysteria, I would say that 95% of developers, project managers, and CTOs do not truly understand how these systems work under the hood, or at the very least are too scared and comfortable to try other systems. They just repeat the same things they hear and tell each other "react has a big ecosystem" "react is industry standard" "everyone uses react" "react was developed by facebook" "we will use react" "Developers only know react, how could we hire for a different framework?"

In my mind its clear that the alternatives are massively better. When i visit certain websites I often get a random tingle that it uses svelte because its way faster and has better loading and navigation than other sites and when i check the devtools I'm almost always correct.

I also get the same feeling sometimes when I hit a laggy slow webapp and I open the devtools and clearly see its a nextjs app.

A dev team could be trained on svelte or vue in literally 3 days, and so long as they actually understand how HTML, JS, and css work under the hood they would increase their speed massively. People just don't want to take the risk.

[Cthulhu_]

To add, the other dominant force is Angular, very popular in enterprise settings. I don't understand why per se, it's very... verbose, every component needing a number of files. It (and also React) gets worse if you add a state system like RxJS.

My theory is that it's popular with back-end / OOP / Java / C# developers, because they're used to that kind of boilerplate and the boilerplate / number of files / separation of concerns gives them comfort and makes it "feel" good.

But also, like React, it's easier to find developers for it, and on a higher level this is more important than runtime performance etc. And continuity beats performance.

(I can't speak of its runtime performance or bundle size though)

[Tade0]

Angular has been my main framework for the past 9 years, so I guess I can shed some light on this:

AngularJS came before React and being a Google product, gained enough inertia in large organizations that given the choice, the decision makers preferred to migrate to Angular 2+, which at the very least had a passing similarity to the previous iteration, instead of jumping to a wholly new framework like React.

The very last AngularJS to Angular 2+ migration I participated in happened in 2020, when it was already known that the former would reach end of life by the end of 2021. That is how reluctant corporations are to rewriting the entire frontend codebase.

Mind you, I've used other frameworks like Vue in an Angular-oriented company, but the project was: greenfield, small and underfunded, so we had some more liberty in choosing what to use.

[elfly]

This whole thing is the problem. AngularJS was released in 2010. If in 2010 I'd know that the damn thing would die in 2021, and that I would have to rewrite it all by that date, I would not have used the damn thing in the first place.

I also at some point inherited an app written in Vue 2. By the time I got it, Vue 3 was already out and a couple of years later, Vue 4, completely different to Vue 2, was out. Rewriting was not an option, so I had to create a docker image that can compile the damn thing offline, cause if some part of the supply chain breaks, well, that's it.

Ten or eleven years is not a super long time in enterprise software. Having to keep upgrading and changing libraries just cause the devs of the libraries get bored should not be a thing.

[mikrotikker]

This is why I struggled and struggled to omit JS at all costs on a greenfield project - many apps from even 5 years ago by now fired teams fail to build with cryptic npm messages. And if you get past that you have to deal with webpack or some such junk. We settled with go fyne which compiles to wasm to handle both local and remotely accessible use cases. Trade off is not as much freedom and a fixed feature set but I know it's gonna work after 5 godamn years.

[jamesfinlayson]

> If in 2010 I'd know that the damn thing would die in 2021

Was it obvious back then? I had to work on an AngularJS site for a while and it was the most confusing thing ever. Having come from React I couldn't understand the complexity but maybe it was still better than callback hell in jQuery?

[paulryanrogers]

React--for all its warts--hasn't had a major backward compatibility break. Microsoft Windows selling point for a long time was backward compatibility.

[rk06]

what?? vue 4 is not out yet. it is not even planned

[frogulis]

My current company uses Angular, and uses it reasonably well. Prior to working there, I'd never used Angular, so I feel well-equipped to comment on this.

We've also recently absorbed a vanilla(-ish) JS codebase largely developed by one dev which provides a point of comparison.

Angular has plenty of boilerplate and idiosyncrasy, but it being opinionated and "pattern-y" has advantages when you want devs who infrequently touch it to be able to jump in and make changes with some level of consistency.

Additionally -- and this is anecdotal, but I suspect it's a common part of working with a plain JS codebase -- tracking the flow of data through the Angular application is usually soooo much more straightforward, even when it involves navigating through many layers and files. The Angular codebase only has N types of things, and they tend to relate to each other in the same ways, and they're often quite explicit (such as explicitly defined component element names in HTML templates). In contrast the JS app has whatever it has built up with very few constraints keeping it consistent. Obviously that could be improved with discipline and structure, but reducing that requirement is one of the things a framework gets you.

I can't comment too much on React as my one experience working in a proper React codebase was in a team who were largely as clueless as me :)

[nicoburns]

My experience of working with Angular (admittedly several years ago when Angular versions 2-4 were current) was that it was pretty close to the React model (which was a huge improvement over the old angular.js), but also slightly worse than it in pretty much every area.

Most of the problems were the framework being too opinionated and not getting out of your way, whereas it is generally easy to "break out" of the abstraction when needed with React.

[burningChrome]

>> To add, the other dominant force is Angular, very popular in enterprise settings.

I work at a fortune 200 company. Worked in development for 5 years before moving into accessibility. I still have good friends who are still working on dev teams here. When I left, people were saying how shitty Angular was and how React was the way of the future.

5 years later and they're rebuilding several enterprise apps that were built with React and going back to Angular. I guess one of the directors, in an all hands team meeting basically said, "The ReactJS experiment is officially OVER."

Its anecdotal evidence, but it seems large projects and teams are going back to Angular for familiarity, ease of debugging and maintainability - not necessarily speed and performance. Which when I was still in dev circles, that was all that mattered.

It kind of feels like another changing of the guard in the industry right now.

[hinkley]

> ease of debugging

I had thought to start trying to contribute to the Grafana project and it turns out the whole frontend is React and some completely impenetrable flavor of it to boot. How do people work like this? It’s insane.

[pjmlp]

Coping, unfortunately. I use React occasionally.

[azangru]

> It (and also React) gets worse if you add a state system like RxJS.

I don't understand this sentiment.

Client-side applications often have a need for global state. It could be as simple as whether the user is logged in, or as complex as, say, the shapes that you have drawn in excalidraw canvas, and the drawing tool that you have selected. State changes over time, and so it seemed plausible to model it as a stream of states over time (hence rxjs). There are more robust ways to deal with the state, which is why angular has now moved to signals; but what is so bad about the state?

[WorldMaker]

RxJS is far more robust than signals (things like backpressure operators, scheduling operators, and more). Angular's move to signals is just another sign of what Angular was doing wrong with RxJS all along: Angular could have used the robustness of RxJS to make a better framework but at many decisions along the way chose to not trust RxJS to do its jobs, skipped operators for the sake of leaking imperative state back out into the world and/or treating RxJS like heavyweight Promises (which indeed they are heavy and unweildy in that context). Signals enshrine the imperative leaks as the preferred and final path forward, further crippling the robustness RxJS could have offered and yet also doesn't entirely eliminate RxJS as a dependency.

Angular was born broken in how it made use of RxJS. A lot of developers have a bad impression of RxJS simply because Angular led them to so many RxJS worst practices, bad performance, and taught them that RxJS was just "heavy Promises".

[azangru]

RxJS has an intrinsic diamond problem (multiple events fired when several sources update simultaneously), which led to occasional glitches. Signals are guaranteed not to have that problem. This is a strong argument in their favor.

But yeah; I am amazed and amused by how, during the past couple of years, the interest to rxjs has plummeted. No more conference talks on this topic. And even though Observables have been released natively, there is no activity in the rxjs repo to update the library accordingly.

[hinkley]

RXJS is also 18 MB which is irritating in a backend but completely bonkers in a frontend.

[pjmlp]

That is one of the reasons, the other is everything is in the box, hence why Next.js is also the React approach the same enterprises will reach for.

Also why enterprises love Java with Java/Jakarta EE, .NET with VS Studio full install, Rails, Django,...

[jonathanlydall]

Like all languages, C#, Java, etc have cargo-cultist developers who use them badly, and in the case OOP languages, doing things like overdoing the separation of concerns.

However, speaking as someone who actually uses C# day in and day out and understands the trade-offs of different levels of (or even no) separation of concerns, it's not done for us to "feel" good.

On very large projects running for a very long time with many developers coming and going with varying levels of competency, an appropriate amount of separation of concerns and decent "plumbing" can be the difference between a code base enduring decades or becoming essentially unmaintainable due to unchecked entropy and complexity.

[jamesfinlayson]

Yep, agreed. I worked on two PHP codebases at a company many years ago - the "old" and the "new". The old was just frameworkless PHP with three different ways of doing controllers, partial templates with no closing tags so that they could be inserted anywhere without breaking the page, inline SQL in the templates etc. The new was hugely complicated with long inheritance chains and multiple classes with the same name but in different directories... but it was structured and you couldn't easily do anything wild.

[likium]

There's 3x more React libraries and code out there to reference. AI agents do _a lot_ better with React than, say, SolidJS. So productivity > performance is a tradeoff that many companies seem to happily take.

[Tade0]

There's so many React libraries because the framew... I mean library is extremely barebones.

That is, in my view, the main issue with React (rendering model notwithstanding): every React application is composed of tens of tiny dependencies and since there are several competing libraries for even basic things like routing, no two projects are the same.

[yaku_brang_ja]

Umm, are we really taking "being AI friendly" as an account to choose framework now? I’ve seen this mentioned often enough lately that it’s making me uncomfortable. I fear if this will becomes epidemic. This will literally hault progress in improving and adopting better frameworks.

[likium]

As a solo dev who picked SolidJS, yes, it is a big factor. Things like tldraw, node editors, wysiwyg editors, etc. Having to reimplement them is a huge time sink.

[aleksiy123]

I also second this.

Some point last year I dropped solidjs in favour of React.

Purely because of libraries and ai assisted dev velocity for my own projects.

Actually started working on the features instead of wrestling with framework.

Sometimes taking the path of least resistance just makes sense.

[endemic]

And the end users pay the price!

[benterix]

> AI agents do _a lot_ better with React

Do you really think this is a solid argument in this particular discussion (about it being slow and introducing a mass of unnecessary complexity)?

[0xblinq]

Some people need ways to cope with the drawbacks of what they use, even if irrelevant to the conversation.

[pjmlp]

It is very hard to avoid when you have Vercel doing partnerships with SaaS cloud providers that end up supporting only React and Next.js on their SDKs.

Even if other programming stacks are supported, they tend to be 2nd or 3rd class versus anything React.

Look into the ecosystem of headless products that have jumped into the whole MACH architecture hype cycle.

Then you have to justify to upper management, and partner support when problems arise why you are not using their SDK.

[mvdtnz]

Why on earth would your cloud provider dictate your front end stack? My mind is in tatters trying to understand this thought process.

[pjmlp]

Because they have these things called SDKs to extend their product, for specific programing languages.

Here is an example, https://www.sanity.io/studio

Want to extend the SaaS product for your backoffice users?

Learn React or make Studio from scratch.

Frontend stacks are also backend stacks in cloud products.

[mvdtnz]

This looks like a SaaS vendor not a cloud provider?

[muvlon]

Because with Next.js, Vercel was able to turn the frontend stack into also a really shitty backend stack. And it's particularly shitty at being deployed, so they're in the business of doing that for you.

[koakuma-chan]

People have no idea who they are hiring, so they hire people who have no idea what they are doing.

[mentalgear]

> they actually understand how HTML, JS, and css work under the hood they would increase their speed massively.

Indeed, Svelte is built directly on web standards so knowing it strengthens your command of core JS and the web-platform itself - not just a silo-specific layer like React.

Also Svelte acts as a compiler: it outputs just clean, highly optimized JavaScript with no virtual DOM, that uses native web-APIs and results in minimal runtime overhead, smaller bundle sizes and overall excellent performance and DX.

[etler]

React is slower than the alternatives, but next.js is really really slow.

[DanHulton]

I managed to avoid learning React long enough to become a manager.

I'm not saying I won't ever end up in engineering and won't ever have to learn it, but at least right now, it feels kinda like I got away with something.

[austin-cheney]

I remained unemployed after I was laid off until a change of career happened. I refused to back to Angular/React/Vue. I was not going to shovel shit anymore for people who were clearly incompetent and really entitled about it.

[icdtea]

Where did you career change take you instead?

[austin-cheney]

Enterprise API management

[widdershins]

It lasted because React genuinely did introduce a useful new paradigm - of UI being a (mostly) pure function of state. This has actual benefits. Unfortunately the way this was implemented was (very) suboptimal, and now they're locked in.

I agree that this stubborn clutching to that original idea, despite better options that acheive the same paradigm having arisen in the meantime.

[pjmlp]

Unfortunely it is hard to avoid when doing backed development with SaaS, iPaaS products, where JavaScript is in many cases the only extension language for backend widgets.

I am kind of alright with Next.js, as it is quite similar to using SSR with more tradicionla backend stacks.

Also at least node's C++ AddOns give me an excuse to occasionally throw C++ into the mix.

[netdevphoenix]

> Google would have to take the lead and implement this in chrome then enough developers would have to build sites using it and force safari and firefox to comply. It just isn't feasible.

This is not something you really want to happen for the health of the web tech ecosystem. I am surprised to see actual developers nonchalantly suggesting this. A type system for the web is not worth an IE 2.0

[carshodev]

I would want this to happen personally as there is no other way that the tech can advance at this current point.

It's clear that there is no global browser federation that works together to make standards. Every browser does things themselves and implements things differently. So the only way that it is feasible is if the browser that is used by 75%+ of sessions is the one that implements it.

Would I like it to be open source? of course. would I like it to be a separate project that was not directly controlled by google? yes. But this does not change the fact that it would ONLY be possible if they accept it into chrome.

The alternative is to forever use Javascript and never advance or change things.

Tech moves quickly and it could be possible that a new browser could take market share in 10 years but it is inconceivable now and would take some groundbreaking shift.

It feels like current browsers can never change their language and it will only be once a new platform is standard, like Vision/Glasses or a voice AI assistant.

It could have been possible if Huawei was allowed to stay in the US market as they are making their own kernal, operating systems and browsers, but they are now excluded. So only google and apple are present to control how things operate.

Over time things must adapt if they become better, there is always pushback when change occurs, but change is necessary for growth.

[autogn0me]

Almost had this with dart

[cyberax]

> React uses an outdated rendering method that has now been surpassed by many better frameworks. Svelte/Sveltekit, Vue, and Qwik are the best examples.

I strongly disagree with this. Svelte/Solid/Vue all become a twisted mess eventually. And by "eventually" I mean "very very soon".

The idea to use proxies and automatic dependency discovery looks good from the outside, but it easily leads to models that have random hidden interdependencies.

React's rendering model is simplistic ("just render everything and then diff the nodes"), but it's comprehensible and magic-less. Everything is explicit, with only contexts/providers providing any "spooky action at a distance".

And the recent React versions with Suspense neatly add the missing parts for async query/effects integration.

> If you want faster webapps just switch to sveltekit or vue or qwik.

If you want even worse webapps then switch to Vue and forgo being able to ever maintain them.

[mightyham]

I've worked on large React and Solid codebases and don't agree at all. You can make a mess of either one if you don't follow good practices. Also dynamic dependency management is not just a nice to have, it's actually critical to why Solid's reactive system is more performant. Take a simple example of a useMemo/createMemo which contains conditional logic based on a reactive variable, in one branch a calculation is done that references a lot of reactive state while the other branch doesn't. In React, the callback will constantly be re-executed when the state changes even if it is not being actively used in the calculation, while this is not the case in Solid because dependencies are tracked at runtime.

[cyberax]

> Take a simple example of a useMemo/createMemo which contains conditional logic based on a reactive variable, in one branch a calculation is done that references a lot of reactive state while the other branch doesn't.

Then you create two useMemos, and recalculate based on the branch. Or you can cache the calculation in a useRef variable and just not re-do it inside the memo callback. There's also React Compiler that attempts to do the static analysis for automatic memoification.

> it's actually critical to why Solid's reactive system is more performant.

I've yet to see a large Solid/Vue project that is more performant than React.

> In React, the callback will constantly be re-executed when the state changes even if it is not being actively used in the calculation, while this is not the case in Solid because dependencies are tracked at runtime.

And in Solid the dependency tracker can't track _all_ the dependencies, so you end up using "ref.value" all the time. Often leading to the code that that has a parallel type system just for reactivity. While in React, you just use regular objects.

[MrBuddyCasino]

Vue's model is more constrained: sharing variables to child components, signals to notify parent components. I found this a lot simpler to reason about than React.

[LtWorf]

Saying that go has good error handling is… bold.

Letting google implement a new language for the web would probably result in something even worse than javascript.

[ericmcer]

I wouldn't call it good, but Go was designed for applications performing large numbers of concurrent processes. It is really easy to just wrap a block of imperative code in a try/catch, but it becomes much more difficult when you have a bunch of different goroutines communicating over channels producing outputs at indeterminate times. Like you need bespoke error handling for every use case, you can't just say: "400 try again later".

[LtWorf]

Python has async and try blocks, what's the problem with having both exactly?

[azangru]

> Letting google implement a new language for the web would probably result in something even worse than javascript.

Why? Javascript was famously written in ten days, was intended for casual scripting, and has not made up its mind whether it wants to be a Java or a Scheme. What could google invent that would be worse?

[LtWorf]

Because go is a poorly designed language as well, with terrible error handling.

[dzonga]

Alex Russel - member of the Chrome core team has a few excellent titles on why React is not the way to go

1. Market for Lemons - https://infrequently.org/2023/02/the-market-for-lemons/

2. https://infrequently.org/2024/11/if-not-react-then-what/

[ragall]

> The JS engines are all relatively fast now.

That's only if you're limiting yourself to laptops. In the smartphone space, the median device (even in the US) is an Android running 2-4 Mediatek cores with a 10-year-old design. On those devices React is unuseable: it can take 5-10 seconds just for initial parsing of all the React code.

[kumarvvr]

Do you consider Angular to have a better rendering system? Or is it similar to React?

Asking because I use Angular and want to learn other frameworks in case Angular is just as bad for long term.

[carshodev]

I analyzed all the major frameworks years ago and went with Svelte when svelte 5 came out. It is all I use now, the development team is highly responsive and cooperative with the community, the founder Rich Harris has a pragmatic approach and tries to keep it as compatible with html/js while still providing great DX and massive efficiency. It natively supports serverside rendering that turns into a SPA once it hits the browser.

Angular is probably more efficient than react but The DX is going to be worse than svelte or vue.

If you want the fastest apps in environments with low ping then use Qwik.

If you want the best overall experience, great customizability, compatability with any js package, great efficiency in most situations, and a great developer experience just go with Svelte (or vue maybe).

Angular might be fine, I don't know. I never used it extensively. But I do know that svelte is the only framework that I like using now.

[epolanski]

Angular uses directives for rendering, that allows compilers to optimize rendering.

React model uses plain JavaScript expressions which are harder to optimize.

[NamlchakKhandro]

Do some research, experiment. Make up your own mind.

[Cthulhu_]

Asking people / reading opinions on the internet is part of research though.

[icyJoseph]

Didn't the React team present an exploration of Performance?

- https://www.youtube.com/watch?v=uAmRtE52mYk

It showed that it is fast already, faster with the compiler, and could even be way faster than signal based approaches, and even faster if it dropped some side-effects it does. Pulling from memory here.

[agos]

it's not a really unbiased view. React's team has made very clear that they won't even start considering a different approach, and this (and other) is just their narrative to support their stance (which never seemed under discussion), and it borders on gaslighting the community which still has to deal at least with the two giant issues of:

1) knowing why something rendered is almost impossible 2) even for skilled developers who know what they are doing it's quite easy to introduce performance regressions. In other words, it's not a pit of success performance wise

Meanwhile (and this is also never addressed by the React team) if you use other frameworks some issues (for one: effect dependencies) simply are not issues

[criticalfault]

> I would rather the web was based on a statically typed language that had better error handling practices like Go.

So, dart?

Back in the day Google had plans to make a dart VM in Chrome, but powers that be didn't like this idea.

So here we are. it's 2026 and the web is still limited to one language. Dare I say the only area where we don't have alternatives.

[pjmlp]

There are other areas.

Embedded development, high critical systems, mobile platforms (the choice isn't really there), game consoles.

It is mostly C or C++, Swift/Objective-C, Java/Kotlin.

There are other alternatives you might want to point out, notice however they need integration layers, leaky ones, some yak shaving not much different than targeting WebAssembly, and still having to talk to JavaScript.

[criticalfault]

if you say apple allows only one language, it may be true. you don't have alternatives. but you can change platforms.

there is no alternative to the web and within the web there are no alternative languages.

for embedded, you have options, no? and I don't mean glue: rust. quick Google says Ada and assembly.

[pjmlp]

The options for embedded are similar to asserting WebAssembly is an option to JavaScript.

Assembly is not an option per se, some embedded devices like PIC, usually still have to be written in Assembly.

Yes you might have Rust, Ada, Pascal, Basic as alternative, however the choice only goes as far as the CPU vendor SDK supports alternative toolchains, or the whole certification process allows for a choice (hence why Ferrocene exists now).

So if in the end you still have an option to go outside the trailed path, it usually means yak shaving to make your toolchain work on the target, or have bindings to the official SDK, instead of actually solving the problem, had you started with the official SDK languages.

[criticalfault]

webassembly is not an alternative to Js. if someone else said it, fine, but I didn't.

the reason why I didnt is because I despise JavaScript and was hoping that webassembly would give an alternative. which never became an alternative.

with embedded you are arguing for my point. you say sometimes there are alternatives (maybe depending on the platform). sometimes not. you can change platforms as well. that's fine. sometimes is very much different from none. and we have none for the web.

[owenpalmer]

> People relying on bloated React packages is obviously not great but that is nothing to do with javascript itself.

JS is slow. If React was written in C++, the performance wouldn't be an issue. Then again, React is trying to solve DOM issues, not JS issues.

[pjmlp]

I keep enjoying SSR with Java and .NET frameworks as much as possible since the 2000's, no need for Go alone.

React is alright, when packaged as part of Next.js, which basically looks like React, while in practice it is SSR with JavaScript.

[fud101]

I'm tired of HN complaining about react for dumb reasons. To be clear, performance and bundle size matters for some things - if that's your complaint, whatever, i have no issue. My issue is there are whole host of use cases for which React is perfect, it has a functional declarative style which favours human understanding and correctness. This is a good thing. This is what the core of modern React gives you with functional components and hooks. You can do a lot with the core these days. Svelte and Vue are inferior for all the reasons React is functional and those other choices are imperative. I could go on but stop trying to make Svelte a thing, no one is buying.

[cosmic_cheese]

I come from the native desktop/mobile world more so than from web, but I’d strongly contest the idea that declarative/functional is always better than imperative/OOP.

My experience is that declarative starts getting mind-bendy and awkward past a certain point of complexity. It’s nice when it’s simple enough for everything to fit on a single screen without too much scrolling, but past that you need to start breaking it out into separate files. That’s not too bad initially, but eventually you end up with an infinite-Matryoshka-doll setup which sucks to navigate for anybody who doesn’t know the codebase because they have to jump through 7 files to drill down to the code they’re actually interested in and makes it more difficult to get a thousand-foot view of it all.

Also, the larger the project the more likely it is that you’re going to have to pull off acrobatics to get the desired behavior due to the model not cleanly fitting a number of situations.

Declarative is solid for small-to-medium projects, but for more “serious” desktop class software with complex views and lots of panes and such I’d be reaching for an imperative framework every time. Those require more boilerplate and have their own pitfalls, but scale much better on average for a dev team with a little discipline and proper code hygiene.

[everforward]

I like functional code, but part of the issue with React in that regard is that it likes to hide state from you.

Eg all those providers that are inputs to your component but get hidden away.

It really diminishes the value proposition of functional code because the implicit inputs make the output feel non-deterministic. Eg you can have bugs because of state in a provider that is a transitive dependency of a downstream component. You never pass it through explicitly, so it’s not readily apparent that that state is important and needs to be tested.

I find imperative to be a mess because of bugs in teardown (eg someone added a div, that div isn’t properly removed when re-rendering, problems only appear when there’s 3 or more left over divs). Unless you tear everything down and rebuild it on view change, which sounds pretty functional to me (though probably not pure, but what is outside of Haskell?)

[cosmic_cheese]

I could see where imperative might be more of a mess on the web compared to other platforms, but there’s probably ways to alleviate that. One that comes to mind is never using bare HTML primitives and only ever using components with proper teardown/management built in, of which could be enforced with some combo of linters and tests.

EDIT: Thinking about this some more, I suspect that intermingling of low level primitives and high level components is the root of a lot of problems on the web. It’s convenient in the moment but the mismatch in models is a recipe for trouble.

[smrq]

Alright, I'll bite. What about imperative programming fixes the scaling issues you're describing?

Typically programming scale is regarded as a benefit of FP over imperative programming, as the lack of mutable state results in less moving parts to reason about.

[cosmic_cheese]

Part of it is solved by how longer files are much more readable in imperative setups and can benefit from things like an editor/IDE being more able to jump around within the file since it’s not a big tangled up deeply nested chunk and developers can add things like titled section dividers for the editor to latch onto.

And no language will fix all these woes on its own, but problems take a lot longer to crop up with a disciplined team in an imperative app compared with a declarative one.

FP probably does scale better when we’re talking about the nuts and bolts under the hood, but I don’t believe it’s well suited for UI except in the simplest of cases. There’s too much in that domain that’s at odds with the nature of a declarative/functional approach.

[array_key_first]

React is not actually functional - hooks are not functions, they're magic functions that smuggle state.

The main problem with react is that it's, ironically, not reactive. It greedily re-renders, whereas Vue actually reacts to state change.

[ericmcer]

Why is Vue, Svelte, Qwik etc. faster?

React done poorly can be slow. Bad code can just force the virtual DOM to diff unnecessarily 1000s of times and your app will still work fine for the most part. That said, if you are intelligent about when you force React to reconcile state changes with the DOM it is very efficient.

All of these frameworks purpose is to synchronize the state of your app with the state of the DOM. There is no getting around that, that is why they exist. Vue uses a virtual DOM with diffing as well, I am not sure how Svelte/Qwik do it but I imagine they have a similar mechanism? Like you can't get around the fact that at the end of the day all of these frameworks exist to say: "The data in the users app updated, what DOM updates do we need to make to reflect that?".

Anyway that was a tangent but, I think React is perceived as "slow" or buggy because the vDOM & reconciler are so flexible that it allows people to do extremely dumb things while coding and it will still work.

[carshodev]

If you don't understand why these are faster then you need to look at the source code and benchmarks.

Qwik is faster because it splits every single reactive element into a loader that only hydrates exactly what is needed when its used, that's why its good on low ping environemnts but can be very bad on high ping environments regarless of DL speed.

Svelte is faster because it uses signals under the hood, has tons of optimizations, doesn't use VDOM, and has a much better diffing algorithm to only update what is needed.

Yes you can make react "fast enough" noone is denying that. Its used by millions of websites. That does not change the fact that all of these other frameworks are faster than it at doing the same operations/dif changes.

[slopinthebag]

React's model is fine, it's just the wrong language. React implemented in Rust for example can be much faster, although you pay the cost differently for wasm <-> js communication.