Yesterday, I completely removed any trace of React (and Typescript) from a project that I’ve been working on for a while (Non-Profit Link). But why?
It’s probably easier to tell you why I wanted to use React in the first place, and why those reasons were half of the motivation for me to remove React: Scalability, reusability, and, embarrassingly enough, just to be able to say that I’ve used React in a larger project.
Scalability ↗
Admittedly, I was a little bit hyper focused on the potential scalability of React. The components, strongly typed languages (as long as you’re using TypeScript, of course), and the overall neatness of it.
Well, lesson learned. Just because something can be scalable doesn’t mean it’s good for you or your project. Components are awesome, but only when you really need them. TypeScript was cool, but overall slow and obnoxious to work with (just in terms of this project, I still love strongly typed languages).
For example, this is just for a singular img element in a component!
export interface imgsInfo {
img: string;
alt: string;
link?: string;
}
And yes, React is neat and tidy, but that’s just more to manage.
Reusability ♻
Components are reusable, right? Right???
Sure, but that just means more files. More imports to manage. More things to make TypeScript lose its religion. More interfaces and props. Being able to reuse stuff is nice, but I simply didn’t need this amount of reusability.
“I used React with Django!” 📄
That’s what I wanted to be able to say, at least. But again, lesson learned. Just use what’s best for your project. Don’t worry about what might look good on a resume.
The other half of the “Why” ❓
Not to place the blame entirely on React, as I was the one who was absolutely starstruck by the ✨ scalability ✨ of React, however those features that I just mentioned were part of React. So, while I would like to completely blame React, that just wouldn’t be fair.
But anyways, onto what I was solely at fault for.
Django and React don’t like each other 🐊
Getting Django and React to play nice is like throwing a crocodile into a cage with a gorilla, and then telling them to shake hands and discuss the current economic situation of the world. They just won’t, and there’s no way to make them peacefully work together.
So what do I mean by that, in the context of Django and React?
The Two Options 🤔
I should first clarify what my two options with Django and React were. Either completely separate the frontend and backend, and communicate to the frontend through the Django Rest Framework (DRF), or use a bundler like Webpack to bundle your JavaScript (TypeScript, in this case), then load the JavaScript into each template.
The problem with using the DRF is that you get none of the advantages that come with Django.
For example, Django comes with a pretty sweet templating system. Without explaining it in depth, if you want to pass data from the server to the client, you can simply pass context to the template when you render it. In case you’re curious, it looks like this:
views.py:
return render(request, "index.html", context={"test": "test"})
index.html:
{{ test }}
Ignoring the imports in views.py, and the header info in index.html, it’s a grand total of (roughly) 2 lines!
Django also comes with user authentication, session management, and more. All the good stuff that makes development go quickly and smoothly.
I decided that if using the DRF removes all of the good stuff about Django, I don’t want to use it. So, I decided to use a bundler.
The bundler (i.e, the main issue) 🧵
This sounds like a pretty good setup, right? Well, I thought so, and I was incredibly wrong!
I could try and describe to you why this doesn’t work all that well, or I could just give you an example. So, let me show you what adding one <h1> element to a template named index.html would look like:
Add a div to index.html like so:
<div id="react-header"></div>
Then, go to assets/pages/index.tsx. Import any components that you need to make the header (in this case, none), then write this code to render HTML in the specified div:
ReactDOM.createRoot(document.getElementById("react-header")!).render(
<React.StrictMode>
<h1></h1>
</React.StrictMode>
);
Ok, we're done now, right?
Wrong. Now you need to transpile and bundle this code with Webpack (this took about 10 hours to get set up):
npm run dev
Webpack is kind of nice, as it does the transpiling and bundling all in one go, but it's still a pain.
Bundling can take anywhere from 1 second to 7 seconds (or more), and then, and only then can you see a <h1> element appear in the rendered template.
By the way, before you do any of this, you would also need to create and then work out the inevitable little problems with these files: webpack.config.js, tsconfig.json, declarations.d.ts, and .eslintrc.cjs.
As you can see, this is… incredibly painful, tedious, and overall, not a great idea.
So I removed React. Contrary to how long I thought it would take, it actually only took about 3 hours. And it was definitely a good decision.
Moving forward ⏩
As I learned, you shouldn’t just use something because it’s intended to work well, and you certainly shouldn't use something just so you can say that you used it.
Please do check out what the codebase looked like before and after I removed React. You can compare the differences here (commit before the removal of React) and here (commit after the removal of React). And guess what? The site functions just as it did with React, with at least 30 fewer files.
If I need a lot of functionality in the future, I’ll probably look into something like HTMX or Alpine.js. Otherwise, raw HTML, CSS, and JS are plenty sufficient.
What do you think I should’ve done differently, if anything?
Contact me:
oscar.gaske.cs@gmail.com
Github
The point of taking time to write TypeScript types is maintainability. Imagine this scenario: I just joined your project. I clone the repo and start playing with it. Without the types, where do I go look for, well, the types? Which properties does the data carry? Did you document this elsewhere? Probably not. TypeScript is your friend.