When does a project need React? That’s the question Chris Coyier addressed in a recent blog post. I’m a big fan of Chris’ writing, so I was curious to see what he had to say.
So today, I’m here to argue that the answer to “When does a project need React?” is not “it depends”. It’s “every time“.
First, let’s get something out of the way: in his article, Chris picked React as a stand-in for “front-end libraries” in general, and I’ll do the same here. Plus, React is what I’m most familiar with from my ongoing work on VulcanJS, a React and GraphQL framework.
That being said, my arguments should apply equally well to any other library that offers the same features as React.
When all you have is a hammer, everything looks like a nail.
This proverb has long been used to condemn anybody trying to apply a systematic one-size-fits-all approach to every problem.
But let’s suppose for a moment that you did live in a world full of nails (however uncomfortable this might sound), and that your trusty hammer was able to take care of any issues you encounter.
Just consider the benefits of being able to reuse the same tool every time:
- No time spent on deciding which tool to use.
- Less time spent having to learn new tools.
- More time to get better at wielding your tool of choice.
So is React that tool? I think it just might be!
First, let’s address the most common argument against the “React all the things!” approach. I’ll quote directly from Chris:
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.
What’s that? You need to use that form in multiple places on different pages? And only show it under certain conditions? And animate it, too? Wait, hold on…
The point I’m trying to make with this little scenario is that complexity is not an all-or-nothing, binary choice. Instead, modern websites live on a continuous spectrum that goes from static page all the way to rich single-page app.
So maybe your project is comfortably nested at the “simple” end of the spectrum now, but what about six months down the road? Isn’t it better to pick a technology that leaves you room to grow, rather than one that pigeon-holes you into bad practices?
Premature optimization is the root of all evil.
Another popular saying among programmers. After all, who needs a hammer and nails when duct tape will do just fine!
But this makes the assumption that “premature optimization” is a long, arduous process with few benefits. And I don’t think this applies to React.
While React may take some time getting used to, once you learn its basic concepts you’ll be just as productive as with classic front-end tools.
Maybe more in fact, because React leverages the extremely powerful concept of components. Just like CSS encourages you to think in terms of reusable classes and styles, React pushes you towards a flexible, modular front-end architecture that has benefits for every use case, from the lowly static homepage to the interactive back-end dashboard.
Installing a jQuery plugin used to involve finding its homepage, downloading it, copying it in your project directory, adding a
<script> tag, and then hopefully remembering to check back every couple months for new versions. These days, installing the same plugin as a React package is just the matter of a single npm install command.
And with new libraries like styled-components, even CSS is now being dragged kicking and screaming into the future.
Believe me, once you get used to this world where everything is speaking the same language, it’s really hard to go back to the old way of doing things.
I know what you’re thinking: so far I’ve tried to sell you on the benefits of React to developers, but I’ve carefully side-stepped any mention of the end user experience.
What I’m talking about here is rendering React on the server. In fact, tools like Gatsby (and soon, Next.js) even let you compile React components into static HTML files that you can host on, say, GitHub pages.
To recap, here are the four reasons why I think React is a valid choice for any project:
- It’s really hard to guarantee you’ll never ever need interactive features like tabs, forms, etc. even for the simplest of site.
- React’s component-based approach has big benefits even for static content-based sites.
- Modern server-rendering tools eliminate the downsides of using React for the end user.
So what do you think, Chris? Have I made a convincing case? Or do doubts still linger in your mind?
And what about you, dear reader? Whether you think like Chris that every tool has its use, or whether you agree with me that the Time of the Hammer is at hand, let us know in the comments!