Frontend Code Strategy with Django

Web development is getting more and more focused on front-end development. This leads to a lot of questions on what is the best way to handle compiling css, javascript, coffeescirpt, stylus, etc. Having been involved with a project where the frontend deals with 100+ files between stylus files, coffeescirpt files, javascript, and css. This is kind of crazy to manage without a good strategy or even knowing how to accomplish it.

How Frontend Code Works in Django

When working with django you need to consider how the code is going to go from your code base to be displayed in the browser. The normal path it takes is to live in a static directory which you edit and run locally. Then in production you do a collectstatic command and it moves everything to a folder for your webserver to pull from. With that in mind as long as the above happens you can do almost anything you want for your frontend code. Lets take a look at the 3 most common ways you can do front-end development with django.

Three Popular Ways to Write Frontend Code

Everything in the static folder

The most common way we start projects is to just stuff everything in a static file on the root of our project. We add img, css, and js folders to keep things organized. We then use the staticfiles app to use template helpers for loading in our static files without having to hard code them. This will get us a long way, and for most sites is a good approach, because lets face it most sites don't move past hobby projects.

To get this working about the only configuration you need is:


STATIC_URL = '/static/'
    os.path.join(BASE_DIR, 'static'),

STATIC_ROOT = os.path.join(BASE_DIR, 'static_final')

To see it in action you can watch a video here: Staticfiles, template filters, and commands

Third Party Django Library

The next step people often move to is using a third party django app which kind of takes care of everything for you. You set in the settings what you want to use to compile and preprocess code. The django app then does all the processing, finally outputing the final information where we tell it, generally from the settings above. It is fairly simple and straight forward to use these libraries especially since they don't really break your workflow, and you get the addition of using the latest cool technologies.

The two most populare packages I have seen is django-compressor and django-pipeline, a fork of compressor. Both are fairly simple to setup and configure, but they do have their limitations and oddities. I would recommend doing a side project with each to evaluate which one you like, to determine if it is right for you.

If you want to checkout a video for django-pipline go here: Compile and compress assets with django-pipline

Front-end Build System

The final way most often seen for building front end code is to use an entire build system outside of django completely. You setup your static file locations like we did above, and then you tell the independent build system to output your files there. Generally you would use something like grunt, gulp or brunch to do this. This method gives you the most flexibility and freedom, but is the most time consuming to setup and learn. If you heavily rely on front end code then this is probably the best solution, especially for single page apps.

Also by taking the time to learn some of these tools it helps you become a better all around developer through getting you involved in other things besides just django and python. Generally these build systems are completely custom, or based on something in the node.js world. Below are some of the more popular ones:

There is also a video on this method as well using gulp check it out here: Use gulp.js to manage static assets


Knowing what is the best way to build your assets is hard, I use all three methods in various projects. So I kind of take a tiered approach to know when to choose what method. If it is a small site where I am going to write it once and forget about it or maybe touch it a couple of times a year I don't worry about a build system at all, not worth the effort. If I am going to touch the code once a month on average I will generally use django-pipeline. However, if I am touching the code base 2+ times a month it means I am probably touching it more than that and I need to have the most flexibility, so I will use gulp.

These are the rules I follow, but I suggest you take a look at these methods and find your own sweet spot.

comments powered by Disqus