Why You Probably Don’t Need React (or any other frontend framework)

Why we have frameworks

Web 2.0. User centred design. User experience. APIs. Single page application. Facebook, Amazon, Apple, Netflix, Google.

The web has changed over the last ten years. The largest websites in the world now serve hundreds of millions of daily users, tens of millions of users at any given time. It's no surprise that as the reach of web architecture in to every facet of our lives has grown, so too has the way we think about and approach the design and build of modern web applications.

In the early days of the web, most sites were simple brochure-ware; a few pages of static content with maybe a contact form or two. These sites were easy to build and maintain; usually built by one person or a small team, and updated infrequently. The technology needs for these types of site were also quite low; a basic understanding of HTML and CSS was all that was required to get started.

As the web grew in popularity, so too did the complexity of sites being built. More and more features were added as businesses saw the potential of what could be done online. These features included things like ecommerce functionality, user registration and login, dynamic content, and integrations with third-party services.

The technology needs for these types of sites also grew; a basic understanding of HTML and CSS was no longer enough. Developers now needed to be proficient in things like server-side scripting languages (like PHP, Ruby on Rails, Python), database technologies (like MySQL, MongoDB), and front-end JavaScript.

In the earlier days of this transition of the web from a library of linked documents to the interactive user-centred platform we would come to call Web 2.0, the most popular tool for working with JavaScript was jQuery. And it was necessary in its day; browser support for JavaScript features varied quite wildly, or required different script code to achieve the same outcome across platforms.

However, as browsers have become more stable and standardized, the need for jQuery has diminished. Modern JavaScript standards up to at least ECMAScript 2017 are supported by all major browsers. Ways of manipulating the DOM which used to be difficult have been made trivial.

Yet despite this standardization of the technology, the framework is still king. Sure, we don't rely on libraries like jQuery any more, but you've probably been told you need to use something like React, Vue or Angular now just to build a simple blog. There's a good chance if you work in the web space, one of these is simply the default used for any new projects. No architectural analysis, no thought about whether this is actually what you need, the justification little more than it's en vogue, it's what everyone does nowadays.

But frameworks like React were built to solve specific problems.

React was created by Facebook in 2013. It was developed as a response to the challenges of developing large-scale web applications. These challenges include managing large numbers of moving parts, updating content in real-time, and integrating with multiple data sources - where the demand on the system was hundreds of millions of daily users.

With the greatest respect, you're not Facebook. You don't have Facebook's problems. You might wish you had Facebook's problems, but your start-up with an MVP in progress and zero users just doesn't have the same demands of concurrency.

The vast majority of web applications do not need the overhead of React or any other frontend framework. You don't need the build tools, you don't need the boilerplate code, you don't need the abstractions. What you should be aiming for is the simplest possible solution that will allow you to get your product or service out there and in front of users as quickly as possible.

This is where agile development comes in. The agile manifesto, written in 2001, pre-dates React by over a decade. But its principles are more relevant than ever.

Agile implores us, in effect, to build working software in small, incremental units of development, testing and deployment, then to use what we learn from this increment to improve the quality and user satisfaction of the next one. An endless feedback cycle where our product is never completed (unless it's failed), just improved and grown.

Don't over-engineer simple problems

One of the most important development principles is often expressed as "keep it simple, stupid" (KISS). This means that you should not over-engineer your solution, or try to use a complex solution when a simpler option will suffice.

Introducing a framework like React too early can add a myriad of layers to your project, each of which require maintenance, testing, debugging, development experience and expertise within your team and other cost factors - but return little or even no benefit over a well designed, simpler monolith.

Scale when you need to scale

Just because you don't start with React, doesn't mean you can never use it. The key is to start small, with a monolith, and only introduce React when your project has reached a scale where the benefits of using a framework justify the significant investment required in order to introduce and maintain it.

By starting with a monolith, written in vanilla JavaScript (no frameworks), you are free to choose the most appropriate tool for the job as your project grows. If React turns out to be the best solution for your needs at scale, then you can always introduce it later.

But by starting with a framework like React, you are effectively painting yourself into a corner - it's much harder (and often not possible) to remove a framework once it's in place. So, if you don't need React - don't use it!

You ain't gonna need it

Another great development principle is "you ain't gonna need it" (YAGNI). This means that you should not add features to your project that you don't currently need. Don't have dozens of moving parts and shared state throughout your application? Great! You don't need to introduce the framework capability to deal with it just yet.

Don't be afraid to copy and paste

Yes, I really mean that. It's easier to maintain a well designed monolith which has been kept as simple as possible than it is a dozen API microservices in three different technology stacks, stitched together by a React monstrosity just to keep a catalogue of products with a user system and a Paypal checkout.

Yes, you might end up copy and pasting a bit of JavaScript when you start with the vanilla approach, you might have very similar functionality in multiple pages or places which definitely could be refactored one day in to a collection of components and general purpose utilities.

And yet you'll get better results from day one with copy-and-paste code than you will with the wrong abstractions, and once abstractions are in place they're very hard to remove.

So, don't be afraid of a little code duplication - it's surprising how often it's the best way to keep your project clean and maintainable.

In conclusion

I'm not urging you to write spaghetti code. I'm not saying you shouldn't use React, or any other frontend framework. I'm asking you to consider, before you start building anything, if a frontend framework is what you need.

You might be surprised with how much you can accomplish with simple fetch() calls to a backend which returns HTML (yes, crazy - your browser can literally just render HTML, straight from a server, no JSON, no shadow DOM needed!), a document query selector and a few event listeners.

If you do need the benefits that React provides, then use it - but only after you've considered the cost of adding yet another framework to your project.

This isn't theory. There are (or rather were) start ups which have failed precisely because they spent 16 months perfecting a state of the art, serverless, fully automated and no doubt awesome CI/CD pipeline, laid out the groundwork for a number of microservices and a shiny, sparkly Progressive Web App with UX to die for and only realised when the funding ran dry that in all the excitement, they forgot to actually build a product.

Don't let that be you.

If you're starting a new project, keep it simple. Build a monolith. Add frameworks later when (and if) you need to. Your users - and you will have users - will thank you for it.

---

Comments