A Visual Guide to React Rendering
alexsidorenko.com
alexsidorenko.com
As linked in this article, folks might also be interested in my very extensive post "A (Mostly) Complete Guide to React Rendering Behavior" [0], which goes into a lot more detail on the nuances of this.
I also generally recommend reading some of Dan Abramov's posts that explain how and why React works, including the "Complete Guide to `useEffect`" [1], "React as a UI Runtime" [2], and "Before You memo()" [3]. Finally, it's worth noting that some of React's batching behavior will change in React 18 to always batch renders even across event loop ticks - see the React 18 Working Group post on "Automatic Batching for Fewer Renders" [4] for details.
FWIW, some of this material is being incorporated into the upcoming React docs rewrite [5], which I'm really excited to see go live.
[0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
[1] https://overreacted.io/a-complete-guide-to-useeffect/
[2] https://overreacted.io/react-as-a-ui-runtime/
[3] https://overreacted.io/before-you-memo/
I do understand the need for React when building truly complex applications, like a spreadsheet or word processor app, but I wouldn't be surprised if the majority of projects using React could be solved with a simple template rendered in the backend.
For one of my clients projects it started out in what seemed like a simple crud app and so I did the few reactive changes in pure java script. The thing is: requirements changed and now after a while I couldn't get around adding VueJS simply because the reactive changes kept piling up.
Even though the HN sentiment seems to be that all "modern" frameworks are just huge piles of code that you add to your project without understanding how any of this works, my personal opinion is that using something like nextjs with server side rendering is not all that different from using a server side php framework like laravel. You still generate the same html unless you need reactive changes and when you do, you are happy to have chosen that. And to play a bit the devil's advocate: Unless you write your own webserver and template rendering engine you are already using a bunch of code you don't really understand.
Just fetch the pre-rendered HTML fragment and put into the page. Done.
And the good thing is that you can render a server side component either as part of a full page load or separately for a dynamic update.
But if you have decided to do frontend rendered templates, then I agree, pick one of the popular frameworks from the start of the project.
Vue is IMHO a better pick than React, Vue has better ergonomics and is just better how everything is tied together. Vue is a well designed framework.
By putting 20% the effort we put nowadays with these big frameworks into well organized "sprinkles" it is a very viable alternatives. Tools such as Stimulus, unpoly, htmx,etc make this very approachable and maintainable.
To me, SPAs only make sense in two scenarios: 1) You have the requirement for the app to work offline, or on really bad network connections (subway, etc) or 2) You already have a team which only wants to do SPAs and everything else is uncool to them.
Also, it make task splitting between frontend and backend engineer that much more easier.
The need to separate the team into frontend & backend engineers is a direct consequence of the over complicated frontend frameworks.
That is another tragedy of this heavy frontend trend. We are undermining the team’s performance and makes it harder to finish deadlines.
Usually what happens is that the frontend & backend engineers get out of sync and starts working on other things until they can sync again.
When this happens too often there is push to put the backend and the frontend in different teams.
After the split the teams start evolving separate cultures and mindset how to solve things and soon enough both teams has their own build and deploy pipes.
Eventually the teams no longer feel that they share a mutual idea of common ownership and the project stagnates.
If we keep things nice & simple we can work as fullstack engineers together as a team.
> solved with a simple template rendered in the backend
Or a simple template rendered in the frontend, see this demo, where no huge libs are used. Instead a 200-line lib is used to get the equivalent of stateless React components: https://github.com/wisercoder/eureka
I am not sure about that. Look at Google. For their truly complex applications like a spreadsheet or word processor (Google docs) they seem to have given up on the DOM altogether and are reimplementing the whole UI in HTML5 canvas.
> I wouldn't be surprised if the majority of projects using React could be solved with a simple template rendered in the backend
Yes, Google and the rest of the folks who are pushing for web components believe they can be.
But here I am at work, doing CRUD forms with rxjs, epics, redux, websockets and a shitton of home made packages for doing validation, lazy translations, mixing microfrontends, etc, etc.
Server Side Events (SSE) is better option to websockets IMHO, it is a much simpler protocol so you can implement in any backend of choice with a few lines because it just a HTTP request that is kept open for a longer period of time.
Websockets are bidirectional whereas SSE are unidirectional, but you rarely need the client to push huge data sets to the server.
And if you already have endpoints for fetching HTML fragments for rendering a components, SSE fits well as enhancement into that architecture to get a more live experience.
e.g.
model update in backend -> notify frontend with SSE that model changed -> component that renders model fetches new HTML fragment over HTTP.
This makes the messages over SSE tiny, only need to say that a model changed, not the entire model data. This means that you can turn off SSE and the applications still works, just without live updates thru push, e.g switch to timer based solution instead.
What is also nice by fetching HTML fragments over HTTP is that you use cache headers, if you already have the latest fragment that is just a 304 Not modified.
I think that SSR with dynamic updates of HTML fragments closer respects how the web was intended.
The other thing that tends to happen is that components become god objects. People stuff all their business logic in there, and suddenly most files in the project have a tsx or jsx extension. It's winforms code behind all over again. "React is a library not a framework" starts sounding pretty hollow.
It's possible to not do this, so I can't strictly blame react for this - but it's happened in every react project I've seen.
I prefer dumb views, but no issue with those dumb views being split up into sub views.
But not 100% sure what you mean - could you expand?
I do agree with your other point - it's almost impossible to use React as 'just a view library', it ends up permeating everything. I believe the hooks API aggravates both of these problems: the former by making it easier than the alternative patterns, the latter by creating function 'colors' that are contagious.
I do agree about one thing though, before hooks, the standard recommendation was redux (or similar) I kept SCREAMING that it was a giant global anti-pattern. I don't think anyone understood that for the first 5 years of React. It seems like that whole thing is corrected now.
Hot take: I'd argue this is confusing because (almost) everything should be a global in UI development. Plenty of websites were built in PHP and basic Javascript with (gasp) globals! I guess some folks don't understand that people have been making pretty complex web apps since before 2013. It's monumentally counterproductive having to deal with state management in like 40 nested components because you just want the username and user email to trickle down.
So people re-invented global state but we call it Redux now. It's a parody of a parody.
Recent versions of Redux include a useSelector hook that manages that context provider for you, which is probably where some of the confusion comes from.
There's no confusion, Redux absolutely does deal with passing around data in your app, that's why there's literally an FAQ dedicated to how to do it[1][2] -- and whether or not it should be done via setState or the Redux store. It's a stupid solution to a stupid problem, but now we're stuck here until TikTok will inevitably come up with their own "ground-breaking" React replacement in 5 or so years and we'll start the whole cycle again.
[1] https://redux.js.org/faq/organizing-state#how-do-i-organize-...
[2] https://stackoverflow.com/questions/37264415/how-to-optimize...
So you don't hate redux, you hate how react binds to it.
I understand that this probably feels incredibly pedantic but it's quite important to frontend engineers like me. Redux is only a state manager, and it is not a React library.
If you tell component X what state component Y is in you are in some way passing data around in your app. Since Redux manages the state it is part of the chosen strategy for how data should be passed around in the app.
It goes further than that, but essentially it's all about maintaining a context for a thing. I have a patient, that has meds and records etc, I need to keep that contained to one place so that I can have a SECOND patient at the same time (if I am writing an EHR for example). The original "UI of the web" was Open a thing, edit a thing, save and close a thing. And all of that was like 6 full page refreshes.
More apps should be like Trello, for example, where you can just edit a lot of state on lots of different objects super quickly. Globals don't work well for that.
Let’s expand your <Tetris> example. You didn’t specify whether both players are on the same computer or not. I agree that my <Tetris> instance should not depend on or conflict with any other player’s <Tetris> instance. What does that look like in practice?
Whether it’s local or internet play, we need a way to isolate each player’s game state. Each <Tetris> instance should only be concerned with displaying a single game state, and responding to at most one player’s inputs. What happens outside of that is not its concern: things like maybe logging into a server, knowing that there is a second <Tetris> instance running alongside it, knowing where garbage blocks came from, maybe knowing that my friends are online, etc.
To me, the obvious choice is to use something like
<Tetris state={app.player[0].gameState} />
In either case, <Tetris> knows nothing about where its state comes from or goes to. But that state has to live somewhere for the app to access it, so where is it stored?
FWIW, I maintain Redux, and I've written extensively trying to clarify when it does and doesn't make sense to use Redux, and how to use it the right way [0] [1] [2] [3] [4] [5]. No question there's been a lot of FUD and misconceptions about that over the years, and I wish I didn't have to spend so much time on this topic, but lots of people never look at our docs and actual recommendations.
Also worth noting that our Redux Toolkit package [6] and React-Redux hooks API [7] have made Redux _much_ easier to learn and use than it was previously, and we get a ton of very positive feedback about that.
[0] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...
[1] https://changelog.com/posts/when-and-when-not-to-reach-for-r...
[2] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
[3] https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
[4] https://redux.js.org/tutorials/essentials/part-1-overview-co...
[5] https://redux.js.org/style-guide/style-guide
[6] https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
Please don't remind me of that
Before react and vue everyone could create a mess, but it was not mandatory. Desktop frameworks always used sorts of controller hierarchy vs view hierarchy separation and didn’t store global data. There was decent ui before web/react (though it may sound crazy to react guys).
I don't think anyone understood that for the first 5 years of React
I bet that millions of developers who were not on the ~awesome hype train~ would look at this statement with a great confusion.
I’m not a react guy though, can someone explain where the data usually resides now? Right in a component state, I guess?
Your mental model for updates can be shared across all apps that use React and it's a huge blessing for getting up and running with an unfamiliar codebase.
Angular, for all its flaws and the major mistake that was announcing Angular 2 to be a rewrite etc causing a big exodus, at least had an Opinion on how to build an application end to end.
- Try Vue[0], Lit[1] (it's a bit cutting edge but I really like it), or the other entries in the component-building library space
- Don't use redux/vuex all of that, and just write plain javascript objects that make fetch() calls
- Don't use hooks (yet)
If you do these things, you should find the component approach refreshing compared to copying and pasting HTML and managing event handlers/spaghetti and making your own structure. For all but the simplest of pages there should be an improvement over vanilla HTML+JS.
If it makes you feel better, if you squint React looks exactly like Backbone views, which had a reason for existing back when they did, and if you go even further back it's like COM[2].
[0]: https://vuejs.org/
[1]: https://lit.dev/
This is a puzzling advice to give to someone who wants to offload business logic away from components, as redux with sagas for example is a great place to put it. That way if you use selectors (preferably memoized as well) your components will only update when needed and you can organize business logic however you want.
By the time they finally realize the mess they’ve created, they’ve sunk too much effort and credibility to admit fault.
Of course, most of this is not React's fault -- they blazed the trail, and it's not like they could have known to build in the semi-automatic reactive system that Vue did right ouf o the gate. That said, KnockoutJS and the whole MVVM revolution along with RXJS were around to learn from.
https://github.com/vuejs/rfcs/pull/17#issuecomment-494242121
You can't ask for more than that from someone who disagrees and is in control of the project. Also he's doing a pretty awesome job maintaining the project.
The posted link contains a detailed breakdown written by Vue's creator of why Vue, a similar tool to React chose to de-emphasize class-based components in favor of the composition API (hooks).
I thought you might be able to find some clues to why people pick hooks over class-based components in there.
I'm a least JS, 'You Might Not Need JQuery' kind of person so my complex web applications are all rendered in the back-end using Go but this particular website is static and this is the first time I've added some JS to it for a core function.
It does seem like Vue is a good fit for small front end reactive components like this, I'm refraining from passing further comments on the subject as this is the first time I've tried it.
I think vue is great for small apps and "big" apps, and I think others would agree. I mostly disagree on just how much value some of the enterprise-grade patterns that show up have.
I agree with your use cases for Vue, It enables quick component development with minimal learning curve and good performance. A good choice for someone like me who had been holding out on modern JS libraries to offer better usability.
There seems to be more lighter version of Vue[1] being developed[1] which seems to offer more flexibility in terms of how light we would want it to be and looks similar to Lit, Did you recommended Lit for the same reason?
But yes, if a dev thinks that React or Vue or whatever is somehow going to automatically create good architecture for them, then they're in for a bad time.
I use PureComponent everywhere, but I don't know what people do in function-component world.
> [ 1, 2, 3 ] === [ 1, 2, 3 ]
false
> [] == []
< false
sometimes. And that's with two equal signs, not three!
Python says True.
Ruby says true.
JS says false.
And otherwise, JS is quite lenient with not interpreting the input like you describe it when using "==":
> [] == 0
< true
> [] == false
< true
> _.isEqual([ 1, 2, 3 ], [ 1, 2, 3 ])
trueI can't think of any good reason beside react native. Is react native, so good that it can compensate for such serious flaws?
Still, very helpful to introduce people to all the important concepts for hook based React.
PureComponent : class components :: memo : function components