Most devs are of average talent and will hang themselves and everyone else with the stateful webs they weave. Even with careful PR reviews, these things have a way of sneaking in and becoming permanent hinderances.
Performance hasn't been a dealbreaker in most JS apps for years now. What HAS been a problem is getting good code out the door as fast as business needs. MOST React code is disposable based on the whims of the company. The bits that aren't disposable are used enough to justify having them designed and maintained by your best devs who should also have the skill to write performant code.
I know you're right; but this still deeply saddens me. I want well crafted software. I want the code I write and the code I depend on to be made in a way that holds reverence and honor for the craft of software engineering.
I don't want to be running crappy, badly performing javascript made by average talent in react, that exists to serve someone else's transient business needs. Gross.
He's not pearl clutching. He's in love with that car. He keeps it immaculate and he has a sparkle in his eye when he talks about it.
Some people are the same with furniture. They buy super expensive, custom stuff and look after it for decades. Not me! All through my 20s I didn't care at all and my various homes were full of cheap ikea furniture. I had bills that need to be paid, and why should I pay more? Most of it is probably in landfill by now.
I'm not an expensive furniture guy. And I'm not an expensive car guy - I don't even own a car. But I am into software. Software is kind of my thing. When software works fast and well, when its clean, reliable, tested and memory efficient - its the best. I know deep down everything is right in the world.
And, obviously, I hate disposable, cheaply made software. I hate when software runs slowly. I hate seeing my expensive computer working hard to do basically nothing because of lazy code. And I hate running into stupid, avoidable bugs. I don't want to create work like that. And I don't want to use with software like that. When software is laggy and unreliable, my skin crawls and I feel disgusting.
Intellectually, I recognize that there's a place for the cheap ikea furniture equivalent in software. But craftsmanship matters to me. And I personally, hate bad software and I don't want it on my computer.
Does that make me a pearl clutching, elitist snob? Sure, whatever. But I'm done acting like I'm sorry for what I like.
I think if you feel strongly about something you should defend it!
It makes it straightforward to reason about, because you aren't dealing with globals, undeclared deps etc. like in the Knockout days
Performance does matter to the people who depend on our products. Can we please stop throwing people under the bus in the name of churning out more crap?
I don't know, IME it's pretty easy to run into bottlenecks with React. To resolve these, you have to spend time optimizing data flow and preventing unnecessary re-renders, and it can be really difficult to trace where an update originally comes from. Svelte and other reactive frameworks give you good performance by default, so it's very unlikely you ever have to do this in the first place.
I never had to deal with `useMemo` and `useCallback` equivalents in Vue apps. The framework is implemented in such a way that it can let me focus on the task at hand. If I have errors in Vue apps, they are logic errors not "you didn't cater to the framework's rendering model" errors
Looking at the geomean benchmark suite everyone uses, it's 1.33 for Svelte 4 and 1.67 for React. That's a mere 0.2x difference and most of that is due to row swapping performance from React iterating lists of thousands of elements -- hardly typical in most apps.
Your team will make THOUSANDS of decisions in your app that will make WAY more difference than 20%. Incorrectly nest some loops in your data processors and the performance difference will almost instantly outshine the update differences.
And all of this is without mentioning that the React team is working on a compiler that will offer many of the benefits you get from the custom Svelte compiler (though TBH, I dislike needing a special compiler for custom JS).
EDIT: I'd also add that the Stage 2 record/tuple proposal will make comparing props many times cheaper and should give a massive performance boost to React as this comparison is one of the things that slows it down.
Now, I'll grant you that it really depends on the project. Building a simple admin interface? This probably won't matter. But for an interactive dashboard with dynamic charts and data being updated in realtime? You're almost certainly going to spend some time making it fast. And optimizing React code is currently a pretty poor experience.
For the record, I'm not arguing that the performance difference alone makes Svelte worth using over React. In fact, I think the developer experience with Svelte is far better, which is (in the majority of cases) a much better reason to use a framework. I just want to dispel this myth that React is so fast that you'll likely never have to think about performance, because I've had to do a non-trivial amount of optimization work on just about every React codebase I've worked on.
Performance was the main issue because one incorrect usage of a hook can make a huge difference.
Hooks are also very interesting, they're basically functions that run at specific times, or that is to say, they're `f(...parameters, state)`. They hold state inside the function, sort of like a closure.
Unfortunately, many React apps use Relay (another Meta product) and it opens up a world of “magic” that is sometimes a real pain to reason about.
https://github.com/coralproject/talk
I agree that Relay CAN be simple, but it isn't for what we do. Have a look at this ReplyListContainer and its nested Relay logic. I didn't originally write this, but I can see what they were trying to do and how Relay made it difficult for them. Your thoughts are welcome, I won't judge you for being critical of our code and welcome any other Relay dev's opinions.
https://github.com/coralproject/talk/blob/develop/client/src...
https://fe-tool.com/awesome-react-state-management
That's an article listing the top 18 state management libraries for React.
18?!?
React devs can't even agree on a common development model for state, but you think it's explicit and very easy to reason about?
Folks don't adopt utility libraries for things that were already easy to reason about on their own. I'm glad you've found peace with React's basic notion of state, but it's a far cry from optimal. And the "state ecosystem" of React is a dumpster fire. Layers upon layers of madness that acolytes peer through and proclaim insight.
> These rerenders can only happen down from where in the tree the state change happens.
Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness.
Despite there being so many, only a handful (redux toolkit, jotai, zustand recoil, and mobx) see much real-world use and they are basically just 3 approaches (reducers, signals, and directed graphs) with varying levels of complexity and features.
> Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness.
Not true. It only needs to diff the leaves of the part that changed and some of those sub-trees can be skipped too if they are functionally pure (or uses shouldComponentUpdate). This is how they reduce complexity down from O(n^3) to something generally closer to O(n)
Can you explain how all 3 state mechanisms you mentioned, and how they are different ?
I think the more glaring criticism is the lack of any unified component library. The amount of different Button implementations alone is astounding
The real kick to the shins is that React Server Components did a number on most component libraries, too. I've been forced to go to Tailwind (and DaisyUI, which is pretty nice) just so my stuff doesn't require 'use client' all over the place. The end result will be way better, it already is when you actually can get there, but right now it's annoying and awkward.
To be fair, context is not a state management tool [0], an article by acemarke, the Redux maintainer. It does work as a dependency injection tool and for many people, that's enough, but it's not a true state management tool.
[0] https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
> 18?!?
I mean, the top library has more weekly NPM downloads than every other library in the list combined.
> Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness.
That is not how rendering works in React.
Static analysis seems like a nice to have. All in all I class this category of concern as very far down the list of concerns, one way or two way. Yes bad things are possible. But the martial attitude that oh no people will do it wrong this tech is horrible is, in my view, actively harmful.
99.99999% of times it goes great. We don't need to make coding environments were bad things are impossible.
I'll disagree with you on that. I've seen and used enough 2-way binding in various projects to know that even the best of devs can create tangles of effects everywhere. At some point, you gotta blame the tool for having footguns, which is why Rust was created over C and C++, to solve such footguns. In the same vein, something like that should be made for frontend frameworks too.
And don't get me started on React's "put all the logic you want in our templating language that doesn't even target HTML5" elephant-footgun. Oh! Sorry! Forgot that React's footguns are aKeats elegant and reasonable while everything else's footguns are dealbreakers.
Sorry, but how is JSX a footgun? I have a lot of issues with React, but JSX doesn't even come close to making the list.
For Svelte as an "island" tool (i.e. for building islands of interactivity in otherwise static pages, like, say, graphs for the New York Times), that's not a problem, because the extra generated code is made up for by the lack of a bulky runtime dependency. But if you scale that up to complicated SPAs - which has been Vue's main stomping ground - you can end up shipping larger files with Svelte than with other small frameworks.
That said, SFCs in Vue are an ideal source for compile-time compilation, and my understanding is that they're heading more down the route of SolidJS. SolidJS has a similar goal of using a compile step for optimisation, but it leans on its signals library implementation much more heavily, which means the compiled code tends to be much smaller, but you also need to include a runtime. (In practice, there's not much size difference between Svelte and SolidJS at all, but it shows itself at the more extreme ends of very small components and very large apps.)
Vue already has a runtime that's very similar in some ways to Solid's (read: it's all signals, baby), so adopting the rendering ideas from there is an obvious next step. That should drastically speed up rendering, as well as reducing bundle sizes significantly. They've already demoed this a bit, but I think it's not fully released yet - they gave a name for the new system, but I've forgotten what it's called.
Looks like early experiments were called Vue 'vapor'
This is one of those things that's more of a problem in theory than in practice, but nevertheless it's worth mentioning that Svelte 5 output is _much_ smaller than Svelte 4 output.
I'm very impressed by this stuff - I'm still not sold on the implicit reactivity, but I'm really excited about the pressure this is putting on the ecosystem as a whole and where that's going to go.
It was a bit sad that it didn't get more popular and possibly improved. Some devs liked it but we were a minority compared to those who liked/used Redux.
One strange thing they did was to release a new "version" called Mobx State Tree which was very different. It had a great api but was different and slower.
> why React was made in the first place, to have only one way data binding and to re-render the entire page in a smart way
This last part is why Vue and now Svelte didn't adopt React's model. Yes, reactivity and two-way data binding give you enough rope to thoroughly hang yourself, but it also gives you a very explicit picture of how and when components will update. React, on the other hand, expects you to trust its smart algorithms, which definitely removes a lot of the pain from day-to-day coding but also makes troubleshooting performance problems harder.
I see the distinction as similar to GC languages vs something like Rust: if all you need is to have an app that does a job and you don't care about how it does it, React is a good choice. If you need to have control over exactly what will update and when, Vue's model gives you fine-grained control over updates that's hard to achieve in React.
EDIT: And with that in mind, it's obvious why Svelte, which prides itself on being lean and fast, would avoid the React smart-but-complicated runtime model in favor of the Vue model.