The modern front-end development world is far too complex... Or is it? The narrative seems to be that React (and other complex frameworks) should not be used for simple sites or small projects. But why? And is there even a downside?

Depending on which programming circles you frequent, you might be aware of this issue which often comes up when discussing the complexity of modern web-development: the overuse of complex frameworks (namely React, Vue and Angular) for simple projects like blogs and personal sites.

Specifically, this article was inspired by Am I Principal Skinner? Complexity of front-end is just baffling to me now from r/webdev. But posts like these pop up regularly on many communities all the time. There's almost always an article about how "you shouldn't use React for X", so I thought I'd throw my hat in the ring and play devil's advocate for a while.

"You shouldn't use React for building websites"

Or so some would say. The argument I've seen repeated ad nauseam is that React is far too complex to build a website with, as HTML, CSS and a sprinkle of Javascript are all you need to make a beautiful and functional website. I can hardly even blame people for making this point, as at its core, it's true.

React is (or was) built to be used in complex apps that require a lot of interactivity. I think this was specifically during the time of Class components, where you'd have these massive components with complex states and logic, but nevertheless that was the aim of React at its inception.

Since then, the ecosystem has seen some pretty big changes: hooks have simplified the logic and Next.js made it easy to start a project (with server-side or static content) without having to bother setting up routers and whatnot. And I think this is why people get confused.

Their arguments are usually:

• A website doesn't need that much reactivity
• It adds a lot of complex overhead to something that should be simple

Which are both absolutely fair. But this doesn't mean there aren't a plethora of good reasons to use React (or any other front-end framework) for websites. After all, this is what a staggering number of devs do regularly, but why?

Why I use React to build websites

I legitimately think that people who believe you shouldn't use React for websites are simply confused, or haven't thought it through.

F*ck useState, it's all about the templating

Here's something to think about. The site you're reading this on was made with React, and in its whole codebase there are exactly three instances of useState, all for simple hooks.

In general, I barely use any of React's built in functionality when building sites. That's because, as many people point out, your website will likely never need it.

What I absolutely love about building sites with React is its templating engine. This allows me to build a component, add as many props as I want to it and be able to reuse it in any other part of my site. I can't even begin to describe just how much repetition this saves me even for something as simple as a website.

Other templating engines like Nunjucks offer similar functionality, but lack the slickness of implementation actual frameworks offer. This is because when using something like Nunjucks:

• Props can't be typed
• Template imports are non-standard and vary between engines
• Components can't have their own internal logic

That's not to say the existing templating engines aren't good, but why should anyone settle for a lesser implementation if React already offers the full package? The amount of setup I need to do to get my IDE to understand the template-specific syntax is enough to make me want to switch.

Build it and optimise it for me please

I don't know if anyone else but me remembers this, but there was a very specific time in website development where you had to minify code manually. In the 2010's especially, the process also involved uploading files manually with an FTP.

Some people somehow look back at having to open up an FTP client to make changes as a "better and simpler" time. But I really cannot relate to that.

Adding a build step to my code doesn't just mean I don't have to worry about my JS and CSS being minified and automatically compatible with multiple browsers (because who the hell can remember every browser's quirk?) but also that I can rely on an automated pipeline to put my website online without having to leave my IDE!

What does this have to do with React? Nothing. Anything can have a build/optimisation step, but if I use Next.js all of it is already set up for me. I don't have to mess about with Webpack settings I frankly don't understand. I just need to know npm run build does most of the work for me 🤷‍♂️.

The ecosystem is simply too good to pass up

The reality is that there's a lot of fun packages available for React. Granted, you might not need them for a website, but the day will come when you'll need to expand your site from a simple static page to have some more interactivity.

• Need some complex components? Go download some and style them as you want
• Want to animate something? Have you seen what you can do with React Spring?
• Need icons and don't want to manage 200 SVGs? Just get one of the hundreds of icon packages available

I could go on all day listing my favourite packages, but I think you get the point. It's not like you can't download pre-made components or animation libraries to use with standard HTML and JS, but they'll never be quite as good as the ones available for React.

Why even separate HTML and Javascript?

I don't know who needs to hear this, but you don't need to pretend like you enjoy having your HTML and Javascript in two separate files. Especially if the Javascript exists exclusively to interact with your HTML.

Riddle me this: does it sound like good code if you have a button in a template but need to switch to a Javascript file to check what listeners have been added to it? How maintainable do you think that is? Your IDE will give you zero hints about where the listeners for a specific element are. It might make sense to you, but it won't be easy for someone else to figure out.

How about loading content with AJAX from an API? Are you just planning to leave comments all over your template to help whoever inherits the code?

Of course anything that's possible in React is also possible with vanilla HTML and Javascript, but it requires working around issues on your own, and you shouldn't need to do that. You should just be coding and building the best site you can.

Static site builders can't save you

There are dozens of static site builders that hope to simplify the sheer mess of a vanilla HTML and Javascript project, but no matter what they do, it just looks to me as if they're just trying to re-build React's component system.

At that point, why not just use React, or Vue or your framework of choice? Projects like Astro are great, though at that point you're essentially using yet another framework!

On top of the Static Site Builder of your choice (which will require understanding its own unique internals) you're then also going to need to choose a specific templating engine, which has implemented common functionality in its own way.

In trying to "simplify your stack" you've just managed to add complexity to it. And I can assure you it will be more difficult to find someone that understands the internals of both your Site Builder and your templating engine than it is to find a React developer.

Moral of the story

Look, I don't care if you want to use ASP .NET to make a site or build it using HTML 1.0.

The moral here is that you can do whatever you want, yes, but don't make the mistake of criticising devs who use React if you haven't gone down that route yourself and seen just how beneficial it is.

React objectively has better DX because it was made to be maintainable for giant projects. Does it mean you shouldn't use it for your blog? F*ck no. Make your code maintainable however you prefer.

But God, please, stop writing articles about how it was easier to write sites in the 2010's. It sucked.