That behaviour is on you

Things get complicated once you’re signalling updates upward through context because the render cascades and you end up chasing an update that arrives seconds late.

The interesting question is whether that’s the framework’s fault and it mostly isn’t. If a child signals to a parent that state has changed, you should always expect that to cascade down the tree, and expect that cascade to cause further updates and further renders. That’s what the words mean. A framework that quietly decided not to propagate some of those updates would be doing something far stranger and far harder to reason about than the thing being complained about.

So the behaviour is on you. Not as a scolding but as an accurate description of where the decision was made because the shape of that cascade came from how the components were arranged and where the state was put.

This is the part of the argument about React that I think gets misplaced and it applies to most frameworks equally. People expect too much of them. If you hand over all of your judgement to the framework and assume it’ll work regardless of what design you throw at it, you’ll build a bad application and it won’t be because the framework let you down.

You still have to think things through. You still have to use your skills, understand what’s happening underneath and know why it’s happening. That’s always been true and it’s going to stay true through every generation of these tools because the thing being automated is the mechanics rather than the decisions. Nobody has built anything that removes the requirement to put the work in and the tools that claim to are usually moving the work somewhere less visible.

There’s a second thing in these complaints worth separating out. The feeling of being trapped, where your last job and your current one and probably your next one are all built on the same framework so you’re stuck with it whether it suits you or not.

That isn’t true unless you decide it is. It’s true right now which is different. If you put effort into learning other things and then look for roles that use them, options open up and that’s a process measured in months rather than a door that’s been locked. It takes real work and it can mean a step sideways or a pay cut for a while and it’s available.

You could also leave web development entirely, which people do, and find that a decade of knowing how state and rendering and network calls interact transfers further than expected. The framework you happen to know is the least portable thing you’ve learned. Everything underneath it goes with you.

Feeling stuck is worth taking seriously as a signal. It’s just usually a signal about what you’ve been prioritising rather than about what’s available.

The frameworks that survive tend to be the ones that are honest about this rather than the ones promising to think for you. A tool that does exactly what you told it, predictably, is more useful over a decade than one that guesses well most of the time, because you can build a model of the first one in your head and the second one will eventually guess wrong somewhere you can’t see.

What makes the trapped feeling worth taking seriously anyway is that it’s usually accurate about the last few years even when it’s wrong about the next few. If three jobs in a row have all been the same stack, something in how you’re choosing roles is producing that, and noticing the pattern is more useful than blaming whichever framework happened to be popular.