You Probably Don’t Need React/Redux
choose your tools because they fit your problem
Listen, I know that react and redux are the hotness right now. Maybe even add in typescript if you want it to be even hotter. And usually things that are the hotness are hot for a good reason — because they are fantastic. Everyone and their mother don’t decide to start using something because it’s “meh”. But there is so much exciting development within the web community these days that it’s easy to get swept up in the hotness. Honestly it doesn’t feel right not to use it, at this point.
But remember that you are not a groupie, you are a software engineer, and it’s called engineering for a reason — because you are designing a system to solve a problem. And just as you wouldn’t expect an architect to draw up your small solar powered home with all the walls as glass, because big windows and glass are hot right now, you can’t let yourself fall into the same pattern. You choose your tools and materials based how effectively they can solve the problem you are trying to solve, not the popularity of the tools and materials.
Accidental Over-Engineering
This realization has hit me hard a couple of times recently. First, I saw an introductory code course that taught react and redux (which inspired the title of this post). Now, react and redux are incredible tools and have achieved their popularity for a good reason. However, they are not the perfect tools for every single site, nor are they simple introductory material, especially redux. In fact, the author of redux himself has said this. React and redux were both built by Facebook’s engineering team, to solve their problems. And their problems are “we are trying to build an absolutely enormous app and keep it running well and organized.” Anyone else who has that same challenge in front of them would do well to very seriously consider react and redux as well. However, if you are just starting to learn code and are trying to make a small blog or personal website, you should think twice before applying these tools, since they were built for a drastically different problem set.
Picking up react/redux for a small simple site is like renting and learning to operate a backhoe in order to dig a hole for a plant in your garden, instead of just using a shovel. Don’t get me wrong, backhoes are incredible tools, and are really really good at digging holes. They can dig the biggest holes the fastest, and enjoy enormous popularity among contractors who need to frequently dig holes. However, if you are just trying to dig a hole in your garden, it’s so much overkill that it’s ridiculous. It would not only be way more expensive, but also take way longer than is necessary, for just about no benefit. In the same way, running react and redux for a small personal site or blog is genuinely insane. Just write it with html and css! It’s not that react or redux are bad, on the contrary they are excellent — you are just using them for the wrong purpose.
Accidental Stifling of Innovation
The same realization hit me when I was working on a new version of my company’s website (this is still the old one, at the time of writing — sorry). Design and product kept asking for parallax and expensive visual effects for the site, and my developer gut instinct was screaming “NO PLEASE NO!”, just because we are so trained to keep things simple, user-friendly, and performant by current conversation and developer tools. But the more I thought about this, the more I realized that this instinct was entirely amateurish.
Where did this instinct even come from? Simplicity, user experience, and performance are values that are hammered over and over by large product companies like Google and Facebook in their talks and tools, and with good reason! It’s incredibly important for them and their business. But again, I was not building Google or Facebook here — not even close. I was building a marketing page for an agency. So why was I trying to get this project to adhere to their best practices? The goal of this project is not to ship a fast app that lots of people can get familiar with quickly and use daily, it’s to ship a cool intriguing page that stands out and wows company executives into hiring us, and getting potential hires to work for us. A dry, fast-loading, app-like experience just doesn’t fit the bill for this project.
Now, that doesn’t mean throw accessibility and performance out the window, but it certainly does mean really evaluating the needs of the specific project I was working on and building the best fit to those needs, rather than blindly following current (well intentioned, to be fair) advice coming from large successful companies. So I loaded up gsap and went to work on some awesome interaction (which we decided would not load on mobile, since mobile perf is a lot more touchy).
Don’t Let It Happen To You!
It is so easy to get swept up in whatever tooling is currently hot and popular, or set your defaults to be whatever wisdom is coming out of thought leaders in the community. But automatically subscribing to these ideas is dangerous, because it can easily lead you down a path where you are wasting your employer’s money and time by absurdly over-engineering, or shifting priorities in a direction that might be best for large companies’ bottom lines, but isn’t necessarily good for the specific project you’re working on.
You certainly should listen to and learn all the cool and hot technologies and conversation topics, because they are that way for a good reason — usually they are amazing. Just make sure that when you are making your own engineering decisions, they are made pragmatically, and with respect to the specific problem you are trying to solve, and let yourself slip into defaulting your decisions based on coolness or popularity.
And finally a shameless plug, just because I can — if this struck a chord with you, feel free to reach out. I have been working specifically on technology that handles small and medium sites extremely well, generously sponsored by my employer, for years. If you are not trying to build a massive app, some of my work might be helpful for you. It’s all open source, and mostly based on static site generators. Check out Spike, the beating heart of our suite of tools, and feel free to join our warm and welcoming community on slack to chat about making quality products using good engineering 😉.
