When You Don’t Need React

Every few months, someone in my bubble will ask for advice on getting started with web programming, and eventually, through the deluge of assertions that React is the ultimate and ideal paradigm for beginner web projects and no others are worth consideration, ask:

I’ve spieled enough times in response to this question that it became more cost-efficient to write a linkable spiel instead of rewriting it all again.

The quick answer is that a lot of people are recommending React to beginners because they personally enjoy using it. Enjoyment is a great reason to recommend a tool, so long as you describe why you enjoy it so that other people can make context-based decisions for themselves.

I don’t see this happen often online. I also see recommendations where folks conflate personal preference with technical necessity. Although personal enjoyment is an important factor in toolchain usability, it is not the same thing as technical necessity. And although React offers many technical benefits, they are not always clear-cut. For many people’s personal use cases, React is fine, but operationally unnecessary, and many other frontend frameworks will serve just as well.

This is not a rigorous feature analysis; merely a loose overview of general heuristics about operational necessity from a jaded, cynical grump for your software-pondering enjoyment, aimed more at recommendation-givers than recommendation-receivers. There are clear use cases where React is designed to shine, versus others where it’s operationally unnecessary and may bog you down. When I see React recommended to beginners, caveats are rarely given.

(You may still enjoy React when it is not strictly necessary, or you may have been lucky enough to only see it used very responsibly, or you may be tautologically wondering what web framework to learn if you wish to get hired to write React! If so, you have no need for my opinions, which are deeply biased by my preference for backend/infrastructure engineering and rapidly iterable, modular speed UIs in my personal projects.)

A quick contextual overview

One of React’s big differentiators is that it is a well-tested framework designed specifically to handle complicated one-way data binding. In other words, it’s very useful if your frontend is weirder and more dynamic than the standard interactivity cases of “clicking triggers interface changes, form inputs are validated, and I chain asynchronous requests whose outcomes inform interface changes”.

React (and its accompanying ecosystem of frameworks) was designed to performantly serve the needs of Facebook, where:

1. infinite scroll exists
2. views are deeply dynamically customized to each user
3. nearly every individual div on a page corresponds directly to a database row
4. every click and scroll polls for updates while also asynchronously firing off copious volumes of metrics-laden events that are collating detailed data about how you spend your attention on the site
5. thousands of engineers are collaborating on bits and pieces of a massive codebase that is constantly shifting.

It handles this monumental task extremely well.

If you are building Facebook, then by nature of its development history, the React ecosystem is probably the best toolset you can use. If you are not, you may want to consider your specific operational needs more thoughtfully.

A framework is what your programming hygiene makes of it

Another argument to use React, reminiscent of Rails trends of yore, is that an opinionated framework forces you to have a certain baseline of programming hygiene.

It is worth noting that although the React ecosystem is designed to handle extremely complex use cases, it is possible to use it well for simple use cases. Possible is a key word here. It is certainly possible to write good simple React when you prioritize maintainability, but I have encountered quite a lot of monolithic React which is painful and slow to refactor or add features to.

The majority of websites do not have needs vaguely resembling Facebook’s needs, and so I will often cry when I see simple webforms that should have been written in 30 lines of HTML + jQuery with a gentle splash of CSS, that are instead laboriously composed in novice spaghetti-fashion of 500 lines of monolithic React because someone was told to use it without being told why or how, obfuscated with verbose intermediate variables whose sole purpose is to pass parameters along chains of components that are each only used once, thusly requiring you to violate 8 blackboxes every time you want to send a simple form input to the DB, as said form inputs slowly struggle to load when you open the page.

If you’re gunning for programming hygiene, a framework alone won’t cut it. While React is more opinionated than many simpler frameworks, it won’t stop someone from writing spaghetti code if that’s how they write code. An explicit priority set on general code maintainability, code review, and shared expectations will keep your code well-oiled regardless of your choice of framework.

a postcard that I hand lettered while, I shit you not, waiting for a bloated webpack compilation to finish

What are your specific operational needs?

Your mileage may vary, but at least in my experience, my personal projects have historically had operational needs that aren’t well-aligned with React. I mention this not to dismiss React, but because I rarely see such operational needs discussed openly in this brave new world proliferating with standardized SaaS.

I think a webapp stands to clearly benefit from React when it has all three of the following operational needs:

1. complex one-page apps with heavy custom-built interactive rendering that must also
2. asynchronously persist and fetch tons of data from microservices, while simultaneously
3. undergoing CICD in collaboration with other developers.

This last point makes it great for plenty of industry use cases, but again, I’m talking about necessity in personal use cases.

Subsets of these three needs tend to work out fine — for example, if you want to make a complex one-page app with interactive visualizations which doesn’t need to continuously persist user-action data to a datastore, you don’t need a heavy lifting web framework. Most of the action ought to be handled with dedicated graphics code, and you can add an arbitrary ultralight web framework of choice to help with your control panel.

Sites with mild interactivity that talk to databases a lot don’t necessarily benefit from React either — as long as you’re not implementing Facebook levels of interactivity, where if one of their billion users (somewhere on the planet, who may or may not be n-degree graph-connected to you) is starting to type a comment on a post that you (another one of said billion users) may be currently viewing or about to view, an interactive notification wiggles at you a second later.

(By the way, this little engagement feature is a gratuitously monumental fucking task of engineering requiring not just a heavy-lifting web ecosystem, but a massively robust distributed network at international scale and thousands of accomplished engineers working across every possible part of the stack down to optimizing not just the network flow but also the air conditioning of the in-house datacenter.)

Another pro/con of React is its opinionated nature, and opinionated frameworks tend to shine in corporate environments. While opinionated frameworks are great for stashing your moving pieces in prescribed places to make it easier to quickly throw a new hire into a complex, unfamiliar webapp that implements a specific through-model between a monetized topic and a database, they can be rather annoying when you’re doing some oddball personal experimentation for fun and then need to come up with a wonky low-level workaround to be compatible with The Prescribed Way.

Figuring out what you need based on context

Part of why I don’t enjoy React is that I don’t enjoy web development. I only do web development as a means to an end or a way to share things online. When I write web code, I don’t want to reinvent the wheel; I want it to be modular, robust, and to get it all over with as quickly as possible. My personal happy place is squarely in the realms of algorithms, engines, data pipelines, systems, and bash glue (I spent my first internship in high school building a virtual haptic suturing/surgical simulator in C++, which, fun fact, involved poking pieces of raw meat to calibrate my simulation model for tissue viscoelasticity), so although I have done my fair share of utilitarian full-stack work in exchange for money since college, I haven’t delved at all into the intricacies of web dev as a hobby. These are both valid backgrounds on the software spectrum, and I think it’s important to provide context in one’s recommendations so that people can choose for themselves.

For example, modern web compilation frequently has incredibly bloated volumes of overhead and complexity, which is a pretty relevant piece of the software process to consider when choosing a stack. I wanted to host my small personal website for free and didn’t feel like dealing with the overhead of webpack, React, and even require.js, but I couldn’t go all the way to vanilla HTML — a certain basic level of compilation was very beneficial to me.

So I set up a simple toolset appropriate to the simplicity of my needs. I run one-line CLI auto-reloaders to watch for file changes. They recompile my SASS, and autorun a 12-line Python script that recompiles my HTML partials. I use a couple pages of modular Angular directives to templatize and render the site’s contents. Said contents are semantically described in JSON, blissfully agnostic to whatever layout I want to modularly slap them into.

I also have a handful of small servered webapps (they need to persist data) with similarly minimal frontend stacks, which use two-way-binding frameworks to efficiently templatize reusable components and provide interaction logic that I can quickly refactor when needed.

Are these appropriate frontend stacks for a corporate webapp in CICD that tracks metrics? Maybe, maybe not. Is it appropriate for my websites? Yes, they meet my needs and they are fast and easy to alter.

We used React at my last company, which was a sensible decision because our core user-facing interface is a complex one page app that handles large amounts of data flow and custom built visualization while logging metrics, making requests of our distributed query engine, and rendering highly interactive elements. It does make our simple, non-reused static components, such as “about” pages, unnecessarily verbose, and I think a number of one-time-use components could have been made far more maintainable and modular by going straight to template and boiling down those static pages to vanilla HTML partials and CSS. But since React’s capabilities really are handy for the heavy lifting in our core product interface, the decision to use it is not about those vanilla pages, but about what’s best for the super-customized complex one-page core app.

While you can by all means choose to use React whenever you want, many people simply don’t require React for their personal projects. For example, I have never built a social media website for fun. I also prefer thinking, architecting, and debugging things with a strong degree of MVC separation and blackboxing. I naturally gravitate toward test-driven development, but I tend to build projects that are are heavy on packageable mathy logic, and light on user-interface-logic. I like to prototype fast and fully restructure my prototype code very fast. In short, my past personal projects which happen to have a web endpoint would have been hindered by React, because they:

• don’t suffer from any of the at-scale drawbacks of a lighter-weight, bidirectionally-data-bound frontend framework
• would be unnecessarily bulky to develop with unidirectional data binding
• don’t derive specific benefits from using an opinionated framework
• in general, would not derive any specific technical benefits from React

So when I’m writing code for fun instead of for money, I personally don’t ever reach for React because it’s not naturally aligned with my project parameters and the way my brain thinks.

Since entering industry, I have also deeply missed the pure joy of building something while thinking solely about its purpose and function the entire time. By nature of its data abstraction — again, a useful tool in the correct context, and a hindrance in the wrong context — React doesn’t personally give me space for that feeling. VC-backed-infinite-growth-SaaS-centric development is a narrow but intrinsically visible slice of the software world, and an area where it often feels to me like development has become less about the simple functionality someone set out to build, and more about the proliferation of dense ecosystems of modules to slather a simple webform with more layers of microservice handler abstraction than the number of dynos your app is serving from.

I fill your ears with these experiences not to promote a specific framework or approach, nor to imply that you shouldn’t use React if you personally enjoy it, but to illustrate different use cases where React is specifically beneficial versus ones where it gets in your way.

But what should I use?

The capabilities and underlying implementations of different web frameworks are of course vastly different — two-way data binding causes hugely unavoidable problems past a certain degree of dynamic interface loading that React’s one-way binding handily gets around. However, the complex data flow that makes the React ecosystem (with all its associated data management frameworks) effective at scale also makes it annoying to use when you don’t need React.

Would you use an industrial-strength data engineering framework to schlep around a couple of 4MB spreadsheets? That’s what it feels like to me when I see a thousand lines of React being used to build what should have been a simple webform. (If the industrial-strength data engineering framework just happened to already be all set up and you were extremely accustomed to that framework, you might indeed use it. But if not, no. You would probably use a bash one-liner, or maybe Google Sheets.)

In summary: if you are asking “what should I use for my frontend framework?” and your goal is to make a webapp for fun, maybe feel it out first with a little vanilla HTML or a mockup. As soon as things get annoying, google “frontend frameworks”, skim some quickstart pages, and use whatever sounds like it will feel natural, fun, and easy to your brain. Something simple and lightweight like Angular or, hell, even jQuery will get the job done and give you a speedy introduction on how logic connects to interfaces, while taking up literally 10% of the time and code volume of the equivalent React. You can still use React if you want; it is merely not a requirement to do so.

If your app specifically requires you to continuously poll changes every few seconds, or a nontrivial volume of your page elements are dynamically generated via infinite scroll, or you are building a social media website, then yes, by all means, it will save your sanity to React, Redux, and Flow the heck out of that bad boy.

For everything in between that you’re not getting paid for, contemplate your goals, consult your heart, and don’t forget to have fun.