DjangoCon 2021 | Rewriting Django from almost scratch in 2021 | Emma Delescolle

One of the decisions that was made 15 years ago was to use home-made code for everything. Django depends on very few libraries. Django doesn't use anything from the Python eco-system, when it comes to ORM, templates, routing, etc.

And that is a decision I would probably have done at the time as well. The Python world was much less welcoming at the time and documentation was still regarded as a second-class citizen. Let's not even mention the wrath you were taking the risk of exposing yourself to if you dared make a pull request on a project you weren't involved with.

Those choices are not the only reasons to consider a rewrite though... After attending several Django conferences, I noticed a few trends about what prominent Django developers would like to change. For example WSGI middlewares is something that's often put on the table, websockets is another of those things that comes up very often.

It is true that the world of the web is quite different today compared to what it was 15 years ago. It seems to me that today REST API's and websockets are first class citizens while server-rendered pages have become less important. Once again, that's just a personal feeling.

A complete Django rewrite is also not my very own idea, several people have been working on a similar idea. Tom Christie has been working on many libraries in order to be able to rewrite Django as an async framework in order to better accommodate websockets. Others like Tobias have been working on something similar but starting at the other end of the problem. I guess this is just my own version of that thought experiment.

For this thought experiment I will care about retaining the "spirit" of Django as I perceive it but I will not care at all about backward compatibility!

What does a Django rewrite needs to achieve in 2021?

• Batteries included: Anything that claims to be a Django-like needs to come with everything out of the box
• A friendly ORM with a syntax that is closer to the objects than to SQL
• Middlewares
• Sessions
• Authentication and authorization
• Routing
• Easy to build REST API's
• Websockets
• Template-based rendering
• Static files serving during development
• Easy documenting of API's
• MVC implementation
• Easy to use CRUD controller and associated views
• A powerful admin(based on its own CRUD controllers)
• Error management

This talk will cover all of those points, how they could be approached and whether using an existing Python library for that job might be a good idea

Code:

• Cordy (https://gitlab.levitnet.be/levit/cordy/-/tree/master)
• CookieCutter for starting a project (https://gitlab.levitnet.be/levit/cordy-project/-/tree/master)
• Demo app (Splendid) (https://gitlab.levitnet.be/emma/splendid/-/tree/master)

Demo: https://levit.be/uploads/Kazam_screencast_00003.mp4

Slides: https://slides.com/emma_be/cordy

Date Added: September 19, 2024