The author of this series has done an excellent job breaking down some of key aspects of React's rendering into good explanations with some nifty illustrations.
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.
You seem very knowlegable witb React abd really I cant wrap my head around it. Di you know any a short tutorial that would show best practices and shows the strengths of React?
Great article but at the same time the absolute horror of what "modern" frontend development is.
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.
From personal experience I can tell you that using a modern framework can be really worth the added complexity even in simple applications.
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.
> I do understand the need for React when building truly complex applications, like a spreadsheet or word processor app
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.
React is indeed a complex library. For simple apps where components are simple and stateless React is easy. When you have more complex apps where components manage their own state and you have to also update the stateful component from outside, that's when the complexity starts. If the data rendered by the component is large and can't be easily cloned then it gets even more complicated.
> 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
THIS. Server side templates and something like Unpoly is what 90% of projects need.
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.
I worked on multiple webapps that used react and, in a way yes, you could do server-side rendering. But the real advantage of react (and most other framework for that matter) is to be able to easily program pages that don't need to fully reload everytime you click on something. Sure, you can still do the same with SSR, but framework make it that much more simple and help a lot with separation of concern.
Also, it make task splitting between frontend and backend engineer that much more easier.
I have to say stuff like this is why I'm not a big fan of the component approach to frontend dev. Reasoning about when and why something gets updated is not very intuitive.
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.
This is confusing because before component models, everything was a global.
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.
- 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].
It's because while React offers a decent standard for declaring components, there is no standard for building an application with React as the rendering layer. I mean I've got an `api.ts` file somewhere with a TODO that says "I should probably split up API requests and business logic", but that's all handcrafted guesswork.
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.
Every project I've inherited has done this, and every time I go through the tedious process of separating UI logic from business logic. If done the right way, a component-oriented approach can be very nice.
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.
You may want to look at SolidJS, and read some of the articles by its creator. The component model of dev doesn't imply any of this, even if the rendering approaches might learn from each other. Specifically: Solid has a component dev approach, but components vanish at runtime and it's just your reactive calls and the DOM from then on.
The alternative is manually hooking up a bunch of views that update by subscribing to some event bus, which quickly becomes unmanageable. I don't want to learn about all the custom events in the system to know how things update. And god help you if you have cascading/recursive events.
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.
That’s more a consequence of hooks & context in React specifically , rather than the component model. There are other frameworks where it’s much easier to reason about updates.
Cool but I would like to understand the opposite: why doesn't React then just memoize everything by default? Why not let the developer opt-out of memoizing instead of having them opt-in?
Memoization isn't a free lunch. I think React's approach is to keep it simple with not managing cache stores for absolutely everything. Most small to medium react apps need little to no use of useMemo to be performant.
[+] [-] acemarke|4 years ago|reply
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/
[4] https://github.com/reactwg/react-18/discussions/21
[5] https://github.com/reactjs/reactjs.org/issues/3308
[+] [-] antman|4 years ago|reply
[+] [-] tored|4 years ago|reply
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.
[+] [-] MHard|4 years ago|reply
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.
[+] [-] azangru|4 years ago|reply
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.
[+] [-] flowerlad|4 years ago|reply
> 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
[+] [-] midrus|4 years ago|reply
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.
[+] [-] maeln|4 years ago|reply
Also, it make task splitting between frontend and backend engineer that much more easier.
[+] [-] LAC-Tech|4 years ago|reply
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.
[+] [-] coding123|4 years ago|reply
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.
[+] [-] hardwaresofton|4 years ago|reply
- 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/
[2]: https://www.bitquabit.com/post/the-more-things-change/
[+] [-] Cthulhu_|4 years ago|reply
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.
[+] [-] tenaciousDaniel|4 years ago|reply
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.
[+] [-] eyelidlessness|4 years ago|reply
[+] [-] wonnage|4 years ago|reply
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.
[+] [-] flowerlad|4 years ago|reply
[+] [-] ricardobeat|4 years ago|reply
[+] [-] sktrdie|4 years ago|reply
[+] [-] have_faith|4 years ago|reply
[+] [-] de_keyboard|4 years ago|reply
[+] [-] bpierre|4 years ago|reply
[+] [-] ThePadawan|4 years ago|reply
> [] == []
< false
sometimes. And that's with two equal signs, not three!
[+] [-] addandsubtract|4 years ago|reply
[+] [-] cesarvarela|4 years ago|reply
[+] [-] iaml|4 years ago|reply
[+] [-] rk06|4 years ago|reply
I can't think of any good reason beside react native. Is react native, so good that it can compensate for such serious flaws?
[+] [-] Aeolun|4 years ago|reply
Still, very helpful to introduce people to all the important concepts for hook based React.
[+] [-] ioseph|4 years ago|reply