Recently I’ve been reviving 2 years old Django application (myplaces)  (from version 1.5.5 to latest version 1.9) and I was very unpleasantly surprised how tedious it was.   As Django  evolved  some features got deprecated and removed and must have been replaced in the code.  And it’s not only Django but also other contributed libraries are evolving as rapidly.   In my application I was using django-rest-framework,  which changed so significantly in version 3, that I cannot use it in my application without basically rebuilding the whole application.

Some of the changes might be necessary, but many where just cosmetic changes in names ( mimetype -> content_type, etc.), which I do not see as much of value add.  Even core python still keeps bit of naming fuss in favour of backward  compatibility ( for instance string.startswith, string.endswith made it till ver.3,  even if they are not in line with PEP008 – python naming standards).

But it’s not only about changes of interface between versions (there is a fair process to deprecate features so when one follows development,  it’s relatively easy to stay up to date), but it’s mainly all concept of the Django. Django was created more then 10 years ago, when web development was focused around servers and everything happened there.  But situation changed radically ( as I have written some time ago).  Now a lot of things is happening in the browser and you can have complete applications running  there (recently I discovered this cool application, which is running almost completely in the browser, it’s just using  a stream of events from the server).  Accordingly servers now are used more to provide APIs to browser applications or to route real time communication to/from/between browsers.

Theoretically you can do all this new great stuff in Django (as I have tried  in myplaces application), however it always needs some add-ons (django-rest-framework for RESTfull API,  gevent-socketio for websockets and socket-io real time communication) and overall it does not feel so great, because new stuff have to match with the old concepts.  Django is quite large and rather monolitic framework, so anything added to it must really try hard to fit in.  As a result new features are bit artificial,  and you need to really understand Django well to see how they should be used.

So where this  article is leading to?  For me to the simple conclusion that I’ll try to avoid Django in my future projects. It has been nice 8 years or so and I’ve learned a lot, but it’s time to move on.

There are surely now many valuable alternatives to Django.  In python world it’s for instance Flask, which I have used in couple of my recent small projects.  Flask is generally much more lighter then Django, so it’s easy to start a new project and whole development there feels much more ‘natural’.  Of course out of box it does not provide so much functionality as Django, but what is there feels really good ( configuration, Jinja2 templates, session management etc.). And it’s easy to add functionality from tons of available extension ( like advanced authentication and SSO with SAML2, which I used recently).  There is a risk there that Flask does not so firmly control the application architecture as the Django does, so one can easily get  into real mess, but on the other hand one can customize application  for specific use cases or technologies more easily ( like using No-SQL data stores).

Outside of Python world there are many interesting possibilities, for instance now very popular Node.js with it’s apps servers like Express.js, Loopback, which enable by default many new technologies and approaches (see this post by Django contributing author Jacob).  Or for curious seekers like myself there are other more weird and technically interesting web frameworks like Eliom (see this article about my experieces with Eliom) or something even more obscure like Opa (again see my article about Opa experiences).

“Farewell, Django, king of web frameworks, whose long and faithful friendship those who knew you won’t forget! “