Note that I did a fairly extensive update to it in 2022 to cover React 18.
My current ongoing Redux maintenance task is trying to revamp our "Redux Essentials" tutorial to be TS-first. Making slower progress on that than I'd wanted, but hopefully can get that wrapped up in the not _too_ distant future.
Beyond that, we've got a ton of open RTK Query feature requests that I'd like to address later on this year.
React absolutely improved things from spaghetti jQuery. The zero-to-one productivity for interactive UIs goes through the roof, but growing and maintaining your project for any serious business use case is a complete nightmare.
I don't wish isometric javascript on any one. Javascript was infamously created in a week or whatever and now it's the browser standard, so be it, by why in god's name would you ever pick it for your server?
I burned myself out working on a personal project completely on my own using nextjs. I was super productive at the start, then as business logic increased... typing and flowing everything through components, state, reducers, selectors, async network calls, good God I grew to hate all of it.
I came crawling back to Rails. Everything and the kitchen sink is loaded in a controlled and blocking env. You can abuse the fuck out of it and it smiles at you. I'm sorry I left you Rails. (rails backend for all business logic: "the brain". Thin/dumb React JS client that consumes view-based APIs. React is great for interactive UIs. Not your fledgling business logic)
Web apps can reach the complexity of a desktop app with a GUI, a game, etc.
I say this as a mostly backend / systems engineer: there is an incredible wealth of complexity in the frontend. In user interaction, making and transforming API calls, and in UI/UX design.
the moment you have to keep track of any type of state, managing dozens of UI elements quickly becomes extremely tedious.
Actual React apps are as simple and elegant as a complex (web) application ever could be. Separating your app into functional components where most complexity is always local is a great way to make the application structure as simple as they can be. Where developers often go wrong, is trying to force patterns from other frameworks or languages into React and TS/JS.
I think if more people would do this exercise they would find that they don't need it, or at least that they might need some form of state reconciliation, but not enough to really warrant all the complexity the tool introduces. Some will find that they don't need it but will still use it for other reasons, like familiarity or because that's what their team uses.
If the developers have experience with other languages and native UI frameworks then they probably won't want to use any of the Javascript frameworks when developing a web application as they already have a mental model for how to setup the structure of function callbacks for handling user interactions and state changes.
This is exceedingly complex, error prone (because you might miss parts of the state that should change) and often slow (because you tend to overcorrect).
I then read it, and come out thinking "why, why, why do people put up with this absurdity?" and always stop at the same conclusion, cz they don't know any better.
I then quietly move on with my life, sometimes leaving such comments as hints to those who might catch on.
Like, they know how to do a simple HTTP query in C/go whatever, and then don’t understand why would you need the whole complexity of spring.
It just turns out that the real world is more complex than what they assume - and they are often more than aware of that in their specific subfield.
C++ always seems to me pretty absurd just because C++ people don't seem to know better ways, and seem to think to much about squeezing out the least little bit of performance instead of aiming for simple abstractions that are performant enough. Also, the last 40 years of programming language development seems to be unknown to them, or at least doesn't influence their decisions, or if they pick up a new idea, it's implemented in the most possible awkward way (because, again, performance).
Imagine a world where you just had drawing and input handling primitives on the web. You wouldn't invent the DOM and then something like React to wrangle it that's for damn sure.
For all of Reacts faults, it's not particularly absurd to use in practice and ultimately there's only one frontend/client language to work with.
Pretty much no one that uses React _loves_ it. But we all use it because it gets the job done.
Sprinkle it a bit with some simple JavaScript/jQuery code for animations, forms checking etc, if you want. That's it. That's how it was supposed to work and that's how it works best. JavaScript was made to make the monkey dance. The end result, either made with overcomplicates frameworks like React/Angular or with simply generating the web page on the backend, is irrelevant to the user.
Everything in that post should still be 100% accurate and relevant.
I specifically did _not_ try to go into further details on Suspense or some of the intricacies of Concurrent Rendering (beyond "React can cancel or reset those render passes"). My overall goal was to explain the core mental model of how React's basic rendering works on the client side.
As far as Suspense goes, that can be summarized as "throw a promise while rendering, `<Suspense>` acts like a `try/catch` at the component level, React will re-render this component when the promise resolves and from its perspective that function call _always_ returned the data synchronously".
Concurrent Rendering is really complicated internally, but loosely: React has an internal notion of priorities for queued renders. `startTransition`, `useDeferredValue`, and Suspense all mark renders as low priority, so those render passes can be "rebased", interrupted, or canceled as needed based on updates that come in later.
I have https://github.com/ryansolid/mobx-jsx/?tab=readme-ov-file#mo... on my list to try since I -really- like mobx for stage management (especially mobx-keystone) and am fascinated by how clean the results can be.
Though for 'real' code I still tend to default to react + mobx-keystone because for all my gripes with react it's a pretty solid Schelling Point.
- https://react.dev/blog/2024/02/15/react-labs-what-we-have-be...
That said, React Compiler will _depend_ on React 19, because it needs a new memo/caching hook that will be included in 19.
