React Is Winning by Default and Slowing Innovation
Posted4 months agoActive3 months ago
lorenstew.artTechstoryHigh profile
calmmixed
Debate
80/100
ReactFront-End DevelopmentInnovation
Key topics
React
Front-End Development
Innovation
The article argues that React's dominance is stifling innovation in front-end development, while the discussion highlights both the benefits and drawbacks of React's widespread adoption.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
15m
Peak period
142
Day 1
Avg / period
22.9
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Sep 15, 2025 at 1:46 PM EDT
4 months ago
Step 01 - 02First comment
Sep 15, 2025 at 2:01 PM EDT
15m after posting
Step 02 - 03Peak activity
142 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 25, 2025 at 2:40 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45252715Type: storyLast synced: 11/22/2025, 11:47:55 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Otherwise the front end land is still very dynamic and so on, I think it's great, there are lots of options.
If some boring insurance company doesn't pick the coolest new framework and picks react instead. I don't think that's a problem. Gotta go be with the cool kids to do the cool new things.
Personally, I loved it... React + Redux + MUI = Winning (IMO)
A sentence written by someone who clearly hasn't worked on a large Angular 1.x project.
I've worked on 2x, if not 3x larger React codebase without these issues. I can't tell a single instance where language tooling was failing me so severely that I've contemplated turning it off because it's creating more uncertainty than its helping.
I'm relatively new to Angular 20 itself—only used Angular 1, and also migrated that project to React. So I'm not yet qualified to make big statements about it (but a preliminary gut feeling is that it often feels complex in the wrong places). C'est la vie though
React didn't win by default, it won because developers tried it and found it was better. It absolutely won on technical merit.
There's a bit of a question of whether React would still win on technical merit today, versus all the next-generation frameworks. I personally think it is still better than Svelte, Vue, etc, but I'm a bit of a React apologist.
Meteor was node framework. jQuery is probably still more popular but it is only a lib. Vue had a Chinese language problem.
React won because a framework by Facebook felt safe.
Products rarely win because of technical merits. Products win with marketing. Technical merits can add another layer to the marketing but without facebook's brand people would still be on angular.
The short answer is that what you're asking doesn't really make sense to me. I think of the lifetime of state as analogous to member variables of a class. In the same way that member variables in a class are always visible to the entire class, a state variable in React is always visible to the entire component. You wouldn't want it to be scoped to an if block any more than you'd want a member variable to be scoped to an if block.
Maybe now you're thinking "well, that's limited in an annoying way, and Svelte is better". Maybe. But I suspect for any problem that exists that you think needs conditionally-scoped state, there's a nice clean solution in React. That's what I suspect, anyways. But I very rarely run into problems in React that I can't express in nice, clean code.
Don't forget about having a migration path. I don't know how common it was (or how messy it might be, I never did this myself), but before Redux became popular, people were using Backbone models as the datastore for React. So existing Backbone-based apps had a way to piecemeal migrate to React.
That was in 2013. Angular 2 came out in 2016, and by that point React had won. Have had to dabble in other frameworks since then, and none of them seem to do anything significantly better than React. I spent my early career learning a new FE framework every year, at this point I'm happy to have something boring that does what I need and has a great ecosystem around it.
React’s main benefit wasn’t technical, it was organisational. It’s so opinionated that it’s difficult for an incompetent developer to introduce very low quality code into the project. Meanwhile in AngularJS, a developer with a clever implementation idea was a terrifying prospect for future productivity.
One of the biggest criticisms at the time (And perhaps still now) was that it wasn't opinionated at all. It didn't make assumptions as to how to do routing, or to fetch data, or to handle state. The community eventually converged towards a handful of solutions, like redux, but it was easy for each project to have its own combination of flavours and patterns.
Angular was an all-batteries-included MVC framework, with DI, testing framework, and one true way to do things. The reason why it's harder to introduce very low quality code in React is because React is just functions, returning JSX, executing when the function parameters change.
On the other hand, angular had comically large footguns due to its very high complexity. Have a look at the legacy documentation, the page about "scopes" by itself is longer and introduces more concepts than the entire "Thinking in react" page.
> Angular was an all-batteries-included MVC framework
As said back then, React is just the "V" in "MVC".
I am so glad to be old and have lived through the transition from Angular to React. To understand why we have React. In fact I am so old I have lived through the transition from Adobe Flex to Javascript Frameworks first.
And the thing that is clear to me is that wave of Javascript Frameworks, of which Angular was one, looked at Flex and leanred all the wrong lessons (I'm looking at you two-way data binding) whilst React got second mover advantage and learnt all the right lessons.
Fun times.
* Two-way data binding spaghetti
* Boilerplate-heavy reactivity
* Opaque, framework-specific magic
* Manual state updates/transitions
React didn't win "by default" (whatever that means), it won because it was better than most of the other options at the time.
I agree that, on purely technical grounds, it isn't as strong of a framework as other competitors anymore, but React is and has always been Good Enough™ for most companies, to the point that it's not worth reaching for anything else most of the time. And I say this as someone who doesn't like most things about modern React.
If a framework is easy to use and everyone knows it, it's simply the best choice for 90%+ of teams.
There’s plenty of users who care, but when the competition is also all slow and heavy they don’t get any choice in the matter.
Even languages or environments that try to "steer the developer into the correct direction" have only really managed it when the new direction is something they already might've chosen to write. Otherwise, you just end up with many square pegs filed down to fit in round holes.
Frontend skills are misunderstood by most of HN because it's a hard role that directly involves business and product wants. There's a ton of hiring (and firing) because it's not easy to find the right people who can communicate about the work clearly with non-devs, navigate the office politics, know what to push back on or when to ask questions, and still write good code.
>“But proven at scale!” jQuery was proven at scale too. Past success doesn’t guarantee future relevance.
jQuery is still one of the most used front-end libraries, used on 80%+ of all websites. It's easy, it gets the job done, and a lot of sites don't require more than jQuery. jQueryUI can actually do a lot of stuff to build basic web applications. React and every other tech mentioned in the article is just too heavy for most website needs. When you need a build step, that increases the complexity and requirement for developer resources compared to something simple like jQuery, which is probably why jQuery still gets used so much.
Because it's just a library, not an opinionated framework, keeping everything consistent across a development team of varied tenure and experience levels will be a herculean effort.
…IOW not every app needs to be an SPA, but if it is, it’s still true that nobody needs most of it loaded at any given time. Give me my RAM back.
React is mostly HTML driven by data. "HTML killed front end innovation". Well that enabled standards to build real use cases on it with a common ground.
Before React, the Web world was a mess. In 2025, you have lots of frameworks to explore. React did not kill front end innovation at all, it just became a standard that gives more common understanding to building a website.
I wish! Mostly though, React is a terrible mess of hooks with weird rules, suspense, “use client”, pedantic docs, and millions of other idiosyncrasies that have no business being this mainstream.
I think most people agree that the core ideas are great. Eg composable components, props, unidirectional data flow etc. There’s a reason that all other reasonably popular frontend frameworks adopted these ideas. It’s great that React established them. It’s just a bit sad that React established them.
Are you referring to something in particular here? I've had my issues with the docs in the past, but I don't think I'd describe any of them being related to pedantry.
So eg when you want to focus an input, how do you do that? That's the input itself right, that's my core UI, that's not synchronizing, it's not an external system so I'm not supposed to use useEffect for that, right? That'd be bad, no?
Turns out I do need useEffect, and in fact it's the only way, barring using 3rd party hooks or components that, themselves, use useEffect for this. And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app! That's not an external system at all. It's as non-external as things can get and I'm not synchronizing anything, I'm focusing an input.
This entire "external system" story isn't at all about what useEffect is, it's not what it does, it's merely what the React designers have decided you should use it for.
useEffect lets you run side effects. That's it, that's all there is to it. But they rewrote the docs with total beginners in mind, and put them so full of dos and donts that they forgot to explain what stuff actually does. Gaaah.
And half the documentation is like this. It dances around the actual behavior, never really explicitly saying what things do or how they work, with huge rants about what I ought to do and no info, except maaayybe hidden in some expando, about how things actually work and why.
[0] https://react.dev/reference/react/useEffect
> And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app!
External systems usually means stuff like an event system, network requests, or something else not managed directly by React. Unless you're reaching outside the area of the DOM React is managing, you can usually do this in event handlers or (for spookier cases) ref callbacks. There are certainly exceptions, but it's often an architectural smell.
Further down in the docs you'll see[0]:
> Effects are an “escape hatch”: you use them when you need to “step outside React” and when there is no better built-in solution for your use case.
[0] https://react.dev/reference/react/useEffect#wrapping-effects...
Do you mean that the information isn’t useful? This page is explaining the process React takes when rendering, the general version of which hasn’t really changed since it was released. There are differences in things like Suspense and SSR, but it’s broadly the same. Knowing the difference between render and commit phases is important for other parts of the docs to make sense.
What sort of behind the scenes workings would you want explained here?
The component render function is pure, meaning you can re-render component without unwanted side-effects. So on encountering an unresolved promise, halt and throw the promise, then have the runtime catch the promise and re-execute the render when it resolves. I thought this was really an elegant way to introduce an asynchronous dependencies.
This inverted behavior is the cause of most of the pain and footguns in React and React Hooks because the way state behaves in a React component is not the way state behaves in any other front-end JS one would normally write.
That's why I think for some folks who started with HTML + vanilla JS, React Hooks just feels wrong. It points the reactive callback to the component function whereas every other framework/library uses some sort of signal to point the reactive callback to a handler. Because React points the callback to the component function, then you have to be really cautious about where you put state inside of a component[0][1][2]
Even You wrote this about React's design choice which I think sums it up best:
If you want to "feel" this for yourself, here are a series of JSFiddles:- Vanilla: https://jsfiddle.net/qtmkbdo2/8/
- Vue: https://jsfiddle.net/vys2rmup
- React: https://jsfiddle.net/0gjckrae/1/
It should be obvious that Vanilla and Vue behave like how one would expect callbacks to work. React, because it points the callback to the component function, then requires that you be cognizant of state inside of the component function (placement, memoization, immutability, etc.). All of the pain of React is self-imposed from this design decision.
You can read more about it here: https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo...
--
[0] https://adevnadia.medium.com/i-tried-react-compiler-today-an...
[1] https://tkdodo.eu/blog/the-useless-use-callback
[2] https://adevnadia.medium.com/react-re-renders-guide-why-reac...
So really, the key difference between React and Vue is that your function component is not the setup, it's the template.
In Vue, for example, when I set up a `watch`, the change in state only invokes the callback that is wired to the state. In React, the entire component function is invoked again on a change of state.
Usually I write a few helper functions to streamline working with elements, attributes, and registration of element + CSS. But even without those, I think this approach provides a good level of simplicity without introducing libraries or frameworks.
It's a minimal, compilation-free JavaScript library that adds reactivity to native web components, as well as scoped styles and a few other ease-of-life features.
https://vorticode.github.io/solarite/
Is that not still considered reactivity? If so then I'll update the docs.
Mobile development forums were having all-out wars regarding MVP vs MVVM vs VIPER vs ... vs ... yadda yadda.
Now I can just enjoy stable predictable tooling and I can benefit from tons of examples and documentation.
One thing I like about React is that if you want it can be very simple.
This means that in theory the backend/runtime can be replaced (and was replaced ones from React to Preact (0.7.0 -> 0.8.0) then to use hooks and signals instead of class components (0.19.0 -> 0.20.0), and the code will remain the same.
This has one drawback which deters framework creators from choosing the language since there is no reason to innovate on something that is already "done", which leads to fewer people using it in general and hinders adoption, but I'm still optimistic.
What's surprising to me is how many alternatives exist in this space. Between elm, imba, svelte, and mint, and probably more that I don't know about, I wonder how many devs in the world are shipping to prod using them.
edit: have you thought about including Form Validation to the core lib?
There is a module for that in the standard library (https://mint-lang.com/api/Validation). Moving the functionality into the language level is intriguing.
https://www.react-hook-form.com
React Hook Form is beastly.
It may be the default today, but it largely earned that position by being one of the better options out there. Today there's alternatives and even Angular still has a decent following, not that I'll touch it if I can avoid it.
edit: Just adding to the pain at the time... iirc Webpack + Babel + Sass + CSS + ReactTransforms each with wierd bespoke configuration options... Babel itself was a massive pain for even trying to limit to modern-ish targets or multi-target.
React itself was a bit awkward as well, a lot of the concepts themselves were difficult, and IMO, it didn't get much easier until functional components, even if that really complicated the library itself.
I still have mixed to poor feelings on Server Components as I think it's largely a waste for the types of things people typically build. HTMLX (speaking of innovation) is likely a better option in that space.
That said, I do like MUI (formerly Material-UI, a Material Design Implementation), I think the component architecture is really thoughtful and works well, biggest issue is that devs don't take the couple hours to read the docs and even have awareness of what's in that box.
I also like Redux and even hand-written reducers and extensions quite a bit.
Good thing that wasn't the premise, then.
The article is specifically looking at reasons for React's success other than its technical merits. It does not deny that it has merits, nor does it deny that its success is partly due to them. It only says that its current success is no longer wholly due to them, and backs the point up with examples of alternatives that are claimed to be technically superior and that are not achieving success commensurate with that superiority.
You can disagree on the superiority claims, you can disagree that innovation in this area is a good thing (many don't!), but I think the main claim is very believable: that in the present day, React's success is heavily helped by its default status.
If there was an MUI for Yew/Leptos/Dioxus I'd probably have switched to them and dealt with the minor performance hit with wasm. And yeah, there's component libraries, but not nearly as complete or polished in usage.
In my experience React is rarely the best solution and adds a huge amount of complexity which is often completely unnecessary because React is rarely needed.
In the early days my very controversial view was that frontend developers tend to be fairly mediocre developers, and this is why a lot of frontend frameworks suck and frontend developers just mindlessly adopt whatever the hot new technology is with seemingly no concern for performance, maintainability, security, etc.
But honestly I'm not sure this explains it anymore... There are a lot of really talented frontend development teams out there working for companies with plenty of cash to try something different. I don't really understand why there's no serious competitor frameworks in terms of market share out there.
As far as I'm aware there's no analogies to this in other areas of the web tech stack. There's plenty of backend frameworks to pick from depending on the product. There's also plenty of competitive DBMSs, cloud providers, package managers, code editors, etc, etc. I don't understand why frontend development is so static in comparison because it's certainly not that React is the perfect solution for everything.
I can't speak to the complexity you've encountered, but for me it's pretty much zero. A button component is just a function. React-Router is good enough and code splitting is pretty much just changing how to import something. Component state is dead-easy to write by just adding a useState hook. Bundlers pretty much handle everything these days so not to much concern about size.
Your view on front-end developers having been mediocre in the past isn't far off though, at least in my experience. I noticed a big difference between the people who wanted to build nice looking pages and the ones that wanted to build applications myself. Even today it amazes me how many people have never unit tested their code, have no idea about layering an application and have poor JS/TS fundamentals. It's gotten a lot better though.
Ultimately it isn't perfect for everything, but for a lot of people it's an easy choice. And for me personally, the tons of other JS frameworks do very little in that area that I'd pick them. I'd rather spend my time working on the product. Lol, maybe its just the default because its the default at this point.
For me, everything depends on the site and the host.
For 80% of websites, a button is <button>, a router is just URLs that point to files, a state is just a json object in localStorage.
For 15% of websites, a button is <button>, a router is a single file that imports an auth provider and a storage provider which are chosen based on the host.
For the remaining 5% of websites which are actually true applications, I'd reach for a RoR inspired framework (so Laravel for PHP host, Adonis for js host, etc...).
No react needed.
There are a lot of valid criticisms of React, but I don't think this is one of them. These problems are not really new with hooks. They're actually problems which existed in some form in the class component API. Taking them one at a time:
Dependency arrays: I cannot count the number of bugs I encountered which were due to a lifecycle containing some code which was supposed to be called when certain props or bits of state changed, but completely forgot to check one of them.
Stale closures: the second argument to setState allowed this exact bug. Also, people would bind methods in incorrect spots (such as in lifecycle methods) which has the same result.
Misused effects: at varying point, class components had access to the class constructor and the lifecycle methods componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentWillUpdate, componentDidUpdate, componentWillUnmount (this is from memory and is definitely only partially complete). Misuse of these was incredibly common. An article like "You Might Not Need an Effect" but titled "You Might Not Need Lifecycle Methods" or "You Might Not Need the Second Parameter to setState" would have been very helpful in the past.
Hooks reduced the number of opportunities for making mistakes, make enumerating those opportunities easier, and, critically, made them easier to detect and warn users about.
This is a normal part of optimizing React components and the exact reason for the React compiler’s existence.
I believe the official recommendation since hooks were announced is to omit the array unless you need it. It makes things much easier to reason about, and many effects can run on each render just fine. It's mostly[0] a performance optimization. Oftentimes you'll want to make an additional comparison between previous and current props to decide if you actually want to do something anyway.
[0] Possibly entirely. Remember that useEffect's goal is to synchronize with an outside system. Additionally, while I can't find references for a similar thing in the docs for useEffect, for useCallback and useMemo the dependency array is explicitly not supposed to give any semantic guarantees about when the value will be re-memoized. React is free to "forget" values if it wants and re-memoize when needed.
Yes, of course. That's why it's recommended as a first step and not as something to do all the time (though you often can if you use something like usePrevious).
> For two, this is exactly what I mean with leaky abstractions. Vue and co do not have this limitation because they approach reactivity from a fundamentally different angle. They come with their own bag of problems, but I would argue that their smells are considerably smaller than what hooks bring to the table.
I'm sure it's possible to do it better, but I'm discussing this in the context of hooks versus the class component APIs they replace.
I'm not very familiar with signals beyond what I've read about them in the past. What I've read about them sound exactly like Knockout observables[0]/computed observables[1], which I'm extremely happy to have left in the past. I assume frameworks using signals must use something to scope subscriptions or enforce update directionality?
Do signals provide a solution to knowing when to run an effect to e.g. establish or close a network connection?
[0] https://knockoutjs.com/documentation/observables.html
[1] https://knockoutjs.com/documentation/computedObservables.htm...
With hooks you still need to think about lifecycle, side effects, and state, but the syntax changes.
The real solution is overall application design and thinking through architecture, but unfortunately that’s higher effort than “just use hooks bro”.
As the rest of my comment points out, the thing hooks did was make these issues more tractable by reducing the places it was possible to make them. Instead of worrying about which logic is needed between the constructor and over eight lifecycle methods (the number of these was reduced over time of course) for your components, you just have to ask "what does this effect depend on?", "What should it do?", and "how should it clean up after itself?".
This reduces the number of places it's possible for bugs to appear but you can still make them. I believe people blame things on hooks because it forces them to confront those (often extremely subtle and hard to catch until it's too late) bugs earlier by putting them front and center, especially with a lint rule. This is good.
In addition to all that, we also got two major other advantages: sharing of logic/composability and making code using hooks much more minifiable than class components (unlike functions, object properties can't be mangled/shortened by minifiers). Plus we get a vastly improved DX because of fast refresh, which is an excellent bonus.
Performance is one thing (the internet is getting slower! Impressively bad!), but also webapps are becoming so incredibly overdesigned, at the expense of the user experience.
Before we had the discrete fields of front-end engineering, design, UX, etc web design was inherently limited and we used standardized shorthands for everything across the industry. With React it's so easy to throw out best practices and try to redesign every single experience from scratch. Combine that with the Figma-fication of web design and teams can get lost making pixel perfect designs that are usability nightmares.
Let's be honest - what percentage of modern React websites actually provide a better user experience than Craigslist? It's fast, I'm not dealing with buttons that move around as a page loads, unusual text sizes at non-standard screen sizes, etc. (The famous McMaster-Carr website is another example).
Then again, I'm hardly one to talk. The last time I wrote actual web code was JSPs in 2001. I did hack on some JS code to add dynamic table sorting to some html report pages I created later, but that's about it.. Never liked JS's idea of "we can be every programming language at once with the standards from none of them".. Sure, it's flexible, but so is a noodle..
While the VDOM overhead does exist, it's not the performance bottleneck. More likely reasons are waterfall fetching (present in all frameworks and solvable by React Server Components) or excessive revalidation (solved by the compiler)
Maybe it can be justified for real apps like desktop apps but the vast majority of web pages that use React could probably provide a better experience to users without it.
Which is to say, that isn't really a goal or objective, imo: it's an unhealthy prediction for misoptimizations, to worship the vanilla.js performance above all past.
More-so, there were so many very very very unperformant web apps before React. So many incredibly bad ways to manipulate DOM. And the spiralling combinatorial possibilities of updating state yourself were gnarly, create enormous cognitive load on every dev in the org.
I know I've just written a pretty big anti- post.
But I feel both sides really strong. I don't want either extreme to be accepted. Inner Platform I see as good and necessary. But also I definitely hope for better someday, see us making lots of Inner Platforms, that might be much smaller / better organically interweaving Inner Platforms. Reacts flaws are significant, a full extra DOM, diffs, coarse grained updates (which I think maybe React Compiler tries to seek out?) all do so much but are a huge abstracting for an Inner Platforms, not necessary imo to what Inner Platforms would have to be. It's amazing how much React gets us, how much consistency & clarity of code & it's purpose (with its immediate mode ish rendering scheme), and the performance is overall stunningly good. But there certainly is significant overhead, lots of code to load & execution time for it. Rather than looking to return back, I want to look onwards.
The "Inner Platform" idea is an amazing & useful framing. I want WebComponents to let us escape this, to be some common system we can agree too, but I suspect even with WebComponents—if they get any broader traction—we will eventually see "inner platforms", paradigms for use and interlinkage that go beyond the very basics of HTML (although Invokers radically and excitingly open up the space of component interacting with components in standard ways!).
Maybe it's not so clear cut a decade+ later, but pieces like The Extensible Web Manifesto speak to a clear loud vocal acceptance of the web as a lower level platform, as a tool that can have higher level expressions built stop it. Theres an expectation of going further, architectures above. https://github.com/extensibleweb/manifesto
Imo it sucks that we near a decade of React Uber Alles, stealing the oxygen that would nourish the web's flourishing. And there's hope for using more of the putter platform: that React as an Inner Platform does a lot of reinvention that maybe ought not be necessary. I guess the question I want to ask is, how little can we make our Inner Platforms, while still retaining the legibility of architecture? Can we decompose that Inner Platform into smaller interoperable pieces, protocols, for how things signal and flow, rather than it being a monolithic platform? What of the Outter Platform could be better used for performance and inter-op, to de-interiorize?
It is dangerous and bad to me to demonize Inner Platforms, to attend only to notions of pure performance as the guiding factor. The karmic wheel imo needs to be going around faster harder, creating and destroying the inner platforms. We have a lot more to explore, have only a couple examples of what web architecture could be and right now the React Inner Platform is a thick boy of an Inner Platform. But it's not just getting rid of Inner Platform that's the goal.
That said if React were to be adopted as a web standard it might be possible.
I detoured into heavier focus on backend work for quite a while, concurrent with the rise of React, and watched its rise with suspicion because it seemed like such an inefficient way to do things. That, and JSX's limitations around everything having to be an expression made me want to gauge out my eyes.
Still, React pushed and laid the foundation for some really important paradigm shifts in terms of state management. The path from the old mental models around state to a unidirectional flow of immutable data... re-learning a totally new mental model was painful, but important.
Even though it's been chaotic at times, React has delivered a lot of value in terms of innovation and how we conceptualize web application architecture.
But today, when you compare it to something like SolidJS, it's really clear to see how Solid delivers basically all the same benefits, but in an architecture that's both simpler and more performant. And in a way that's much easier to organize and reason about than React. You still get JSX, server components, reactive state management (actually a MUCH better and cleaner foundation for that) and any React dev could move to Solid with fairly little mental re-wiring of the neural pathways. It doesn't require you to really change anything about how you think about application architecture and structure. It just basically does everything React does but better, faster, and with drastically smaller bundle sizes.
Yet I still have to begrudgingly use React in several contexts because of the industry-wide inertia, and I really wish I didn't have to.
SolidJS still has some major pain points; the one I found was not knowing whether a prop was a signal or needed to become one. The type system doesn't help much. In React, you know for sure that if your reference changes, the component reading that reference as a prop will re-render. In Solid, it's less clear whether the update will be observed.
Amen. Data flows down. That, to me, is one of React's biggest strengths.
I think you'll find a lot of people begrudgingly have to work and really wish they didn't have to. That means using what they know, which means React. Which I totally get. People want to spend time with their kids, hobbies etc. Worst case, they might be caring for others, like their elderly parents.
Give me S-expressions instead. How else am I supposed to prove to frontend developers that I didn't make those up
Only half joking, it's same principle as how indentation-based Python ate world, while languages with `begin` and `end` keywords like Ruby and Pascal are hardly to be seen these days
ES6 wouldn’t have been needed. CSS-in-JS would have become standard decades ago. HTML would have almost disappeared too because parsing s-expressions would have been native. JSON would never been invented either due to S-expr.
In short, everything about the modern web would have appeared decades sooner and been more consistent.
Browser people should pick up slack and start developing sane components for the web. How about a backend-supporting combobox, or a standardized date picker across browsers? Then we wouldn't need to constantly innovate how we manage the state of those fundamental operating controls that browser still don't have in 2025.
Google functionally controls just enough of a monopoly via chrome that they can generally do whatever they want (and not do whatever they don't want to do). So that standards still mostly can't do anything google isn't enthusiastic about dumping dev time into.
And they're just barely not enough of a monopoly that they can't just go wild and actually turn the browser into a locked down capital-P Product. Safari and Firefox (in that order... much to my chagrin) are holding them back from that.
So browsers just kind of hang out, not doing too terribly much, when obviously there are strong technical forces that want the browser to finally finish morphing from a document viewer to an application runtime. Finally fulfill the dream of silverlight and java applets/JNLP and so on. But nobody wants to bother doing that if they don't get to control it (and firefox doesn't have the dev power to just trailblaze alone in OSS spirit).
So instead the js people just have to plow along doing their best with the app-runtime version of NAND chips since the incentives don't want to offer them anything better at the browser/platform level.
I really hope that never happens if only because the web dev on ramp will discourage anyone without preexisting technical chops.
This is a good thing! It keeps salaries high and keeps the dilettantes out. I am sick of getting my work devalued by morons
There are too many people trying to build "tech" who shouldn't be. We need more gatekeepers
No other GUI runtime or framework delivers true cross platform implementation. HTML, CSS and js are as open and as standard as it gets.
GTK sucks in its own ways and is not international standard.
Crazy statement. Any API not supported by Safari might as well not exist.
WebSQL? WebUSB?
It seems like Safari bends towards whatever is in common use, at least within a few years.
In the last 10 years, 3D NAND memory has scaled 10x (in bits per unit area). So… maybe not the best analogy?
HTML, CSS, and JS made sense back when the web was primarily text with some simple forms. It's a dog shit foundation to build highly interactive apps on. The whole thing needs to be thrown out and rebuilt.
Also iOS accessibility screen reader APIs are way better than the web. Accessibility actions for instance are great.
Even if you could ship chrome renderer on iOS you won’t be able to make a mobile web app feel as good as an iOS app. The little details, animations, and microinteractions that come with native apps are better, plus there are other less visiual capabilities like background uploads and prefetching. The moment you need something like an in app camera, a native app is going to be so much better.
I am old enough to remember the days of Internet Explorer, I can tell you that it was not fun. It is a blessing that we can at least deliver some pretty decent web apps today, and we should keep pushing for it.
Unfortunately we decided the correct way to provide the functionality was by layering bonkers ass abstractions on top of a system meant to largely display static text and images. In the year 2025 there is absolutely no reason we shouldn't have a unified coding language that allows you to render things in a web browser in a sane way.
At the very least we should have seen a substantial expansion of what HTML is capable of, closer to what HTMX is doing now, with a better way to style everything then fucking CSS. People complain about JavaScript but for my money CSS is the greatest sin.
Honestly between React, Angular and Vue, there's enough jobs if you do want to specialise, but the mental model between the three isn't that different that a good engineer wouldn't be able to adapt.
React is boring old tech to me at this point and I'm happy with that. Like choosing Java, C# or Python for the back-end. I'd rather focus on innovating my clients products until something earth shattering comes along.
Front end engineering has been a perpetual chase for The Shiny Thing™, constantly changing, with good excuses, but way too often throwing everything away and starting from scratch, forcing a perpetual catch up and periodic rewrites of everything.
Some maturity and a slower pace of change could be a good thing.
I mean, innovation is still happening, but it's not compelling enough to drop React for most apparently (at least not yet).
Huh, I wish. This is loosely related, but early in my career I worked in a company where one of the projects I was involved in was a relatively large-scale web platform. The system had quite a lot of interactive UI elements, but for some reason we weren't allowed to use any off-the-shelf UI library/framework like React (it was already around for quite some time), despite presenting arguments countless times on why it would be the better solution and save a huge amount of time.
Instead, we had to use a buggy and incomplete UI library that was built within the company, and the results were as you'd expect. Making changes to the UI was agonizing, the library's behavior and API was inconsistent, components were difficult to reuse, and you had to jump through hoops and monkey-patched nonsense to update the UI. On top of that, nobody worked on fixing the library itself, and eventually the system using it grew so large that making any fixes to the library would break the system and would need a massive amount of time to fix or rewrite all the broken components. The saddest thing was that the UI library itself did not actually do anything "innovative", just some things that are available in countless other UI libraries, but worse.
Sure, maybe it was my technical incompetence and poor decisions, but on the other hand, even then, I knew JS/TS quite well and wasn't one of those people who swear by a particular framework and know nothing else. I worked on other web-based projects before with various technologies and never had that many problems.
All in all, this story has played out many times before, and will again. I think you either have adoption or you have a modern solution without technical debt. React had constraints that don't exist anymore that shaped its architecture, and now it has an enormous community that cannot turn on a dime.
Svelte, Solid, and Qwik have the benefit of hindsight and browser advancements. In 10 to 15 years time we'll be talking about a new batch of frameworks that have the same advantages over Svelte/Solid/Qwik.
https://github.com/Qbix/Q.js
I will release a playground soon on qbix.org so you can try it out. You can use it alongside React and Angular
React trades this very minor performance hit to give us better developer clarity through a functional paradigm. This makes complex state management much easier to manage
A better article could've been written for this title. I just don't care about improving renders by 3ms when it's already fast enough
I think the reason React won, and is still top dog, is that improvements to performance at this point aren't worth it if you have to give up something beneficial
677 more comments available on Hacker News