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.
In a nutshell, Chris puts forward a series of good and bad reasons why one might want to use React (or other similar modern JavaScript libraries) on a project. Yet while I don’t disagree with his arguments, I still find myself coming to a different conclusion.
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“.
React vs Vue vs Angular vs…
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.
The Power of the Hammer
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!
The Complexity Spectrum
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.
Fair enough. A simple blog doesn’t need React. After all, even if you need a bit of JavaScript to hook up a newsletter sign-up form, you can just use jQuery.
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?
The Benefits of React
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.
JavaScript, JavaScript Everywhere
We live in a JavaScript world. Or, as Chris puts it:
You got Node.js on the server side. There are loads of projects that yank CSS out of the mix and handle styles through JavaScript. And with React, your HTML is in JavaScript too.
All JavaScript! All hail JavaScript!
Chris isn’t quite convinced, but I am. JavaScript in itself isn’t necessarily perfect, but having access to the entire modern NPM ecosystem is amazing.
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.
Won’t Somebody Please Think of the Users!
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.
And that remains the key argument against modern libraries: slow, JavaScript-bloated sites that take ages just to display a single “one weird trick” ad.
Except here’s a little secret: you can get all the benefits of React without any JavaScript at all!
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.
As an example, my own personal site is a Gatsby-generated React app that doesn’t load any JavaScript at all (beyond a Google Analytics snippet). I get all the benefits of using React in development (all-JavaScript, access to the NPM ecosystem, styled-components, etc.) but end up with a 100% HTML-and-CSS end product.
Wrapping Up
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.
- Access to the modern JavaScript ecosystem is a huge benefit.
- 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!
Hail JavaScript! sounds like Hail Hydra! to me. And I’m with Shield
I see a lot of people that take your approach but don’t own up to it. So I applaud you for that.
I used to take this approach too, but have learned to invest more in the problem area as supposed to the frameworks/toolset as they come and go like the wind.
Good luck with VulcanJs!
Lively debate!
Before I start, let me say I’m not an expert on all-things React. I’m a beginner, but I have the perspective of decade of being a tech pundit and product owner of a production product in React.
Where I thought this might be going is more like react-native, where should you go down the React road, it opens doors for you (like a native app) that you don’t necessarily get on other tech stacks. So I suppose that’s one more thing to add to your arguments.
It’s also nice that we can toss aside any arguments about SEO and progressive enhancement and user experience and such, because React apps can be rendered on the server and thus we have healthy URLs and nobody is being left out and such.
Or can we? Server rendered pages are likely great for your blog, but I don’t think it’s safe to tell folks that means you don’t need to ship any client side JavaScript at all. I would think 99% of React usage is specifically for the front end. It’s all that state management (in reaction to client side events) and DOM management that made React appealing in the first place, and which I’d happily point people toward React to handle. So to say “you can get all the benefits of React without any JavaScript at all!” doesn’t feel quite right to me.
I find it hard to wrap my head around what it looks like to ship a server-rendered React app, that also leverages all of React on the front-end. I guess that’s why Ember calls their version of that “fastboot”, right? Because you’re shipping the page, but it’s (mostly) non-functional until the JavaScript arrives and executes. Percieved performance.
Complexity also factors in here. There is good bit of difference between:
React
and
React + Redux*
(*Substitute your favorite state management system) And Redux I think is a pretty important peice if a big part of the goal is fighting spaghetti and disparate sources of truth.
And that’s a good bit differnet between:
React + Redux + Immutable + Styled Components + Babel + Webpack + Lambda + DynamoDB
All of those things provide a lot of value and make sense in many situations. But holy heck is that a thick stack.
You didn’t advocate for that, but even with Gatsby, you’re looking at:
React + Gatsby + Webpack + React Router + Server Side Rendering
Which is a non-trivial buy-in.
I don’t have a massive point here, other than going down this road means a big learning curve and lots of dependencies. My hope would be that choices are made along the way that make backing out (to hop on some new future hot tech stack) not so hard. Things like content-in-Markdown and using CSS.
But you could argue any stack has this going on.
Let’s do the four points!
I don’t think it’s “interactive features” that are what require React. Especially not a handful of them, like tabs and (even repeated) forms. It’s a heaping pile of interactive features that are all intertwined with each other that point toward that “reach for React” moment to me.
If the end product is “a static content-based site”, I’d say the door is wide open for stack experimentation. Everything is on the table. Classic CMS’s, static site generators, sites compiled with things like Pug or Nunjucks, and sure, some cool headless CMS + server-rendered React thing might be perfect.
It’s hard for me to think “static content site? The best option there is server-rendred React” That stack is pretty thick and opinionated and I’m not sure every site like this is the exact same sized nail for the the metaphorical one-true-hammer.
Agreed! React, specifically, isn’t required for this, but I take the point.
In terms of a fast-boot situation, sure. That helps loading speed and so the downside of slowness is minimized. In terms of classic progressive enhancement thinking, no. If you have an animated and interactive form that is powered by React, you need React on the client side to power that, and I’d argue that React doesn’t exactly encourage you to make that server-rendered form work in the event that client-side React doesn’t run as expected.
I’m enjoying this discussion! Thanks for you’re perspective, Sacha.
Great debate! Just to push back on one thing:
Since Gatsby takes care of your Webpack config, routing, as well as SSR, in practice the Gatsby stack is just React and Gatsby. I think that’s where a lot of the confusion about React comes from, people unfamiliar with the JavaScript ecosystem assume that Webpack, Babel, etc. are all individual pieces of the stack you have to learn, when in fact they can just be tools that run in the background and improve your developer experience.
But overall I think you make some perfectly reasonable points, which makes it really hard to argue with you… Still, I did my best ;)
Proceeds to make a binary recommendation on a very complex topic…
What I think is missing here, and what is often missing from these types arguments is background info, especially assumptions being made. There is a wide array of projects that we work on and they often require different tooling but sometimes it’s very difficult to see outside our own world and into others. Often when I speak to client-side evangelists I find myself immediately disagreeing with them but when I dig deeper I find that the type of work they do tends to lend itself well to JS heavy projects, while the type of work I do daily does not.
Maybe this was a poor choice for examples, but forms have been around longer than JavaScript, there is no need to make any use of JS on simple forms at all. Tabs can also easily be done without any JS in modern browsers now. To make arguments like this without additional background leads new developers to believe it outright and is, in my opinion, leading to a decrease in web literacy and overall understanding for developers learning how to code for the web now.
I deliberately chose a controversial point of view with this article, so I’ll keep going in the same vein ;)
I think that’s actually a good thing. Web development has been far too messy and complex for too long, and it’s only because we’re so used to it that we don’t realize it. Sure, you can build tabs using radio buttons and CSS selectors, but how is that a reasonable way to code? Didn’t we all protest against misusing tables for layouts 10 years ago?
That’s why I believe it’s high time that React (or something like it) comes along to serve as an abstraction layer on top of HTML/CSS, and make all that “web literacy” obsolete for all but a minority of web developers.
That’s a very valid point Sacha, and one I can get behind. However, reading your article, I get much more of a contentious rather than empowering message.
What I would like to take away from this is that React, in a similar way to something like WordPress, should be a tool that any virgining developer should feel empowered to use without fear of questioning “is this really the right tool?”. If you continue to get deeper into web development it can equally be a great choice, but you should also be aware that there is a whole lot more out there.
Let stop arguing about it and start encouraging more people to build more cool things.
Can you help us understand motivations and possible conflicts of interest in this debate? The usual method of vetting an “outside” post is to include a statement of possible conflicts of interest (usually at the end). Chris I know, Sacha I don’t. Is there any connection (work, monetary or otherwise) with the product in question and the author of the argument? Help us understand potential bias please with pieces like this. Thanks.
I missed the reference to “vulcanJS” in my first read through, but still am not sure how it fully connects to react – perhaps the article isn’t for people who don’t use the product? (yet)
I see Yeogurt as the best option for simple static sites. It provides a great framework for doing modular design and also gives you easy access to the npm community.
Thanks Chris for explaining the larger dependency stack which might well show up once you start out down the road with React. I have no doubt React is super-powerful and web developers would do well to get into it. However, I am always a little wary of investing into tech which you don’t necessarily “get”. For example I see a lot of projects which import libraries needlessly and out of habit. Bottom line – understand the technology you are using, when you are using it and why. I am also an advocate for using your brain to solve problems rather than just importing a pre-built component – sometimes it feels good to try and build something from scratch and actually learn something from 1st principles rather than just learning how to chain or mashup technology components together to get the results you need.
This article is getting a lot of backlash, but from my perspective (small agency, with small to mid tier clients ) react is super useful because clients always want to move forwards and not backwards adding extra features as the project matures.
So for example if we start with a client who just needs a static website but might want to do an app later, going straight to react means less work later.
Plus its damm fun to work with. Everything I do now is so DRY i can finally focus on interesting things rather than feeling like im banging out widgets all day, if the learning curve seems to steep checkout react create app – it works out of the box
This is an awesome point, thanks!
I don’t think React is the equivalent of a “hammer”. A hammer is a basic tool that has been around for 1000s of years and will surely continue to be used for many years to come. Something analogous in the web world would be HTML, CSS and (plain) Javascript – standardized technologies that have existed for a long time and will continue to exist for a long time.
React (and co) is a more complex tool, which did not stand the test of time. Chances are that in a few years using React will be considered uncool and development will slow down. Those who use React today will eventually have to move to something else.
I am not against React and other similar frameworks, however these are tools created to solve specific problems in our era and they shouldn’t be used as an excuse to avoid learning the core technologies.
React is a tool analogous to what JQuery used to be until recently, or what WYSISYG editors used to be in the more distant past. If you are a Web Developer then you should master the core technologies of the web and you shouldn’t use the fad of the day as an excuse not to. Then you can use React etc whenever it makes sense for the specific project, and not because that is the only tool you know well.
Couldn’t agree more Theo.
I love your stuff Sacha, and I appreciate you’re taking a really biased view here to make your point but there were a couple of things I wanted to mention that I too exception to or have found issues with in my own practice.
This comment came at the end of a sentence about adding a Newsletter signup form with the assumption that jQuery would be needed to make it work and animate it in. We can simply use newsletter signup forms and animations without the use of jQuery or Javascript at all, however, you nailed it on saying certain conditions can be made easier with help from React.
Also, the technology we’re using is HTML, CSS, and Javascript so there’s no pigeon-holing here either.
While this sounds great there is the issue of getting NPM setup in the first place… and watch out if anything goes wrong with it. Sometimes going to a homepage and getting the latest stable version of a library is easier than getting npm setup and running with your project.
Again, I know that you’re making a point here. I’m keen to get my head around React more than it is at the moment but people should not be mistaken in that it is the easiest approach to building every site.
Keep up the great work Sacha!