Introduction
Two well-known JavaScript frameworks and libraries used for creating user interfaces are React.js and Solid.js. Solid.js, a...
For further actions, you may consider blocking this person and/or reporting abuse
Actually, React doesn't scale too well. At some point, you will inevitably run into the necessity to optimize updates, which will eat up increasingly more time. The main thing it has going for itself is the employability that comes with it being known to managers.
The thing that Solid.js cannot yet compete with is the state of the ecosystem, and it gets better by the day. I should know, being the maintainer of its testing-library and multiple community primitives. If you are building your components yourself anyways, you should definitely consider Solid.js.
I would pick solid any day🙌
React scales really well if you avoid dirty state inside your render function.
For example, a lot of people do this:
When they should really be doing this:
There's a whole religious movement in the React community that advocates against the use of memoization. This problem has become so big, that it has spawned the React Forget project, that will just auto memoize everything for you 😛
The issue here is that complex applications run on complex data, which often requires nested objects that change a lot - and then even memoization won't save you, as you need a changed object reference for the fiber walker to detect the change.
The only way around that is to not manage that state within react and
useSyncExternalStoreto subscribe to changes (or use a state management like mobx to emulate the behavior of Solid.js in React).Not sure about your use case, but i haven't ran into any trouble myself with fast changing data, even when building something like a stock rate checker that updates in realtime. React is extremely efficient at rendering, if it can rely on a clean state, that only changes when the value actually changes. If you start with dirty state high up in your React tree, once you get 10 levels deep, your component is recomputing 10x or more, while the actual value it relies on hasn't changed at all. Suppose that component is one of a hundred table rows all doing computations 10x on the same unchanged value... Even if that computation only takes 2ms that's still 2 seconds of CPU time that the user can't interact with your app :B and all of those 2 seconds can be brought down to 10ms with simple memoization.
In this case, it was an online meeting software supporting more than 50 attendees, each of which required rather complex state.
Not much more than the alternatives. Also, the problem with fibers vs. a signals-based architecture is that you still have to walk two trees until you even start rendering.
And while memoization allows you to re-use object references for unchanged values, you still need to create new references for changed values, or else your updates won't be detected.
Well I'm definitely not against signals based solutions like solidjs, just wanted to make sure that devs don't write off React because they refuse to memoize and are thus confronted with poor performance when scaling up.
While the benchmarks might be a little "artificial" in nature, they clearly reveal a major problem in the React library. React simply can't compete with Solid or Svelte, or pretty much 70% of the frameworks out there. It wastes RAM and CPU cycles left and right, and I wonder why people seem to be so fixated with it, even when confronted with the cold hard data.
React for new projects makes no sense to me. Why would I go for one of the worst performing libraries for UI in existence today? The only reasons are: Existing codebase, or need of the ecosystem, and the first one doesn't apply to new projects.
So this leaves us with the ecosystem reason. I, as team leader of a project written in React, studied my needs and decided to kill React. My only roadblock was Kendo Grid. I ended up making a replacement in Svelte. Now we'll move all code to Svelte progressively using
single-spa.Don't know if you've seen, but Rich Harris (the creator of Svelte) has some videos where he shows React and Svelte solutions of the same thing, and wow, React cannot come close.
I get that many people think React is king, and in some ways it is, but really is just a matter of time before a new king is crowned, and I think it will be Svelte. Svelte 5 early benchmarks place it in the top 5, competing with Solid and vanilla JS.
But even if all this doesn't convince you, let's talk about learning curves. Have you seen the documentation on the
<Suspense>component? Have you seen the documentation on the{#await}Svelte block (which provides equivalent functionality)? Svelte can be learned in 1 day. All of it. React? 1 month, perhaps.I believe you are talking from the perspective of an experienced developer trying to learn svelte. But realistically, we are going to be using newbies to judge the learning curve. I don't think it's possible to learn a framework in a day, IMO.
A bit exaggerated, but not exactly wrong. However, the learning curve matters not if all newly hired developers already know the framework.
In that case, what matters most is that internal and external code can be (re-) used – and React still has the most extensive ecosystem. Granted, there are many packages that are no longer maintained or have low quality, but managers cannot make such a distinction, so they can only judge the size.
So the best we can do is improve the ecosystems of the alternatives and all work together in order to find better patterns and solutions.
One of the issues I have with React is that it doesn't play nice with others. This is why I'm looking into Lit/WebComponents and perhaps Solid and Svelte.
I want to be able to create components that are small, efficient and performant and can be used in any environment without worrying about performance or interoperability.
I've noticed that a lot of component bundles for React are actually written in pure javascript or some other closer to javascript form and just wrapped to be React friendly - makes sense since then you can also use it in other frameworks. If you wrote it in React then you'd have to rewrite it for other frameworks.
I'm currently trying to determine if Solid or Svelte would be viable or perhaps I have to try sticking with Lit as far as possible.
It is true that React assumes an awful amount of control over the DOM and even overwrites fetch. I personally prefer Solid.js, but Svelte and Lit are also viable choices, all with their individual advantages and drawbacks.
If you are afraid that you need to rewrite your components, you might want to check Mitosis, which allows you to write components in a certain JSX flavor and compile them to React/Vue/Solid/Svelte/Lit and a multitude of others.
Interesting thing, Mitosis. The premise is super attractive, but I worry: The example shows a React-like example, and in all honesty, I don't think this would produce optimized per-framework versions of the component. Still, I just spent 1 minute looking at it. I'll shut up for now, and maybe have a better look at it.
You can use plugins to optimize separate use cases. It's less obvious, but a) optimisations can be shared over modules and b) this entry barrier helps avoiding premature optimisations.
Balance is key, Vue is the winner. Have no idea why anyone would recommend React for large projects. From the provided solutions it’s the least scalable one. Vapor is under active development and once it’s available I have hard time seeing any advantages Solid can offer. I’ve done production development with each of the main reactive frameworks and Vue is an easy and clear winner in performance, flexibility, ecosystem, DevEx, consistency, maintainability, learning curve. The only place where react has advantage is popularity, and given the JS development scene popularity is a very temporal advantage.
Apparently, React relies solely on its ecosystem. There are better alternatives in terms of learning curve, performance, and code style. That's where Vue stands out.
But when comparing there performances, the key battle lies in how effective the reactivity system is. This is where Solid shines. React and Vue use the same virtual DOM techniques, with Vue having the edge thanks to its direct tracking reactivity, which allows it to make changes directly to the DOM when an update is made to its reactive data.
Solid otherwise, outshine them by removing the virtual DOM and replacing it with a more efficient reactive system. I mean, it makes it better. My only issue with Solid is that it has the same code style as React. It will only be easier for someone coming from React backgroud to hit the ground running when working with it.
That’s why I pointed out Vue Vapor mode which is under active development and will be available soon. It removes the virtual DOM and implements Solid-like reactivity within Vue. Look it up.
Also I strongly disagree about the react ecosystem. It’s actually pretty bad. Things like routing, css styling and build and browser tools are behind and in some cases just sad compared to Vue counterparts. Even if you ignore Vitest, Vite, VuePress, Vue Dev Tools, Volar that are clear winners in their respective context, there are some other open source project such as Quasar (no react alternative), NativeScript, JSX/TSX support that are nothing short of impressive and incredible. Arguably the Vue documentation is better and more consistent too. Even just considering Next should be a good start in understanding how messed up the React Ecosystem is. To give where credit is due ReactNative is actually good, although I personally prefer single codebase solutions like Quasar and Ionic.
I’ve been using both React and Vue professionally for over 5 years and don’t know a single developer who would pick react given the choice and having at least basic experience with Vue.
That's why React is just a library not a FW. While I totally agree with you, for routing, styling, building things are just fixed/collected in Next.Js. I still had bad dreams when I had to re-configure react router and when I started working with Next 13 it was a pleasant surprise.
What if I don't want to use Next by Vercel? Why do I have to use another framework with questionable practices and affiliations in order to handle basic things such as routing and styling?
I had no other way. Our client's SA made this choice before I joined the team. This is an enterprise project, it's not always our choice, or even most of the time. Anyway, I think Next is quite ok. Just 1.5 years ago, one of our clients was looking for people with KNOCKOUT (!) knowledge. :D The whole thing was a rewrite, but it still required knowledge of a technology from 13 years ago. I'm just pointing out that I rarely choose, technology choose us.
I understand. But you also got to realize that part of the reason is developers like you defending and/or advocating for bad solutions as per in this example. Settling for solutions that are "quite ok" and promoting them in the community is how we reach a stage where the worst solution is the most popular one. On another hand voicing concerns and pointing out problems brings attention to alternative solutions which is necessary to displace the current popular choice. Given all of the conversation under this article, many of the posts on reddit, the countless tweets about issues, the state of issues in the github repository I believe sunsetting react is only a question of time. Sooner or later it will be just another KNOCKOUT technology from 13 years ago. And this can't happen too soon.
I'm not defending or advocating, you've got something very wrong. You can change at any time on a home project. In the case of a large banking software, which was started 3.5 years ago by 6 teams and now has a huge code base, it is simply not possible to always replace it with the best and fastest one. If the client were to support this in time and money, by the time it was completed, Solid would also be obsolete by then. The introduction of Next is already a step forward.
Vue Vapor, Svelte 5 and React Forget will be there at some point in the future. Solid is already there now.
That being said, you can work around most of the issues so there's no wrong choice except to call other choices wrong.
The more complex it is, the more it suffers from coarse-grained reactivity. React is dead. Just like that. I personally switch to Svelte to never see React again.
But you can't actually shy away from the ecosystem advantage; it's holding a lot of people down. Lol
Oh, yes I can. For example, I recreated all the functionality of Kendo Grid in Svelte to drop Kendo React. Fixed columns, dropdown column menu, inline editing, sorting, searching, column resizing. Svelte is so nice you actually enjoy building components. What holds people down is themselves. You just have to plan appropriately.
Fair
It's only that - and it's only a matter of time.
Solid.js is better than React in every category, except ecosystem size/breath.
Solid.js scales much better than React.
"React's virtual DOM and component-based architecture are well-suited for building large and complex applications"
Solid.js is the spiritual success to react.
It has all its upsides (except ecosystem size) and none of its downsides (missing signal based state solutions), while being very similar (using JSX and having similar hooks like APIs). Solidjs is the perfect choice for React developers.
Both Solid.js and Svelte -> are successors of React, because they learned on Reacts mistakes and improved/solved them, each in their own way.
Both Svelte and Solidjs are at the top of the performance charts because if this.
New/Junior Developers should learn
It's usually too easy to disregard the business side of a tech stack, which is where the term used in the title "efficient" becomes subjective to the context.
React isn't efficient in terms of performance compared to many competitor UI libraries.
Popularity might not make efficient code, but you really want efficient software within an efficient business. Sticking with what's popular can help alleviate a lot of issues, rather than focusing on specifics.
React in terms of jobs, and the number of people who use it is great. The more people, the better it's to find solutions to problems.
Even though other frameworks are better.
I am here to defend React. We have an experienced team, working with the library for many years on a quite big code base. We had performance issues, but fixed them without major impact. Our customers are also quite happy, maybe because they are not going into the performance horse race. React's big ecosystem, still improves with web frameworks like Remix, making it much easier to use the library. Of course, we will look into new technologies, like Solid and play with it. For developing major apps I would still wait until it gets more mature, though. SolidStart is still beta.
Great Share
Counter-argument :
A mature company has different sets of concerns when making choices
Concerns A : efficiency, performance, ...
Concerns B : how productive the team is with the framework, ie time to market
Concerns C : how hard it will be to hire good people
I am not into web development, so I have no idea who the winners are for each categories.
What I know is that while I value Concerns A, I value concerns B more, and I value Concerns C even more.
Just use Svelte, there is no need for VirtualDOM if you know how to optimize a UI. Plus we need to get back to basic JS not these React shenanigans
solid is dope 👌🏻👌🏻
I really do love a valid explanation backed with good examples.
The problem is that when you work in a team you can’t expect that everyone is aware and knowledgeable on how to deal with reactivity bottlenecks that simply don’t exist in Vue. I can go into detail, but If you ever worked on a large enough project you’ve been to the point where the number of WTF’s exceeds the change count in almost every PR. Reviews quickly become bottleneck watch outs where the focus is on making sure you have all memoizations in place and reduce dependencies as much as possible for the sake of not having to debug where the lag comes from instead of keeping focus on what we are actually trying to build/do in the first place. It’s really sad state of affairs, but hey everyone has their own preferences on what to do with their free time and I can respect that.
It was a pleasure to talk with you all about this. I completely agree that the react reactivity method is inadequate. Nevertheless, million.js is addressing this issue.
Tbh React is killing itself with its own hands.
From when the team started try to implement all the things others frameworks smartly implemented over the right amount of time to be mature and production ready, it's becoming more and more a complete mess.
Never seen a dev team suggesting you to don't use their official script to create an app with their own library! This thing alone to me it's disgusting. They are running after too much things that simply were not and are not for React, just to keep the market. Not smart at all.
As SPA framework I've choosen Vue3 - the right balance to me.
If I want to go enterprise level, Angular still rules, sorry.
Astro and a few tools for the rest.
I'll try Solid or Svelte because of its fine grained reactivity, with no hurry.
But, React can die, with all its facebook created hype that people has misunderstood as quality. Good for facebook, but maybe not good for everyone. I won't miss it.
Thanks for including Vue in the tables!
Hi Oscar,
There is no point in saying someone does not know how to use a certain tool if they do not agree with your explanation.
Are you saying people don't break stuff into components in Vue?
That argument is void.
React Forget is already forgotten… Actually just the idea that we need something like react forget to deal with memoization which only exists due to poor architecture and performance is crazy… Its hard to see past the pattern of patch on top of patch on top of poor design choices. It makes it hard to focus on building applications when you are fighting with the framework to get simple things like global context without re-rendering the shit out of everything. And let’s not discuss lists, filtering, reducers, layout effects, animations, etc.
Please remember that Forget only solves the issue of the need to memoize, not problems like large bundles and high memory usage. And it's not yet production ready.
Also, I wouldn't choose Solid because of performance only. To me, Solid's mental model makes a lot more sense than re-running components all the time. But I know that this is a personal preference, not a fact.
You should realize that your personal preference for React is not a fact, either.
I would rather choose Solid, since I'm already a member of its ecosystem team. In any case, why do you think would anybody need an excuse to choose a framework?
Use whatever you want, just don't go around claiming it would be the best without being able to back up such a claim.
I love that the new tools are atomic and performant. This speaks of a bright future for development. Finally, we'll leave behind the giant, syntax-poor, and performance-lacking frameworks (like Meteor, Angular, etc).
React started as a simple library for frontend development, offering class js and the great innovation of its time: JSX. When it was on the verge of fading away, they introduced hooks, bringing it back to life. Nowadays, it's proven that hooks aren't necessary and result in somewhat messy and hard-to-maintain code. This is where new libraries have come to further simplify the system and be as close to native as possible. React will persist as the new legacy in the coming years, until another tool gains popularity and builds an ecosystem like React's today: react-router-dom, dnd, react-query, lazy loading, CSS libs, and many other utilities to enhance development. We must remember that with just one library and language, we can't efficiently address all business problems.
Lastly, it's important to remember that principles remain the same across the frontend. We should use JS or TS with ES6 and above, apply SOLID principles, unit testing, separation of concerns, clean architectures, etc. Nowadays, most frontend developers know many libraries but lack principles, so any tool they choose may generate disposable code in the short term.
Great article.
Looking for 2 cents on which paradigm and approach I should take for my data intensive(100s of thousands rows in total) dashboard application with filter tables and many live charts/graphs that are user interactive and real time update from database and other sources.
Kindly suggest which approach is better for long term.
Fair point. Another fair point in favor of Svelte and the likes is the lack of need for larger ecosystems. Svelte is so close to vanilla JS that you don't need ports of neutral libraries.
No disrespect intended, but I don't see any other way to say this: Reasons like this are, to me, delusional. Why, o why would I stick to the loser?? Why should I punish myself into the older, slower and more complex of the tools? This reasoning, to me, has no logic or reason behind it. "Because I don't need a Ferrari, I'll opt in for the VW, even though the Ferrari is free". No shape or form in this line of thought, from my perspective.
Regarding OOP in Svelte, I just don't see it. Can you provide an example? Svelte is programmed as FP as React. I see no difference. I can't think of a single class you import from "svelte". All you import is functions:
onMount(),writable,fade(),animate(), etc. Surely some produces objects, but that's the case of React as well. So in short: Where's the OOP in Svelte you refer to?Can you show me? I'm interested in concrete examples. Nobody has ever been able to give them to me, despite asking easily half a dozen authors.
UPDATE
Oh, I forgot to ask this:
What's the point of the
<Suspense>component. Is it not React's way to provide an "easy" way for developers to show spinners and the likes of them while data becomes available or work is done, or more generally speaking, show an interim user interface while asynchronous tasks complete? If not, what's<Suspense>for?Oh my! User Oscar Luis Jimenez deleted his account!
The kind of loonies you see here talking things they have no idea about.
There's no need to trash-talk them. There's this certain kind of junior developer who thinks they know more than us seniors. After they cool down a bit, they might mature into actual developers themselves, so I appreciate him cooling down a bit.
Well, the comments seem to remain, so I guess the message serves as fair warning about some eloquently-yet-plain-wrong comments in the thread. I'll just shut up about it and will simply increase my counter:
I always found this claim dishonest. Svelte looks close to vanilla JS, but it is actually a separate language that merely looks similar, but works somewhat differently. The Svelte compiler not only handles the view, but also the reactive core.
Dishonest would be to say "it is vanilla JS". I don't see any hidden truth behind the word "close". It doesn't merely look similar, it is super similar, works almost identical, hence the word "close" instead of "is exactly".
You do know that useEffect does not work with arrays, right? There is an issue with dependency check, which is done by reference and any array mutations require custom callbacks. Either that or you need to introduce fake flags to trigger re-renders. Of course you can force re-renders manually, but this requires re-rendering of all sub-components, which might happen either way when updating an array and there is no actual way to create a predictable and consistent behavior which is a rabbit hole on its own. Actually it’s the main reason that lists are almost always and only iterated inside the templates and often require explicit reducers to eliminate side effects and unexpected behavior. And let’s not talk about render keys/indexes for lists that don’t have unique identifier… I am very puzzled that you are asking that questions and think that the size of the array is relevant. In a large and complex application you can easily experience these issues with array of two/three elements rendering a large (50+ elements) component tree.
Breaking it down into components doesn’t solve the problem that updating an array/table is slow and painful. You can put each cell, or heck even a character if you want into its own component…
Also if you ever used useContext hook you would know that breaking it down to components does nothing to prevent re-rendering half the DOM just because you updated one of the keys and used a reducer in the hidden footer… And what about AppRouter and Layouts, ouch… CSS/styling systems… Or debugging, hot reloads… If these problems are news to you than I seriously doubt your expertise. And that’s just the tip of the iceberg. Breaking down into smaller components does heck a lot of nothing to resolve these issues and is such a basic answer to a non-problem..
I like where Solid is heading, but SolidStart still sees a lot of churn (just released Beta 2.0), and my experience getting questions answered could have been much better. To Solid's credit, the Start site states,
This is spot-on advice, and I've found I'm more productive in React (using Remix) despite the many benefits SolidStart provides. Therefore, I'm sticking with React for now, and I will re-consider using SolidStart once it is past 1.0, the docs are updated and complete, and the ecosystem has become more fully developed.
Let's agree to disagree. You have your experiences, I have mine. If you managed to get Vue or Solid to scale badly (Svelte is a different case here, but that should be solved soon), I would really like to see what you did to get such a result. On the other hand, I have more than enough real-life experiences myself and from colleagues that show how React will have performance issues at scale and that you need to work around them. I'm not saying it's not possible, but it will slow down your development.
...that those benchmarks are optimized to a point that would not really be maintainable in a production application (actually, that applies to the other languages as well, so that evens the field a bit). That the React folks are implementing auto-memoization with their Forget compiler only shows that they understood that performance is an actual a problem with React.
Look, I'm not hating React. I will still happily use it at work five days a week, even though at the end of the day, 1-2 of these days will be used solving performance issues my junior devs left for me.
Preact has its own Signals for some time now, so leaner React-like lib with signals seems like another valid option if you are looking for React-Solid hybrid experience. Note that Preact Signals are not the same as Solid Signals, but the performance is similar.
I did some Preact widgets with API calls before, Preact version was way more smaller in size and had better performance than React version in POC, so we went with Preact. Can't talk about state management because we didn't need it for this one.
I know, sounds crazy. However, one can go through the entirety of lessons @ learn.svelte.dev in one day. Maybe a bit more if you're not familiar with UI state-driven frameworks, but I can't imagine it takes 4 days. I'd say 2 is the limit.
Vue Vapor is not a patch on top of patch… It’s Virtual DOM replacement. It’s basically applying the benefits of Solid.js to the Vue architecture. React doesn’t even currently support signals without breaking the existing hooks… How does React forget solve any of these problems? Please explain or share a link that does. I would love to learn about a real solution that we can apply in our projects and based on my current knowledge of React forget it ain’t it.
I don't follow "The higher the score, the better performance" here. It looks like the chart this references is showing TTI (time to interactive). Lower scores are better for that.
Great article. I love React.js but there are great alternatives that may be better suited to a particular project. Solid.js is definitely one of them.
There is now a new ReactJS state manager called "eagle eye context" which can very easily provide the same SolidJS level instant reactivity. Feel free to check that out when you get a chance.
github.com/webKrafters/eagleeye
It all depends. If you are building a high-performance web app with loads of real time data coming in and hundreds of components using pieces of that data, solid absolutely obliterates react — it’s not even in the same league.
What really gets you with react is all the components and their children re-rendering, and the diffing that goes with that. You can memoize and write careful effects to avoid the unnecessary cycles (and more importantly the needless memory allocations), but then at some point all those dependency checks and the tower of effects you had to write in order to tip-toe around react starts to add up.
In my experience, solid has an unquestionably superior DX simply due to being able to write JS like JS, and not having to constantly memoize and worry about what piece of state might trigger which components to re-render 40x a second. But then again, if I were building a typical web app, the difference would be minimal.
In reality, it’s all about use case and performance metrics will never tell the full story. If you know react, you know solid. Unless you’re using a thousand packages, making the switch to solid, or vice versa, is trivial.
Efficiency is not popularity
;o)This discussion is not complete, without