Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app. Most of us deal with average teams where half the devs are at or below par while managing very tight deadlines. The spaghetti from everything in the whole system mutating always comes back to bite.
You call signals an "implementation detail", but if someone doesn't know that's what they are, then they'll wind up doing very bad things. This means they either aren't just an implementation detail or they are a hyper-leaky abstraction.
What I mean by 'implementation detail' is that you _literally can't get a reference to a signal_ in Svelte 5. This alone prevents people from mutating things in unexpected ways.
> Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app.
Yes, but having gone through this at previous companies, the average/non-front end specialist developers definitely had an easier time understanding 2 way binding ala Knockout, MobX, Svelte, etc. The Redux style stuff was only pushed by the frontend brainiac types.
Pretext: I'm a backend developer that often needs to stare into the abyss that is frontend.
I used to say these same things about reactivity. It was highly confusing to me years ago; as a backend developer doing frontend tasks was always reaching outside of my cookie jar and testing the boundaries of what I knew vs what I thought I knew. Many headaches ensued. That said, using Vue 3 and Svelte 4 has made utilizing stores and reactivity a lot more obvious in my opinion. Things render when they're supposed to and my applications remain performant. As a non-frontend person, I mainly like the APIs that Vue and Svelte bring. In React I'm almost always switching to class based components for what I can do in the compositional API in Vue or what's natively possible in Svelte. That brings a lot of repeated code and doesn't look as clear to people not as familiar with React.
Seems like your comment cut off there, but if you're using class components in React, there will be repeated code, yes, which is why hooks were invented and why they enable you to reuse such code.
I’m referring to the dependency array you pass into hooks, and any hook being able to trigger updates.
With classes there was no manual dependency tracking (except comparing old props?) and all re-renders were triggered by state, context or prop changes.
Not making a judgement either way, just stating the trade-offs.
The dependency array strikes me as far safer and more reliable, but it has been a bit of a foot gun for a lot of people. I still encounter code where dependencies are missing, which virtually never makes sense or should be intentional. I suppose the compilation step that’s proposed would address that, but it’s yet to be seen.
There does seem to be an aspect to modern react where it’s great if you’re willing to put in the effort to figure out all the quirks, but for everyone else who just wants to get things done/has other priorities, it’s a bit of a minefield at times.
You call signals an "implementation detail", but if someone doesn't know that's what they are, then they'll wind up doing very bad things. This means they either aren't just an implementation detail or they are a hyper-leaky abstraction.