Few days ago, I started to work in new company. Before me, all front-end and backend code was written by one man.

As you know, Django app contains two main directories for front-end: /static - for static(public) files and /templates - for django templates

Now, we have large application with more than 10 different modules like: home, admin, spanel, mobile etc.

This is current structure of files and directories:

FIRST - /static directory. As you can see, it is mixed directories with some named like modules, some contains global libs.

static dir

one more:

static dir second

SECOND - /templates directory. Some directories named like module with mixed templates, some depends on new version =), some used only in module, but placed globally.

templates dir

and more:

templates dir 2

I think, that this is ugly, non-maintainable, put-in-stress structure!

After some time spend, I suggest to use this scheme, that based on module-structure.

enter image description here

At first, we have version directories, used for save full project backup, includes: /DEPRECATED directory - for old, unused files and /CURRENT (Active) directory, that contains
production version of project.

I think it's right, because we can access to older or newer version files fast and easy. Also, we are saved from broken or wrong dependencies between different versions.

Second, in every version we have standalone modules and global module.

Every module contains own /static and /templates directories. This structure used to avoid broken or wrong dependencies between different modules, because every module has own js app, css tables and local images.

Global module contains all libraries, main style-sheets and images like logos or favicon.

I think, this structure is much better to maintain, update, refactoring etc.

My question is:

How do you think, is this scheme better than current? Can this scheme live, or it is not possible to implement this in Django app?

  • One problem with your proposal is that if you have many modules and decide to update jQuery or AngularJS, you will have to do it in the global. You will have to guarantee that none of the modules get broke, if you got 50 modules, that can be a impossible task by the time can force you to keep the libraries deprecated in all of your modules.
    – RMalke
    Aug 17, 2015 at 11:42

4 Answers 4


By "module", do you mean app? Django already has a pretty standard structure for where to place files.

I suggest you consider using that structure. For one thing, just about all help you will get will have examples with this structure.

As for your structure, it looks pretty sprawling to me. It's up to you, though. In particular if it fits the business problem, you won't have issues navigating it.


The points that look ugly to me:

  1. Why not a Version Control System? Keeping versions on the local file system is not pretty. You can use versioning systems and add 3rd party javascript/css libraries too so added/removed/replaced javascript and css files will be trackable. You go go back or forth between revisions and check the differences easily.
  2. It is hard to develop a software whose modules needs different versions of the same 3rd party software. If your admin module need jQuery X while Products module needs jQuery Y, then you have problems. It is hard to maintain and it would be only you who knows why each module need specific version of jQuery X and why it can not run under jQuery Y. Since you have a full copy of each deployment on your local drive, You probably will not remember why A module is needing a specific bootstrap version. For different js/css files which are specific to a single module, you can create static directory under each application and place application-specific files in here. See this post as a reference
  3. Django have a well-planned template structure. You can do the same as you did to static files. You may have templates directory under each application and palce application-specific templates in here.
  4. Having application-specific templates and static directories is up to the developer. If having all files under the same directory looks ugly then you can choose the application-specific solution. Django will handle them both nicely. Especially if you have a lot of applications then you may have name collusions if all of your templates and static files are under the same directory.

Current form is much better than the old one. But I am sure you may get more better ideas if you check the Django docs and check SO/programmers for similar situations and solutions.


Yes. It is much better then how it was done previously. Moreover Django is also the right tool to do it. The reason for the same is, when we look at the base of the framework i.e. Django is this case is written in Python. Python believes more in Readability rather then writing the code itself.

So, yes the things you have done is much better in simple terms


I think that's a good structure but I'm gonna suggest you that don't use django template or any server side template technology. Imagine that in the future you decide (or not you, your boss) to implement some services in other server technology than python/django (ruby/rails, symphony2, J2EE, .NET), that way all you client side html templates are not usable. I think is a good idea to use client side templating like mustache.js and others.

Check this article: "https://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more"

  • 4
    Building a website using a tool, then throwing away one of that tool's best features, based on speculation of completely unknown usage in the future, is usually unwise. Mar 29, 2015 at 20:18
  • Never unwise decouple front-end from back-end, those technologies are 20th century, obsolete, look for trends now (SPA, angular, backbone, ember, knockout, node ... NO Server side templates NEVER MORE!) Sep 16, 2015 at 21:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.