Do I NEED to Combine Django with Vue or React?
It’s really easy to get caught up in “tech for tech’s sake”. Using new stuff is not a bad thing. The problem consists of opting for something just because it’s new and popular.
People who are relatively new to Django seem to be drawn to frontend frameworks. It’s completely understandable - that’s what everybody seems to be talking aboutthese days. Articles are telling about ways of building your Vue or React SPA, people on forums are asking about it.
Every time the topics comes up, somebody will mention single page applications (SPA) or progressive web application (PWA). God forbid they will strongly recommend to build one of them and never look back.
You can’t help but wonder: is it really that bad if you’re “only” using Django templates styled with Bootstrap and sprinkled with jQuery?
The short answer
No, you’re not doing anything wrong by not-using a frontend framework with Django. There’s no unwritten law that everything has to turn into a SPA, or be rewritten from scratch in React. Your project can be awesome without them, and you won’t miss out on much.
Go you! Now that this one’s out of the way, let’s go a bit deeper to help you approach similar questions in the future.
Let’s talk about the why behind using frontend frameworks.
Why are SPAs a thing?
The most popular use case for Vue and React are single page applications. With the SPA approach, the frontend and backend become almost separate projects. They only communicate via an API to exchange data. This has upsides, but also costs.
First, let’s look at the legitimate reasons why people decide to split up the frontend and the backend, building an SPA:
- A clear interface between the frontend and backend team. This is great for making work easier. You only need to know where to put data, or where to get it from. As a frontend developer you only care about the API design, and not about the backend stack.
- Separation of concerns, less room for interference. Backend and frontend developers can focus on their own code, stack and the tools they know well. A frontend developer does not need to learn Django to fetch data via the REST API.
- Making it easier to deploy either the frontend or the backend part, without redeploying the other. It can be frustrating when deploys are very slow, or blocked for small changes.
- Smoother user experience, with less loading times and less perceived transitions - data is fetched in the background, and only a part of the page is reloaded. With Django templates, you are reloading the page completely with each click.
- When you have multiple types of clients (web, mobile), the backend still only needs to provide one API. This saves work on the backend side of things.
As you see, most of those are about a team of people, working together smoothly. Those upsides don’t come for free. Here are some things which become harder when you’re choosing to build a SPA:
- Now the team is working on three projects instead of one. You need to implement the Django backend, the API and the new frontend project as well. This adds complexity.
- Simple things can become harder - you might need to figure out how to authenticate your frontend session with the backend, and how to bass CSRF tokens correctly.
- You lose some of Django’s built-in convenience - form rendering and validation will not work out of the box as it would Django templates.
- You’ll have duplication of effort. Logic might need to be implemented in the backend and in the frontend.
- You’re dealing with a more complicated tool stack because more tech is used. You’ll have to make more things work together.
- Depending on your project, SEO concerns may arise. There’s some work involved to make your SPA play nice with search engines.
- The loading times may go up, if you’re not careful with the size of your frontend bundle.
When you’re wondering if you should transition your app to a SPA, here are some questions you can ask yourself:
- Is your team growing, and do frontend and backend developers struggle with frequent merge issues?
- Are you prepared to handle the additional complexity of providing an additional API and having two somewhat-independent projects instead of one?
If you don’t have a clear YES for both of those, you might not want to go the SPA route.
You probably felt like the list of questions above was not quite complete. I totally left out the cool user interface upsides!
- Would your product benefit from a smoother-feeling user interface?
- Are whole-page reloads an issue?
- Would you like to make your frontend more dynamic without having to touch jQuery?
Well, the above sections was about whether you should go the SPA way. Frontend frameworks can help you with those aspects, but you don’t need to build a SPA for that.
Using a frontend framework without SPA overhead
Good news if you did not like the SPA downsides: going full-SPA is not necessary! You can get the benefits of using a frontend framework without the complexity and costs of a SPA.
Vue.js is designed to be incrementally adoptable. You can define complex, dynamic user interfaces and get that smooth SPA feeling without having to take a leap of faith first or rebuild your site from scratch.
You can integrate Vue.js into your Django templates piece by piece, to get a bit more reactivity where it matters. Vue can be used like (or instead of) jQuery, to spice up single templates and add interactivity incrementally.
If you want to try Vue.js with your Django project, you can follow this approach without having to design a REST API up-front. You won’t have to create new views, rethink your url patterns, change your deployment or introduce Webpack.
Your Django project does not NEED a frontend framework, but it’s quite simple to give it a try with Vue.js. You can see if your Django project can benefit from using a frontend framework, and learn by doing instead of making a hard decision up-front.
It’s easy to get started! Go ahead and add a dynamic component to your site. Or pick a template where you’re using jQuery to manipulate DOM elements and try to replace it with Vue. Just keep SEO in mind, and you’ll be fine.