
Using VueJS Alongside Django - tkainrad
https://tkainrad.dev/posts/use-vuejs-with-django/
======
willio58
This is great, thanks for writing it!

I have recently stepped out of the seemingly never-ending spiral of using
React/Vue for everything frontend, and also discovered Django along the way.

For building prototypes, Django is the fastest framework I've ever used. After
building out prototypes in Django I've come to a realization that at most 10%
of my websites need to be truly reactive to user interaction without page
reload. Turns out when I dropped this requirement when building something, I
can actually finish the projects I start. And also turns out for the end-user,
they don't even notice page reloads for most sites.

~~~
jkcxn
I totally agree. Full page rendered app are way easier to code. It's like an
immutable function - request in, transform, html out. I think as soon as you
want to add some niceties with React you end up setting up a load of front end
stuff. You suddenly need APIs, create-react-app, webpack, babel, build
scripts, redux, routing etc. And you also end up losing out on some of the
Django side, forms+validation, templating, views, urls. And often you end up
having business spilling over to your front end.

I'm working on a project that lets you build your Django app like you normally
would with templates and views but you get a React app and all the benefits of
a single page app. You don't need to write any APIs or use redux etc. It will
have a bunch of components built in and if you don't need any more then you
don't even need to build the javascript yourself, you just include the already
built file. At the moment I have a sort of Django Admin equivalent example
working and I'm looking for some feedback. If you or anyone else has any ideas
about it I would love to hear, feel free to PM me (email in profile).

~~~
andybak
Are you aware of pjax, turbolinks and (stepping up a bit from this really
minimal baseline) intercooler.js?

Curious how you feel your project fits in at this end of the ecosystem.

~~~
joss82
Intercooler is fantastic and integrates well with Django.

------
rojoca
I totally understand people's preference to use Django templates wherever
possible, and only sprinkle in more frontend focused stuff when needed, but
personally, I would rather just write the whole frontend in React or Vue.

This is probably partly due to the fact I find working with django rest
framework serializers / views to be much nicer than django forms / views.

I think what puts most people off is the default requirement to go all-in and
create an SPA with global state management and client-side managed routing,
but this isn't actually necessary.

I have found incorporating Django with
[https://inertiajs.com](https://inertiajs.com) to be a pretty solid
alternative. I can write the whole frontend in React, and the backend in
Django rest framework, but everything is still page based, so I don't require
redux or any other kind of global state, just use the inertia utils to make
page transitions.

NextJS is another alternative. To talk to a (django) API you need to go
through getStaticProps and getServerSideProps which, depending on the location
of your API server, can be a little slow, but you get pre-rendered HTML and
page based routing so again no global state management required.

~~~
evv555
>I think what puts most people off is the default requirement to go all-in and
create an SPA with global state management and client-side managed routing,
but this isn't actually necessary.

There's also the benefit of being able to lean on Django patterns for
sessions.

~~~
rojoca
Since inertia runs in the same session context as your django app you can use
django sessions as you would in a standard django app - in fact this is the
goal of inertia. This even works with a django rest framework API

------
andrewstuart
I have a Django application which I wanted to connect to from a ReactJS front
end.

However I did not want to lose all the business logic and work that had gone
into the views, models, forms and fields along with all the validation and
authentication logic etc.

So I wrote some React code that grabs Django's HTML forms and dynamically
turns all the HTML fields into React components. To do updates I just submit
ordinary form data from React. This means I just create ordinary Django
application forms and views and it works from the React app.

There's pros and cons to this approach. The code that does the HTML form to
React form logic is more complex than I would like. On the other hand it's all
constrained to a fairly tight area of React. Then there is the huge benefit of
being able to make zero modifications to the Django back end. On the con side,
it does feel like a bit of a frankenstein application. But its a small price
to pay for not having to convert entire Django apps into API's.

I actually have lots of mini React apps at the front end that are loaded onto
ordinary Django HTML template.

~~~
mooreds
I did that with the google web toolkit a decade ago. It was great for
enriching functionality, but didn't work with the overarching GWT architecture
(which expected to control the whole page as an SPA).

Is react happier being a component on page?

~~~
andrewstuart
>> Is react happier being a component on page?

I asked Dan Abramov (a lead React developer) the same question and he said
yes, indeed this is exactly what facebook do - they progressively added more
and more small react components to their HTML pages.

In React you can also use "portals" to render to multiple HTML elements on an
HTML page so you can do it both ways - one React app represented in multiple
places in the DOM or you can just create many small React apps and plop them
in multiple places on your page.

------
wilsonfiifi
I really love Django and Wagtail but I just can’t stop writing Go(lang) code,
it’s just so addictive. It’s a pity there aren’t any WSGI servers written in
Go that Would allow you to intermix Go and Python code seamlessly. Kind of
like what Roadrunner does for php [0]

    
    
      [0] https://github.com/spiral/roadrunner

------
code4tee
Nice article. People sometimes dismiss Django but it’s been around for a while
and is certainly the fastest framework for building out new ideas that I’ve
seen. It’s my goto framework for prototyping.

I find too many teams are so focused on using the latest fancy frameworks that
they spend way more effort to build something using “new stuff” that could
have been done in half or a quarter of the time with something like Django.
For most projects, simple that’s built and works beats fancy that’s still
being built.

~~~
postpawl
I saw a really good reddit comment about this topic recently (server side
templating vs client side). Tl;dr: when things get really interactive/dynamic,
the js framework simplifies things.

“Server side templating can work really well when the website is static. The
problem is that as you add more and more dynamic elements, you either have to
go to the server and re-render everything with every change (which can be
slow), or you can make the changes on the client side with something like
jQuery. But the latter option presents a challenge because you'll eventually
find yourself duplicating functionality.

For example, imagine a to-do list website that you render on the server with a
templating language. It fetches the user's to-do items from the database and
then renders the list. Now let's say you want to let a user add a new item
without re-rendering the entire page. You could use AJAX to tell the server to
add the new item, but now you need to update your UI list accordingly. You
could use jQuery to construct a new DOM element and append it, but now that
list element exists in two different places: in your jQuery code and in your
template on the server. If your website becomes very dynamic, this situation
can get really unwieldy from a programming perspective.

Both Angular (from what I've read) and React (from personal experience) are
highly suitable for creating single page apps, with the goal of creating a
dynamic, fast, and maintainable website. There are other benefits, as well as
downsides, to using Angular and React, but I hope this clears it up a little
bit. Both of them make server side templating unnecessary by moving UI
logic/rendering from your server to the client's browser. So a user who visits
your React powered to-list website would get the React code as a JS bundle, it
would make an AJAX call to your server to get just the data, and then it would
render the UI based on the data." -/u/VertiGuo
([https://www.reddit.com/r/node/comments/6t22cr/back_end_templ...](https://www.reddit.com/r/node/comments/6t22cr/back_end_templating_engine_or_front_end_framework/dlhukkf/))

~~~
conorgdaly
> You could use AJAX to tell the server to add the new item, but now you need
> to update your UI list accordingly. You could use jQuery to construct a new
> DOM element and append it, but now that list element exists in two different
> places: in your jQuery code and in your template on the server.

Your server can just return html which is ready to be inserted into DOM. You
don't need to duplicate the node view creation logic client side.

~~~
postpawl
That can get pretty complicated for pages with a lot of dynamic elements. For
example, if you submit a form and have to re-render the form with an error.
All the hidden “ready to be inserted into the DOM” elements also need server
side code to re-render things the same way. For pages with a lot of dynamic
stuff, it might be better to just build it on the client side and use an API
with server side validation on the server side.

~~~
conorgdaly
> All the hidden “ready to be inserted into the DOM” elements also need server
> side code to re-render things the same way.

There seems to be some confusion. With your list example, you still make an
ajax call to create a new ToDo, the server returns html which is inserted into
DOM.

You'll be making an ajax call anyway, except instead of just 200 reponse/json
, you'll get html. This is server side rendered. There is no """hidden “ready
to be inserted into the DOM” elements"""

Yes, forms are something which, depending on complexity, can be better served
with SPA type solution.

If it's not complex, I'd still keep rendering server side and just add small
bit of JS logic to update form header to add/remove to error list and just
replace form input field with server response.

~~~
postpawl
Yeah, the TODO list example probably isn't a good example for a complicated
scenario when avoiding server side templating makes sense.

------
mythrwy
Vue and Django (with Rest Framework) are a great combo and I've used them
together to build two reasonably sized apps recently.

I don't know if I'm doing it wrong but I still use Gulp to compile everything.
I use Django for the routing and intermix a tiny bit of dynamic server-side
data (like login user or breadcrumbs) in the Django templates before they go
to Vue.

Doing it like this I skip all the component complexity (I do use mixins) and
can build front end with simple tools I understand. Possibly I could avoid a
little repetition by using components, but the increase in abstraction I don't
think would be worth it.

This is fast to develop. I've seen less complex single page apps using React
or whatever take what seems like a lot more effort. But like I say, maybe I'm
not doing it right. It works really well though.

------
sgt
Been using Django alongside VueJS as well. It's a very efficient way of
building your web app.

That being said, mostly it's just a couple of pages that need VueJS such as
e.g. a dashboard and such (depending on your app of course!).

If you use standard Django with Turbolinks it will give you the SPA "feel"
that you require.

------
rurp
This is a great read. I had considered using React with a Django side project
a while back, but it just seemed like too much added complexity for the gain I
would get in a small app. The approach in this article though looks great.

------
alphanumeric0
This is similar to what I've done recently with a project of mine using Django
+ Elm
([https://github.com/ereadingtool/ereadingtool](https://github.com/ereadingtool/ereadingtool)).

I wrote an adapter of sorts, between Django and the frontend, which is a
Django base template specifically for the pages loading compiled
Elm/JavaScript, that turns Django view context data into a JavaScript data
structure that gets fed into the Elm code. In this way, the frontend
JavaScript is initialized and ready to go without more page fetches. If I need
to pass some extra data to it, I can simply add it in to get_context_data().

I like the idea of re-using everything Django has to offer but also being able
to pass a few parameters into Elm and have it handle the view side. Where I
get into trouble is when Elm and Django code both have to agree on data
formats and schemas, but this is more my fault for not strongly abstracting
the API.

------
zmmmmm
One of the reasons I have ended up choosing Vue over React as my preferred
front end framework is exactly that it can integrate at these different
levels. If you want to write a full on SPA it will do that. But if you want to
have a 99% traditional server rendered app, and you just want to sprinkle a
component here or there, it does that in an extremely light weight manner.

But the most likely scenario? You have both: new apps being developed as SPAs
and some older ones being maintained and the nice thing is it is very non-
intrusive share Vue components between them by dropping a script tag into the
legacy page.

So it's both legacy compatible, current-tech compatible, and my prediction is,
better positioned for forward compatibilty with whatever comes next for the
same reasons.

------
ivan_ah
> This post aims to show that you can start to use Vue with your Django
> projects immediately without any sophisticated setup that will take hours to
> complete. Therefore, we will use the simplest method to use Vue.js:
> Including it via a <script> tag.

Nice. Yeah, sometimes it's easier to get started this way without investing a
day in getting webpack working...

When the time comes and you need webpack, then this package has been known to
help the integration between the frontend build system (webpack) and django's
static file serving functions: [https://github.com/owais/django-webpack-
loader](https://github.com/owais/django-webpack-loader)

~~~
PascalW
I've tried setting up django-webpack-loader but it felt very heavy handed and
I didn't like how it forces you to use some non-standard manifest plugin that
was pretty buggy.

Instead I went with vanilla Webpack outputting files into Django
`STATIC_ROOT`. That way Webpack is only concerned with producing the files and
Django handles the whole file name hashing, compression etc in production.

I've found this to be much, much more straightforward. I'm planning to write a
post about it.

~~~
ivan_ah
Yes, please blog post this. I'm curious to see how you inject the right bundle
hack name (js side) into the django template (Python side).

> non-standard manifest plugin

I hear you, and this feels weird to me too, but then again node-land needs to
talk to Django-land somehow so writing a .json file doesn't seem all that bad
way to do it ;)

~~~
PascalW
It's up here: [https://pascalw.me/blog/2020/04/19/webpack-
django.html](https://pascalw.me/blog/2020/04/19/webpack-django.html)

------
dtjones
Vue and Django work very well together. However I'd recommend completely
decoupling the frontend and backend source code - and avoid using django
templates entirely. Instead expose REST endpoints using django rest framework

~~~
CameronNemo
Why? Server side rendering is often fast and well suited for pages with mostly
read-only content.

~~~
dtjones
Yes, serverside rendering is generally more performant than a decoupled
client/server-side approach. If server-side rendering is a requirement of the
project I'd look into nuxt.js + vue

I was commenting more generally on the approach to building a web app with
Django and including external js libraries in Django templates, which I've
done in the past as project requirements have changed over time. After
including external js libraries to Django templates, there is a lot less
support in terms of resources and supporting libraries such as testing
frameworks. If the client-side project is initialized with Vue, the project
can benefit from the overwhelming amount of supporting resources.

------
is0tope
I wrote my Clash Royale streamer tracker
([http://playedwith.io](http://playedwith.io)) using this exact combination.

Backend: \- Django Rest Framework \- Django Background Tasks (great for
running cron like jobs, and simpler than celery)

Frontend: \- Vue SPA

All of this runs on docker-compose, with nginx used to route traffic to either
the backend API or frontend files that were built using Vue-Cli.

Very happy with this stack. It's not super advanced, but it is easy to get up
and running and quick at prototyping.

------
koyote
Slightly off topic, but I really like how this site uses the left and right
whitespace on larger screens.

One of my minor frutstrations around having a large 4K monitor is that a lot
of websites (especially blogs) force the width of the text to be very small
and I end up with massive whitespace on the sides. Although this blog still
has a small width for the main text, the sides are not wasted!

~~~
tkainrad
Thank you! The site is created with Hugo, as described in this post:
[https://tkainrad.dev/posts/using-hugo-gitlab-pages-and-
cloud...](https://tkainrad.dev/posts/using-hugo-gitlab-pages-and-cloudflare-
to-create-and-run-this-website/)

I used the Coder theme ([https://github.com/luizdepra/hugo-
coder/](https://github.com/luizdepra/hugo-coder/)) but made quite a few
changes over time. These changes include a slight increase in the main
container width and the addition of information on the sides.

I really have a hard time reading long posts where I cannot see a TOC on the
side, so this was a priority for me.

------
vital101
I've been using Django with Vue sprinkled in on
[https://candid.work](https://candid.work) and it's been a pleasure. Using Vue
for reactive stuff and then modifying form fields after the changes so Django
can still do the updates has been a pretty great experience so far.

~~~
Nextgrid
Off topic but did you use an off the shelf template for your actual
application? The screenshots look very familiar for some reason.

~~~
davidu
It's [https://startbootstrap.com/themes/sb-
admin-2/](https://startbootstrap.com/themes/sb-admin-2/) which is free.

------
Stephen0xFF
I feel the only way these two will play nicely is swapping Django for a DRF
approach. Vanilla JS could be, and perhaps should be, used in place of Vue for
small use cases. There's no need for the extra abstraction when AJAX could
work.

~~~
mythrwy
Well you "could" spit out data from the views as JSON into <script> blocks in
the Django templates and they would play nicely together.

But then you would be limited to various manipulations of the initial data so
"could" is certainly not "should".

~~~
postpawl
Can’t you also pass data into components by using server side templating to
fill in props on the component?

Like this:
[https://stackoverflow.com/a/56461472](https://stackoverflow.com/a/56461472)

------
srich36
Interesting article! Another approach is serving webpack bundles from Django
views. This allows you to take advantage of the entire node ecosystem and
build process (for better or worse) while still utilizing Django
authentication, etc. Writing single file Vue components (with hot reloading)
and bundling them is definitely more enjoyable than writing static files for
Django. If performance is a concern, you can always optimize with webpack in
this approach, whereas optimization may be harder in methods such as the one
this article suggests

------
mherrmann
I recently also coded my first Django/Vue app. Here's what I really liked:
Have _all_ business logic on the server. The user clicks a button? Tie this to
a function on the server that receives the client state from Vue and responds
with the new state. This way, all business logic is in very simple Python
functions that essentially operate on a JSON dictionary.

The above approach only needs very little generic wiring. The caveat is that
it probably only works when there is little client data, which was the case
for me.

------
Pandabob
I've been building a web app with Django (+ DRF, Next.js and React) recently
again for the first time in two years and it sure is a joy.

My biggest gripe with it is that it leaves the business logic side of things
totally up to the developer. While many like it this way, I'd find a cookbook
of sorts helpful with reference implementations on stuff like fat models or
service layers. This is something Next.js has done very well with their
examples hosted on Github.

------
jilles
I am currently working on a personal project using Django and Django Rest
Framework purely as the back-end. My front-end is a React app.

Because I just use django+drf for the api, I thought about using Flask + Flask
REST.. However, after having worked with Django over 3 years, I found the
learning curve quite steep.

Do you intend to use Vuex and/or Vue router at some point?

------
sireat
Would be nice to see a semi complete project using VueJS with Django
integrated as closely as in the article.

Something along the lines of:
[https://github.com/gothinkster/realworld](https://github.com/gothinkster/realworld)
which covers front-end and back-end separately

------
stanep
if you use [https://www.transcrypt.org/](https://www.transcrypt.org/) you do
not need node.js and with little work you can write Vue apps like this

class MyApp(VueBase):

    
    
        def __init__(self):
            self.el = "#app"
            self.msg = "Hello from vue class"
    
        def created(self):
            print('Created')
    
        def v_show(self, evt):
            print('show method', evt)
    
        def computed_title(self):
            return self.msg + " Computed"
    

app = MyApp() app.mount_to("#app")

#Vue methods declare with v_ #Computed and watch with computed_ and watch_

------
dzonga
alpine.js or intecooler.js will neglate the need for vue.js altogether. I have
moved away from the SPA approach even though I have worked as frontend dev.
html rendered on the server all the way with sprinkles of js.

------
zaro
Ah yes, Vue in Jinja. What's better than embedding template in another one and
both languages use the same interpolation delimiters.

------
pier25
TL;DR: the idea is basically to write the Django data from the DB into a JS
object and then use that to feed Vue components. I imagine they do this only
for the stuff that uses Vue and not the whole page markup.

Vue is a great option to combine with server rendered markup (PHP, Python,
etc) because it can read the templates directly from the DOM and doesn't need
a build step like JSX does.

It's not the only option though. You could also use Preact + Htm (JSX in
string templates) which doesn't need a build step either and is much smaller
than Vue.

[https://github.com/developit/htm](https://github.com/developit/htm)

------
clubdorothe
Anyone has a similar "how-to" article on how to do this with Flask and Vue?

