As the need for these libraries fades, and we see a massive rise in new frameworks, I’d argue it’s not as clear when to reach for them. At what point do we need React?
Here’s my take.
✅ Because there is lots of state.
Even “state” is a bit of a nebulous word. Imagine things like this:
- Which navigation item is active
- Whether a button is disabled or not
- The value of an input
- Which accordion sections are expanded
- When an area is loading
- The user that is logged in and the team they belong to
- Whether the thing the user is working on is published, or a draft
“Business logic”-type stuff that we regularly deal with. State can also be straight up content:
- All the comments on an article and the bits and bobs that make them up
- The currently viewed article and all its metadata
- An array of related articles and the metadata for those
- A list of authors
- An an activity log of recent actions a user has taken
React doesn’t help you organize that state, it just says: I know you need to deal with state, so let’s just call it state and have programmatic ways to set and get that state.
Before React, we might have thought in terms of state, but, for the most part, didn’t manage it as a direct concept.
Perhaps you’ve heard the phrase “single source of truth”? A lot of times we treated the DOM as our single source of truth. For example, say you need to know if a form on your website is able to be submitted. Maybe you’d check to see if
$(".form input[type='submit']).is(":disabled") because all your business logic that dealt with whether or not the form could be submitted or not ultimately changed the disabled attribute of that button. So the button became this defacto source of truth for the state of your app.
Or say you needed to figure of the name of the first comment author on an article. Maybe you’d write
$(".comments > ul > li:first > h3.comment-author).text() because the DOM is the only place that knows that information.
React kinda tells us:
- Let’s start thinking about all that stuff as state.
- I’ll do ya one better: state is a chunk of JSON, so it’s easy to work with and probably works nicely with your back end.
- And one more even better: You build your HTML using bits of that state, and you won’t have to deal with the DOM directly at all, I’ll handle all that for you (and likely do a better/faster job than you would have.)
✅ To Fight Spaghetti.
This is highly related to the state stuff we were just talking about.
React encourages the use of building things into modules. So this form would likely either be a module of its own or comprised of other smaller modules. Each of them would handle the logic that is directly relevant to it.
React says: well, you aren’t going to be watching the DOM directly for changes and stuff, because the DOM is mine and you don’t get to work with it directly. Why don’t you start thinking of these things as part of the state, change state when you need to, and I’ll deal with the rest, rerendering what needs to be rerendered.
It should be said that React itself doesn’t entirely solve spaghetti. You can still have state in all kinds of weird places, name things badly, and connect things in weird ways.
In my limited experience, it’s Redux that is the thing that really kills spaghetti. Redux says: I’ll handle all the important state, totally globally, not module-by-module. I am the absolute source of truth. If you need to change state, there is quite a ceremony involved (I’ve heard it called that, and I like it.) There are reducers and dispatched actions and such. All changes follow the ceremony.
If you go the Redux road (and there are variations of it, of course), you end up with really solid code. It’s much harder to break things and there are clear trails to follow for how everything is wired together.
✅ Lots of DOM management.
Manually handling the DOM is probably the biggest cause of spaghetti code.
- Inject HTML over here!
- Rip something out over here!
- Watch this area for this event!
- Bind a new event over here!
- New incoming content! Inject again! Make sure it has the right event bindings!
All these things can happen any time from anywhere in an app that’s gone spaghetti. Real organization has been given up and it’s back to the DOM as the source of truth. It’s hard to know exactly what’s going on for any given element, so everybody just asks the DOM, does what they need to do, and crosses their fingers it doesn’t mess with somebody else.
React says: you don’t get to deal with the DOM directly. I have a virtual DOM and I deal with that. Events are bound directly to the elements, and if you need it to do something above and beyond something directly handle-able in this module, you can kind of ceremoniously call things in higher order modules, but that way, the breadcrumb trail can be followed.
Complicated DOM management is another thing. Imagine a chat app. New chat messages might appear because a realtime database has new data from other chatters and some new messages have arrives. Or you’ve typed a new message yourself! Or the page is loading for the first time and old messages are being pulled from a local data store so you have something to see right away. Here’s a Twitter thread that drives that home.
❌ Just because. It’s the new hotness.
Learning something for the sake of learning something is awesome. Do that.
Building a project for clients and real human being users requires more careful consideration.
A blog, for example, probably has none of the problems and fits none of the scenarios that would make React a good fit. And because it’s not a good fit, it’s probably a bad fit, because it introduces complicated technology and dependencies for something that doesn’t call for it.
And yet, gray area. If that blog is a SPA (“Single Page App”, e.g. no browser refreshing) that is built from data from a headless CMS and had fancy server-side rendering… well maybe that is React territory again.
The web app CMS that makes that blog? Maybe a good choice for React, because of all the state.
That’s cool and all, but again, just because you can doesn’t mean you should. Not all projects call for this, and in fact, most probably don’t.
☯️ That’s what I know.
(There are decent emojis for YES and NO, but MAYBE is tougher!)
You’re learning. Awesome. Everybody is. Keep learning. The more you know the more informed decisions you can make about what tech to use.
But sometimes you gotta build with what you know, so I ain’t gonna ding ya for that.
☯️ That’s where the jobs are.
Not everybody has a direct say in what technology is used on any given project. Hopefully, over time, you have influence in that, but that takes time. Eden says she spent 2 years with Ember because that’s where the jobs were. No harm in that. Everybody’s gotta get paid, and Ember might have been a perfect fit for those projects.
Great post, especially the “good reasons to use React” part
It’s lovely to seem some good sense in the land of buzzwords :)
There are .js based ones, where you lose things like GSAP and more. They do CSS in .js for example. They come and go every 18 months. Knockout, Ember. Next is ELM.
vs DOM based, like Polymer2 (ex: Google Earth) and RIOT (https://youtu.be/5bpBkvuy-OE ). By using DOM you are more of a team player w/ designers, SASS, etc. Works w/ jquery and all the other productivity tools.
I even use Pug ( https://youtu.be/wzAWI9h3q18 ) w/ RIOT for static / serverless.
Thanks for taking the time to explain this topic thoroughly.
Global state management is so critical when you need it. Since there are so many choices besides Redux, I wanted to share a recent overview for those that are new or want to explore their options:
There’s also more on frameworks:
Agreed on most points and here a counter example.
This is part of the HTML used to create the (so far) fastest Hacker News PWA out there.
Tooling makes it a literal template.
That view is served both through the server and through the client.
In all this the CSS is a CSS file and served as such.
As summary, the HTML can be kept a part, the CSS can be kept a part, and the JS can orchestrate them all together in both server and client, serving an Hacker News PWA that’s interactive on fast 3G in 1.6 seconds.
Everything works with or without JS and can be shared, and rendered, per session.
React couples components and rendering into JS via JSX but like you said, and luckily for the Web, React is not the only option.
I think this is spot-on. DOM and application/UI state management are the two biggest deciding factors.
Easier automated testing is another big benefit; if you’re using React (and particularly Redux/similar as well), you have a ready-made structure to build simple tests into. You don’t have to unravel spaghetti to make things predictable and testable.
Another reason to go to a framework is if you’re going to have multiple front-end developers working on the project in parallel. The encapsulated, modular approach of React (and similar frameworks) helps maximise the team’s efficiency while maintaining code consistency, and reducing integration bugs.
Both of these rapidly become important considerations on larger projects. Project scale is a good indicator by itself of whether or not a framework is sensible.
Hey Chris, Lovely article and very helpful for me personally!
Any amendments possible to cover performance in responsive sites? :)
Maybe Vue in an exception (and that’s one of its strengths)
Front end development just gets better and better. Great article on explaining “why/when to use a framework (any)” succinctly.
Nowadays, I’ve see developers learning a new framework because others developers are using it framework. As you wrote, learning all is important to skills but use it in the any situation is very controversial for me.
Months ago, me and a friend were talking about to use react in any projects. He was trying to convince myself that react is a good solutions for all. Homever, I disagree it, because even of react is a great ideia, but use it in the any project because your community is great, there are many posts about it or because this a hype is a big problem for me.
So, great article and I hope this post open the mind of many developers.
Ps.: my english is very poor, sorry! ;)
As a “+”, I would had “the pros of working with a framework”, especially one like React: a lot of ressources, a big community, standards, best practices…
“Manually handling the DOM is probably the biggest cause of spaghetti code.” – rightly said. But only when your web application is complex. I do see people talking about React, Angular and modern technologies for basic web pages.
Understanding where to use what technologies need lot of learning.