Not at this time. I'm pretty full up at this point with day job ( https://replay.io ), conferences, and personal life stuff.
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.
Not a critic to the article itself, in fact I know nothing about React and learned a lot from the it, but...do we REALLY need all of this to render web pages? Even if it is a web application and not just a page, doesn't this ecosystem seem too complicated for the problem it solves?
I made my career on open source web technologies before both GitHub and Stackoverflow were a thing. I love the web! And I love making UIs and I can spend untold hours with CSS even! And I agree the state of frontend is completely bonkers.
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)
Spaghetti jQuery has become the boogie man to peddle the ridiculously overcomplicated solutions like React or Angular. Which, ironically, also have got spaghetti, but in a different form.
React by itself is not "overcomplicated", or even "complex" at all.
The majority of the complexity is in the ancillary tools and ecosystem extras, which are not strictly necessary. You don't need bundlers and transpilers, for example. The only reason they are popular is because JSX is a good convenience, though.
You can get away with very basic React for the majority of cases. Things like advanced lifecycle shenanigans are also not necessary, unless you’re doing something extra-smart, or inherently complex (due to browser APIs, third-party APIs, or just complex design patterns). But those are also not necessary: just nip complexity in the bud if possible, but if something becomes impossible to avoid, the complex side of React will have your back.
The main difference between jQuery and React-the-library is that React handles a lot of the complexity around state and component abstraction all by itself.
With jQuery the complexity and spaghetti appears much earlier than in React. It's even difficult to compare, it is much simpler to keep a React codebase cleaner than a jQuery one.
Of course, if your app is simple enough, you don't need the "extra complexity" brought in by React, and jQuery will serve you well.
But this is also true even for "simpler things" like jQuery and Ajax: if your app is simple enough, you don't need Javascript at all, you can handle 100% with server rendering. And so on.
Nope we don’t, but it solves a lot of the problems people frequently encounter while building web pages without too much of a downside. It’s a big trade off space and react sits in a very nice spot in that space.
Phenomenal answer. No, you don't need it, but if you build something long enough you'll avoid a couple categories of common problems by starting with it (and choose a different set of common problems)
I like to think about framework choices as choosing which kind of problems you are okay with experiencing. This choice can be made from a product perspective much easier
These aren't just web pages. They're full applications with robust, rich state.
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.
so long as browsers don't have a great way to be stateful, and tie that state to markup, then there will be a couple of major frameworks trying to square that circle.
the moment you have to keep track of any type of state, managing dozens of UI elements quickly becomes extremely tedious.
You don’t really need to know the majority of what’s in this article to make good apps with React. It goes in-depth into how the framework works. Any framework will look complicated when you look under its hood; it’s meant to make everything possible after all.
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.
The thing about looking under the hood into the complexity of the tool you're using is that is can make you consider my initial question in this thread: Do I REALLY need all of this for my use case?
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.
It isn't needed. Teams could develop complex web applications before React existed and they can still do so.
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.
The problem with using the DOM or similar UI frameworks is that you have to code the delta from any state to any state by hand.
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).
It does require a lot of thinking before hand about the user interactions and their impact on the application state, user workflows, etc. However that thinking should already be happening regardless of the choice of implementing technology (granted it doesn't in a lot of cases :| )
The problem seems to be that the fundamental abstractions in web (HTML and the DOM) are not suited to modern web apps. This much complexity around state management shouldn't be needed.
ya'know, everytime there's a post with react in the title, I open it with the best positive attitude I can muster, holding back my knee jerk reaction.
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.
It's the same thing with every technology for me. C++ is pretty absurd, same with Java/Spring framework, ditto for Linux and the whole TTY system/file descriptor hell. Anywhere where someone spends their whole life is probably going to be a big mess.
With all due respect, I believe there is a certain demographic in IT that just has a way too trivial working model of how stuff they don’t work on directly operates.
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.
Yes, and to me the logical conclusion of that is to not worry about how complex React is. I'm sure someone somewhere needed the complexity of each feature somewhere along the line. Is it more than I need? Yes, but maybe someday the complexity will be something I appreciate. And in the meantime, you can just ignore it since it's not directly in your path.
Though the TTY system is clearly historical accident: Hacks piled on hacks on early Unix system to make actual teletypes work, then enshrined in POSIX and need for compatibilities sake.
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).
I think most people would consider almost any other stack based UI framework that has no fear of stateful components, layout engines with constant solvers, and lets you control when and how to draw frames to be an improvement.
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.
> Imagine a world where you just had drawing and input handling primitives on the web.
Good news! We do have those primitives! The canvas element can - and is - used for drawing, and input events are fairly easy to manage. Larger projects like Google Docs or Figma often go in this direction, because for very complicated applications, it's useful to be able to handle every part of the rendering process yourself.
That said, it turns out having a rich selection of easily-debuggable, accessible components attached to a powerful layout engine is also really useful, hence why people mostly stick to the DOM unless they specifically need something that only canvas can offer.
This misses the point entirely, what I mean is that if we didn't already have DOM we wouldn't invent it again — we would invent something like UIKit that has all your premade debuggable accessible components but without the kludge of the DOM.
I think this gets to the core of web devs seemingly not knowing anything else. Not knowing that, from a technology standpoint, how much better you could have it.
No one uses the DOM because they think it’s the best possible GUI technology. They build software for browsers because browsers are the lowest common denominator for distribution, which is far, far more important than technical considerations most of the time. And because of that, there’s also a large ecosystem of well understood, well documented, widely used, beginner-friendly tools for it, ranging from jQuery to React to Tailwind to WordPress.
We can talk all day about how there are better ways to do it, but until you solve the distribution problem, the technology doesn’t matter. Mobile apps sort of solved it, but even then, the bar for installing an app is higher than the bar for clicking on a link. Plus there are cross-platform tech and policy differences to deal with, you can’t guarantee your users are running the same version of the app, etc.
I'm not really disagreeing with you so much as wishing that webdevs had access to a better UI toolkit because the current state of things makes life harder unnecessarily.
the web won not because it was the best technology. the web won because it's basically the one thing that has a standards body and exists on pretty much every device.
writing native apps means having to have basically 4+ development teams for Windows/Mac, Android/iOS, and 5 if you want to have Linux. And it is pretty logistically difficult to herd five separate teams using the same product roadmap because the implementation of one feature can vary so wildly. But if you don't and someone gets a feature someone else doesn't get then people get upset.
The other big piece missing is that desktop-based GUI tools have native primitives that are designed for building complex apps. The web has bits and pieces, but is still a document renderer at its core. I’ve worked in a few of the XML-based GUI tools and MVC frameworks, and none of them were great, especially for real-time information. But at least the native SDKs provide basically everything you need.
I think the reactivity model React has is very compelling, and once you start thinking in terms of “GUI as a function of state,” you start trying to do the same in PHP or Swift and it just doesn’t work out as well. (Though there’s now SwiftUI which is a more reactive way to do iOS GUIs.)
I think react struck gold conceptually, and in a world where the “native sdk” (the browser) didn’t give you much, it became very compelling for many people. I think it has struggled to create intuitive APIs, and has struggled to handle real-world performance without clunky APIs.
Not to mention, browser environments face a slew of problems desktop apps don’t. You have to ship much smaller bundle sizes, no type-safe language, immature language requiring polyfills for useful language features, and the list goes on. Each problem introduces a new tool (webpack, typescript, babel, etc.), and they don’t frequently place nicely together. If I’m writing a Rust or Go program, practically every dev tool I need is part of the language toolchain. And while there are projects that aim to do that for web, they run into the “yet another standard” problem.
Backend has complex problems to solve, but at least you fully control the stack. You can use languages with simple toolchains and good libraries for writing web servers. On the front-end, every library you use is ultimately at the whim of the browser.
at the end of the day it is really about which poison you would pick; one team dealing with one complicated toolchain or five teams with their own bespoke OS-specific toolchains that can barely coordinate. They're both not good choices; and in an era that until recently was an era of dev scarcity, a lot of companies picked the former choice.
people also really hate feature gaps between platforms. so option one makes your customers less angry at you.
> 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.
I think this is a really good thought experiment and that you are right - we wouldn't end up with the DOM if we started from scratch. It's a pretty bad local optima resulting from decades of legacy cruft. However, I do think react is closer to that ideal than the DOM.
Like, what is better? GUIs are hard, the old way was duplicating state at the ”view” and the “model” layer, resulting in millions of bugs. The core idea of react v=f(m) is sound, and is the correct approach. Also, react itself is not even that complex.
Are you an experienced UI developer that knows of something we should all use instead? Even if it's non-web I'd love to hear about it. We all would. Then we might take inspiration from it and build a new web framework.
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.
Agreed with “just generate a web page on the backend”. But if the webapp is sufficiently complex (all websites I have been paid to work on have been), you need a component based framework like React to make the creation of the page manageable
Really thorough! Best opening explanation of react render behavior I’ve read to date. One of my goto interview questions for front end devs is “when does react render?”
Updated in 2022, but I don't see anything on <Suspense> for example. That doesn't necessarily mean the info is now wrong, but it's definitely not complete anymore.
I did title it "_Mostly_ Complete Guide" for a reason :)
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.
Tangentially, Solid is fascinating - especially the dom-expressions backend meaning you can basically bolt compilation behaviour into anything that supports that.
The flagship feature of React 19 is a "compiler", but doesn't seem to have the main features of Forget. (inferred effect dependencies) I'm guessing it's not coming any time soon.
React 19, a library release, is completely separate from the eventual release of the React Compiler build tool (which is currently implemented as a Babel plugin wrapper around a full compiler implementation core).
That said, React Compiler will _depend_ on React 19, because it needs a new memo/caching hook that will be included in 19.
Note that I did a fairly extensive update to it in 2022 to cover React 18.