DEV Community

Discussion on: Stop Using React

 
leob profile image
leob

I agree ...

If your React app is slow then you're probably doing it wrong (unnecessary re-renders etc).

And the bundle size of a React app doesn't have to be huge (use code splitting or SSR, and Preact is also an option) ... Angular is heavier I think, I don't have that much trust in those numbers, especially without sources or references.

And if React is horrible, is Vue or Svelte then also horrible? Or, if they aren't horrible, then why is only React horrible? More questions than answers ... :-)

Thread Thread
 
bajix profile image
Thomas Sieverding

React apps are slow because of the time complexity of VDOM. If you use for instance CanJS which has change-propagation based rendering this is substantially faster than React.

Thread Thread
 
leob profile image
leob

Funny because from the very beginning we always heard "React is fast (and small), VDOM is fast, and a good thing", and so on.

So how come it's now suddenly "slow" ? The answer is of course "relatively" speaking :-)

For 99% of ordinary use cases "React is slow" is a purely academic statement, we're talking about milliseconds. I imagine that only in some rare edge cases (lists with thousands of items?) would it be 'slow'.

I think it's mainly an academic issue, and of course you need to weigh that against the advantages of React (and against the other disadvantages, haha).

Thread Thread
 
bajix profile image
Thomas Sieverding

VDOM is only fast when compared to alternatives that are incapable of efficient DOM patching. When you compare the performance of VDOM to that of change-propagation based rendering, then suddenly VDOM falls flat on it's face. The time complexity difference between these two approaches is actually quite staggering; these are not minor millisecond differences, these are staggering performance differences. Say for instance you refresh data after an SSR call and want to reconcile any changes from the cached data that was printed to the page vs the live API data; in observable land only attributes that have actually changed result in change events, and it can be known by the data changes what parts of the DOM tree need to be re-rendered and how. If you shuffle a list and replace it when new data, that just shuffles around DOM nodes without any further overhead even if the source data is entirely new. The DOM changes are propagated from the data changes instead of deriving this from a VDOM diff and patching. It is vastly more performant, and much easier to reason about.

As far as the rest of React goes, the only thing that it really has going for it is the cult following it has. This whole notion that it makes apps simpler or enables more sophisticated SPA's is utter bullshit. Going all in on observables and using a proper observable implementation such as what CanJS has actually results in far simple applications that are much easier to reason about, that perform much better, that are much more succinct and above all else it makes it much easier to compose complex behavior that scales well.

I believe it's the case that you simply haven't seen how incredible well written observable-driven SPA's can be. If you had, you would know how bad React's shit stank. The juxtaposition is incredibly stark even if you entirely dismiss any performance factor. I say this all as someone who's built a prolific amount both in CanJS and in React and by combining the two (MobX is trash observables!). I would very much so love for React to be a better framework, but alas not being observable driven is an insurmountable design flaw that can never be reconciled. It is a cult choice that fundamentally lacks technical merit

Thread Thread
 
leob profile image
leob • Edited

Well maybe it's a matter of the state of the art having evolved and progressed so that VDOM, which was once our hero, is no longer the holy grail. But, my hunch is that for 95% of the apps and use cases the performance difference is probably negligible, i.e. it doesn't matter much.

If (for the majority of use cases) React was that awful and CanJS that superior, then how come that not everyone recognizes this apparently obvious fact? I believe you when you say that observables are a technically better solution, but probably not that much better in the majority of cases. If it's that obvious, and the difference is that huge, then for sure people would know about it by now?

My own criticism of React is quite different, namely that it's putting a lot of the burden of doing it "right" on the developer, hence the endless avalanche of complicated "patterns" - first HOCs and render props, now "hooks", and so on and so on - all of which must be mastered and applied correctly in order to build well-structured and performant React apps. If you do it wrong then you get performance problems (i.e. unnecessary re-renders) - so unlike for instance Vue, which has a lot more 'intelligence' built in, React is putting a lot of that burden on the developer.

Other example: Vue has things like routing and state management "built in" making it much more complete 'out of the box' - React lets devs grapple endlessly with iteration upon iteration of routing solutions and an infinite number of "alternatives" ... I don't want to mess around ad nauseam with alternative routing and state management libs, I just want to build an app!

React has become something of dark voodoo science and makes you jump through hoops for the sake of it, instead of it just being a tool that makes your life easier by keeping simple things easy and providing you with the tools you need (like Vue or Svelte).

But I digress ... the big payoff of mastering React is that it's used in a gazillion projects, has a huge community and ecosystem, and totally dominates the job market. Just that might be more than enough of a reason to go with it.

P.S. I could be wrong but I think that VueJS is also observable-based (although it uses VDOM as well). It's more intelligent about re-rendering, while React, as said, forces the developer to be aware of unnecessary re-renders. By the way, do you have an opinion about Svelte?

Thread Thread
 
ca0v profile image
Corey Alix

I just started going through the Svelte tutorial at svelte.dev/tutorial and it is blowing my mind. Declarative and unbelievably responsive. Genius.

Thread Thread
 
leob profile image
leob

Fantastic, and I look at this this (from the Svelte site):

"You can build your entire app with Svelte, or you can add it incrementally to an existing codebase. You can also ship components as standalone packages that work anywhere, without the overhead of a dependency on a conventional framework"

Thread Thread
 
bajix profile image
Thomas Sieverding

Yea after reviewing Svelte I would say it looks like a really great library. They are actually doing change-propagation based rendering here similarly to how CanJS works, which as I contend is vastly better than VDOM from a time-complexity perspective.

Also, regarding Yew & Seed; those just stand out as being promising libraries that are propped up by the unique strengths of Rust, but I would say they still leave quite a bit wanting. I think it's worth taking a second here to highlight Mogwai; as far as I'm aware, there is no frontend project in existence with a better rendering model, and their approach is perhaps the only approach faster than change-propagation based rendering. It's like 15x faster than React, and by virtue of it being entirely in WASM there's no JS parsing overhead. I'm fairly confident in saying that there is no framework technically capable of faster time-to-render than that of Mogwai

Thread Thread
 
leob profile image
leob

Cool, but you have to understand the use cases for which this makes a substantial/perceivable difference. For a large class of apps you won't really notice any difference, your screen would render in 0.05 seconds rather than in 0.1 seconds, if I may put it that way.

I'm not saying that there's no point in technical progress (there is, absolutely) but for most React projects it would probably be a bad idea to say "we got this new and faster framework here, let's rewrite our app from scratch".

Even for greenfield projects you might still choose React rather than Svelte or Yew simply because of the large number of devs who know it, and the because of the vastly larger community and ecosystem (answers on Stackoverflow, huge number of ready-made solutions/components/tools etcetera).

It also depends on your team of course, how technically competent are they, do they know Rust or WASM, and so on.

The point I just want to make is, when choosing a tech stack for a project you're normally looking at much more than sheer technical superiority.

Thread Thread
 
bajix profile image
Thomas Sieverding

You’re completely understating the performance differences. It’s more like going from 3000ms-400ms to 300ms-25ms; that’s a massive difference, which will have a major impact on user interaction. Furthermore, the initial time to first render is substantially affected by the parsing time when loading JS, whereas WASM compiles as it’s downloading and is ready immediately. Finally, a WASM app can be server side rendered by an edge working, allowing for low latency edge computing that’s both economical and scalable. These aren’t minor performance differences.

In any case, I definitely agree with your sentiment on why React is successful; it’s an 800lb gorilla, it’s safe, there’s a lot of resources to google your way out of a rabbit hole, there’s a lot out there to guide those in need of guidance, and there’s a lot of devs by virtue of boot camps etc.

In any case, I think it’s still worth learning things like Rust WASM / Mogwai / Yew because if you actually do know how to use these things and can build apps end to end yourself it’s a way to take on major tech players. If you're going to compete with an major tech company, you sort of need to go big

Thread Thread
 
leob profile image
leob

I'll definitely keep it in mind ... BTW Rust is brilliant :-)

Thread Thread
 
bajix profile image
Thomas Sieverding

Right!? I know more than a dozen programming languages, but all of them left so much wanting; Rust is truly the only language that left me in awe of its' brilliance. Lately I've been porting all of my NodeJS work over to Rust and I foresee it as being the sole backend language that I write in going forward. It's super empowering all you can do it with it: so far I've used it for GraphQL API development, lamda functions (13mb peak RAM, <5ms response from cold start mindblown), Redis Native Module development, EOS smart contacts, Holochain DAPPs, extending Postgres, creating NodeJS modules via WASM-bindgen and I feel like I'm only really scratching the surface here. I'm not sure how well you know Redis, but doing redis native modules via github.com/RedisLabsModules/redism... is actually a complete game changer and is applicable for so many use cases. I've never been so excited by a language

Thread Thread
 
leob profile image
leob

Great to hear ... put more of that stuff up on your Github? github.com/Bajix

Thread Thread
 
bajix profile image
Thomas Sieverding

It's all closed source. I don't do open source projects on the side anymore; instead I build companies, solo-author apps, and patent new inventions. Right now my most pressing priority is stopping coronavirus, and everything else takes lesser priority. This project I've been financing & working on with my dad for the past 7 years and we're trying to get this onto the market ASAP: youtube.com/watch?v=MuHWW-25mBw

Thread Thread
 
leob profile image
leob

Cool, understood ... nice, you're an innovator inventing stuff, we need more of those :-)

Some comments have been hidden by the post's author - find out more