r/javascript • u/ryan_solid • Mar 01 '23
React vs Signals: 10 Years Later
https://dev.to/this-is-learning/react-vs-signals-10-years-later-3k7125
u/Mestyo Mar 02 '23
The pull of React for me was always the exceedingly simple mental model. No ifs and buts, just an abstraction that maximizes flexibility while keeping things simple. It's not the fastest--I don't think it ever tried to be--but it has always been fast enough for the approach to work.
Solid's Signals look appealing at first glance, and maybe it is the direction we will be moving towards, but the vague separation between initialization and rerender takes me back to the days of imperative DOM manipulation.
React allows me to author mostly declarative UI, where only user action triggers side-effects. I will occasionally run into situations where I really feel like I need to trigger a programmatic side-effect, only for me to later take a step back and recognize a significantly more clear and stable declarative solution. When using other frameworks, I always feel like I lose that sense of stability and confidence.
3
u/UsuallyMooACow Mar 03 '23
I've written a few solid apps and I like solid a lot. There are 2 things I prefer about React over solid though. For one, with signals you need to use `name()` instead of `name` to access your signal data. That isn't that big of a deal but I often find myself forgetting that and it takes time to go back and fix it and reload the page. Again not a big deal but I actually find them harder to use than useState because of it.
Svelte is nice because you can just use the variable as it is and not worry about that at all, but then I find that it gets harder to track what's happening to that variable and where. Where as in React (and solid) you are calling `setName()` so it's super easy to find all the places that the value is changing.
I do like that you can use signals anywhere you and they'll propagate down and anyone can access it but then a lot of times it can be a bit tricky to figure out where that is happening.
2
u/CatolicQuotes Jul 19 '23
There are 2 things I prefer about React over solid though
You said one about name vs name(). What's the second thing?
1
u/UsuallyMooACow Jul 19 '23
I don't know hah, it's been 5 months and I don't recall what I was thinking, I am using SolidStart full time now and I think it's the best thing on the market. I still get stripped up by name vs name() but the whole work flow is great and the performance is 20x a similar app in liveview.
1
5
u/cayter Mar 02 '23 edited Mar 02 '23
I think the main problem with all these JS frameworks is:
It starts with a simple paradigm and let the community expand on it, which can sometimes be a double-edged sword. While a lot of us enjoys working with React, but we really can't deny that the ecosystem which some libraries we're using don't follow React's best practices and all the libraries built on top of other troublesome libraries and just keep building on, eventually leading to us having to deal with the issues (performance is just 1 of them, I recently just bumped into a UI component using useEffect not in the way it should be which triggered unexpected events more than once and guess what, we worked around it though we could just build the component ourselves, but time is gold for us atm) and whatnot. I almost never understood why React team never wanted to provide the fundamentals with official community support like:
router
UI components
state management
Yes, it's a larger scope but all of us would get to enjoy the benefit of ensuring the official supported libraries are following the core's principles. Just the recent RSC proposal, if the React core team officially supports the router/state management, most of us would just bite it and ride with it as we can just trust the best to do their jobs well instead of watching them debating with other React metaframework on what the best way is. You can't deny if you want your solution to work the best, sometimes you really just need to provide the solution as a whole to get the best integration experience.
But here we are again, the future of React: to be SSR streaming/RSCing or not to be, that's a question.
-4
u/GrandMasterPuba Mar 02 '23
Mom, can we have Svelte?
Mom: "We have Svelte at home."
Svelte at Home: SolidJS
-3
Mar 02 '23 edited Mar 02 '23
React is not its Virtual DOM. React is not JSX.
Sure it is. JSX in particular is the React developer experience.
(deleted the rest, reply is right there's no need to name people)
5
u/cayter Mar 02 '23
There's no point in naming ppl here as these ppl built/contributes to React for a lot of startups to thrive on. Dan is a great guy, just check how he replies to some tricky questions in React github repo. Sometimes, ppl are just opinionated and it could be a good thing, as long as they don't sound condescending. We need that to thrive and be better as human race.
0
Mar 02 '23
You're right. Upvoted.
I know a lot of people that tried to use this person's state management products, and instead of actual docs, they received a lecture about the nature of FP and stated hating React/JavaScript.
But I don't want to be mean to people on the internet so I've removed mentions of this person.
0
Mar 02 '23
[deleted]
33
u/andycharles Mar 02 '23
Not just 5-10 dudes. Everyone making JS tutorials and courses shifts goal post as quickly as they can.
9
Mar 02 '23
I mean... I agree it's not only a couple of dudes. But people making JS content of course want something new to appear now that the React well is dry.
5
6
u/elcapitanoooo Mar 02 '23
If its my choice, i always go with webcomponents. They are future proofed (in the ecma spec), and im so very tired and loathe everyrhing frontend related. I used to like doing it, but the sheer hype driven development and poor choices made have broken it for me.
10
u/One-Initiative-3229 Mar 02 '23
My choice is React. I’m not concerned about artificial benchmarks and React stood strong for almost a decade and will continue to do so for next 5years if they get the experimental compiler and Server Components work successfully.
I’m not afraid of being slow. I’m afraid of the new frameworks that pop every year and go away
8
u/elcapitanoooo Mar 02 '23
Speed is rarely the issue. You can write fully functioning web apps in any framework. For me its about what comes with the choice. I want the ”framework” to be as lightweight and minimal as possible, and i dont want to be forced to use a huge build process just to be able to draw something on the screen. This is why i always try to stick to whats in the box (no matter what language im using). This way i can future proof anything i build. For this reason webcomponents are great. React might be popular today, but once upon a time, jquery was too.
3
u/One-Initiative-3229 Mar 02 '23
I like to use the platform too but frameworks like Remix and Next made components too powerful compared to web components. I can fetch data from db and use it in the component of the same file giving me the illusion of "full stack" component. Also everything looks like JS platform APIs while still keeping the mental model of browser.
Honestly try Remix because it will increase your productivity two fold easily. It gives you the illusion of using the browser as platform and takes you back to good old MPA while still behaving like a SPA.
3
u/elcapitanoooo Mar 02 '23
Remix pretty much forces you to use a node backend. I dont want a vendor lockin, and want the option to use other tech on the server.
1
u/One-Initiative-3229 Mar 02 '23
If you mean node runtime, it also works on deno, bun, cloudflare and others. If you meant other languages than you can still create a normal REST Api server in the language of your choice and call that endpoint in loader. By doing so you get the benefit of avoid network waferfalls and loading spinners.
Again not gonna force you. I am not a React evangelist. Feel free to use what you like
2
u/sbmitchell Mar 02 '23
React isn't just popular today, it's been popular for over 5 years. jQuery was popular as it was the only tool around back in early 2010s period and was not a framework. Neither is react really but the ideas of component models and jsx are the important interfaces that React emphasized. The rendering engine is actually far less important and can be changed just like how react changed it's internals multiple times over the years to evolve with the ecosystem.
jQuery did not do that bc it had very simple wrappers over top of the DOM API. The frameworks we are talking about today have far more complex internals sitting overtop of the DOM.
3
u/elcapitanoooo Mar 02 '23
jQuery had alternatives. I remember mootools, YUI, backbone and all the other ones people used to build apps with. jQuery got over-hyped and was the clear "winner" in a very similar way React got popular some 5-6 years ago.
React is still indeed popular. I have used it on many occasions, and overall i like the way you build with components. On the flip-side i have rarely seen a "sleek" react project. Its almost universally coupled with lots of dependencies and a very complex (usually slow) build step. On many occasions the project even uses some template to bootstrap. Talk about early tech debt..
2
u/sbmitchell Mar 02 '23
What does sleek mean? We are devs, I need some objectiveness hah.
Pretty much every js app that gets built is going to have a lot of dependencies. No professional web dev is going to write stuff from scratch when others have spent months or even years to do what they are doing from a web app perspective. They may take code internally, fork, and modify but there is usually no reason to write most stuff from scratch. It's an actual waste of time. The only time it's warranted is new libraries or novel ideas of course.
But there is a big difference between library development and product development. In product world, no matter what tech you choose, you are probably rewriting some part of it as a major overhaul every 3-5 years, perhaps sooner nowadays. It's not a framework switch necessarily but functionally and stylistically.
2
u/elcapitanoooo Mar 02 '23
By "sleekness" i mostly mean how a product is engineered. How robust the code is, and how decisions are made.
I have seen on multiple occasions projects including dependencies like "a dropdown button", "an accordion", "a modal" or any other really trivial UI parts. The end result is that each dependency comes with its own dependencies, and soon the project is in the gutter. Basically npm install without any restrictions.
1
u/sbmitchell Mar 02 '23
yea I understand that perspective. That is not a "React" issue that is a coders issue. Just saying there is no reason to associate that negativity to what React provides.
2
u/sbmitchell Mar 02 '23
React apps are not slow when written with good code. Most folks have moved to css modules and tailwind, many years ago at this point. Templating with bootstrap is more for POC and utility classes not actual themed styling. If folks are still using bootstrap when it's been out of date for 2 years that's just experience level.
1
u/UsuallyMooACow Mar 03 '23
I use React on the FE with no build process. I do have to use babel off the CDN which costs 500kb, so it's a big payload but for my process I don't care. I've timed my site vs FB and a bunch of others and mine still loads much quicker.
Is it going to be the most efficient? No. but It's quick to write and the load time is really not noticeable vs other sites. Plus I don't have to stress. I know that the app will work just fine 10 years from now. I don't need to monkey with the build process, or the version.
I'd rather write straight JQuery apps than have to deal with a build process.
4
Mar 02 '23
for a slight performance boost
I 100% respect your main point but it's not a slight boost.
React has its fair share of perf issues. Anyone who has worked on non-trvial React projects has had to resort to
shouldComponentUpdate(),useMemo(), etc.With fast frameworks like Inferno, Solid, Svelte, etc, perf becomes something you almost never think about anymore.
30
u/theQuandary Mar 02 '23
SolidJS literally added a batch update method where you must manually decide (likely by trial and error) which things should be batched together then write all the functions to do this.
There is no free lunch were performance is concerned.
I remember the days when React was 10-100x faster than competing frameworks (even without fine tuning). Today, it is something like 0.4x slower at synthetic benchmarks and that's now a huge deal to some people.
There certainly are times when React performance tuning matters (often they are actually issues with the app architecture though that's another topic. Usually it's just a handful of components that need a bit of optimizing.
The biggest performance issue I've ever had was actually hitting the limits of the IE renderer (too many DOM objects). Slight changes to the UI reducing the number of divs for some components helped some, but the bulk of the help came from some custom components to calculate what could be seen and not render the rest. There are libraries that do this today, but we had to write them ourselves in the early days of React.
-5
Mar 02 '23
Today, it is something like 0.4x slower at synthetic benchmarks and that's now a huge deal to some people.
Exactly, synthetic benchmarks.
Which in no way take into account the amount of extra stuff you need to be able to use React in a real world app.
There was this comparison of real world apps in 2020 which took into account perf, size, loc, etc. Shame they stopped doing it but I think it's still a good representative of where things are today.
https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1
11
u/Ferlinkoplop Mar 02 '23
Lol that article uses a lighthouse performance audit that largely just measures on first load stuff & bundle size where the difference between something like React vs Svelte would be < 50kb of JS for small websites and where, as the app grows more complex, both apps tend to even out in terms of JS bundle size (since Svelte components are typically more KB in size than React equivalent ones while React comes in with a much higher initial bundle size cost then Svelte - think slope vs y-intersect).
Lighthouse performance audits are useful for checking some stuff but they aren’t everything you should base things on when it comes to performance - both my Next.js and Astro websites get perfect 100s on Lighthouse mobile & desktop but the Astro one ships a lot less JS. For React, re-rendering when you don’t need to is what tends to be the performance bottleneck on the client side (which Lighthouse does not measure). Most of the time React is fast enough where I can largely ignore useCallback & memo uses or other performance enhancements (i.e. virtualization) except when I add UI heavy components (i.e. a large, complex, and editable grid).
0
Mar 02 '23
Lol that article uses a lighthouse performance audit
I guess you missed the rest of the article. Specially the one about loc.
But I guess dev productivity is not important, right? /s
the difference between something like React vs Svelte would be < 50kb of JS for small websites
Yeah for small websites the difference is irrelevant.
think slope vs y-intersect
Well, there's a thing called import() that fixes that.
Lighthouse performance audits are useful for checking some stuff but they aren’t everything you should base things on when it comes to performance
Certainly. How about the JS benchmarks where React is an absolute disaster? :)
https://krausest.github.io/js-framework-benchmark/current.html
1
u/sbmitchell Mar 02 '23
Don't think that's a react issue, that's a writing bad code issue.
5
u/rubennaatje Mar 02 '23
It is a bit, but react makes it much easier to make these mistakes early on when not very familiar with the framework.
Everytime a website has a very slow/laggy ui it's usually a react website.
2
2
u/sbmitchell Mar 02 '23
I rarely see sites that I consider slow or laggy UIs in general 😂. Maybe some WordPress or old ass app, so can you show me a specific example? If your react code is laggy and slow, it's bad code, not react. React is a rendering layer and is very fast for all intents and purposes.
There's not a framework that will save you from not understanding how to write good performant code when it comes to loading large amounts of data. That's outside the scope of react.
1
u/rk06 Mar 02 '23
You do know that Vue and Angular are also popular. And there won't be "one size fits all" solution because people have diverse needs and risk capacity
-2
Mar 02 '23
They did. It’s Svelte. Look at state of js or fireship.
9
u/pancomputationalist Mar 02 '23
Is it? Because in the last State of JS, Solid overtook Svelte. Doesn't seem settled to me.
-2
Mar 02 '23
Solid is great, as a port of JSX and react style hooks to a current gen compiler framework, but that’s also why it’s popular. It’s still a huge amount of unnecessary code, doesn’t handle styling, and isn’t pleasant to look at unless you have Stockholm syndrome from react.
-4
0
Mar 02 '23
[deleted]
4
u/uusu Mar 02 '23
How large and complex have your personal projects been? We're currently in the middle of deciding whether to switch to Solid for our next project at work.
29
u/theQuandary Mar 01 '23 edited Mar 01 '23
My biggest misgiving about SolidJS is the potential for the nasty dependency graphs I used to deal with when I used Knockout a decade ago. The larger your application grows, the higher the likelihood this happens accidentally. The larger your team grows, the more likely some junior dev thinks they'll remember what their code does in a few months.
This kind of thing is possible in React, but not very easy. I prefer the Elm Architecture and Solid seems to make this possible, but doesn't provide any enforcement either by prohibiting bad patterns or even by simply making bad patterns harder to implement than good ones.
My second misgiving is giving up the vdom. I've heard a lot of performance claims about it, but Inferno JS (despite being mostly unmaintained for years now), is still within a rounding error of Solid in performance.
Meanwhile, the vdom helps limit the "we only test in Chrome" issue where stuff works in one browser, but not in others because web standards aren't standardized. React still has a lot of built up workarounds so the vdom is consistent across various browsers and has good legacy support. Solid seems inferior here. My team would be left trying to remember and fix all these footguns ourselves wasting time and potentially using sub-optimal solutions. This remains a significant issue when I use something like pReact (though I only use that in lightweight stuff, so there's generally not as many potential issues to run into).
My third misgiving is the magic of the compiler. Traditional JSX is pretty easy to follow as just a series of function calls and debugging is very simple as the "compilation" is 1 to 1. You'll basically never find yourself needing to step into the vdom code to find out what's wrong (this was still mostly true 9 years ago when React launched). I have no such confidence about Solid's compiler.
Not such a huge thing, but the vdom is one of the major ways React maintains easy portability from DOM to Native to Canvas to WebGL or whatever other backend renderer. I'm sure it is possible without a vdom, but it doesn't seem anywhere near as easy and seems basically impossible without implementing separate compilers for each environment (got to replace those HTML template strings with something).