Stability without stagnation

Recently several different conversations around Django, stability, conservativism and/or breaking changes have caught my eye. Having been known a while ago in certain Python circles as "the Ember lady", I couldn't help but draw some parallels with EmberJS and the way they have been managing releases since several years.

Disclaimer: this post asks a lot of questions and provides absolutely no answer. My hope is that some of those questions might foster some fruitful discussions.

For those who have not been introduced, Ember and Django are two opinionated web frameworks with a strong and welcoming community, one is aimed at perfectionists with deadlines, the other at ambitious web developer but they both come with batteries included.

Stability is a big part of Ember's identity and for good reasons. For example, last time I was privvy to the information, Heroku who runs a significant portion of the web, was still using Ember for their dashboard. If that ever became unstable, I would think we'd hear about it!

Quite some time ago, Ember moved from the 1.x series to the 2.x series. Coincidentally, this was at about the same time Django moved from the 1.x series to the 2.x series. Ember 1.13 was an LTS and it introduced many deprecation warnings. Version 2.0 had many breaking changes and the upgrade path was painful for many, resulting in a lot of projects never moving on from the 1.x series.

This didn't go un-noticed and many things were introduced in the Ember release lifecycle, those include but are not limited to:

• a stricter release cycle with rules about deprecation warnings
• an RFC process was introduced (similar to the Django DEP process) with the entire process happening on GitHub
• feature flags for the library itself

The similarities between Django and Ember don't stop at them being being web frameworks with great communities. I will try to list here those that are most obvious to me and the way they differ slightly, starting with versionning since I've already broached that subject.

Before getting started thought I want to get something out of the way: It would be easy to assume the comparison is not fair, Ember being a bit of a niche Javascript framework, simply due to the sheer number of people doing React and Vue. Against Django, the leading Python web framework. But I'll argue instead that Django is as niche in the backend world, due to the sheer amount of people doing PHP, than Ember is in the frontend world.

Versionning

Django and Ember's major version number have coincidentally been quite in sync

The one difference I'd like to highlight here is that Ember is adhering more closely to SemVer than Django is (see the "Features removed" section of each minor release) and major versions of Ember introduce no to little features and exist mostly to enact deprecations. Last time I checked, the most recommended way to upgrade a Django application from LTS to LTS is still to go version by version.

Both Ember and Django provide tools to help with migrating from version to version, Ember publishes codemods and Django has django-codemod and django-upgrade.

I feel like it is more publicized in the Ember world though, being repeated over and over during conferences. I even remember, during the 3.x to 4.x transition, core team members asking teams who would experience problems to get in touch and certifying that all Ember 3.x applications would be able to be migrated to 4.x without major refactor.

From the information I have, the distribution of version usage seems to be fairly similar when looking at Ember and Django. Meaning that, for both frameworks, a majority of people are running their applications based on one of the supported LTS releases while some are using the latest release and a few are stuck with a legacy version.

Glossary of "recognized" libraries

EmberJS has Ember Observer while Django has Django Packages... but also Awesome Django. To be fair, there is an awesome-ember but it gets much less visibility or use compared to Awesome Django.

Overall, both Ember Observer and Django Packages use similar metrics to rank packages, the major difference here being Ember Observer, based on those metrics, assigns a score (0-10) for each package.

It also feels, quite ironically, that when it comes to the number of packages, Ember is closer to the Python motto of "having one and only one obvious tool for each problem". If you don't believe me, look at the number of packages that are trying to solves "Components for Django", "datatables" or just "forms". Something happened here... I'm not sure what though. Could this have something to do with the fact potential contributors are encouraged to write an addon library when trying to propose new features for the framework?

Maintainer fatigue

When looking at the best scored and most popular packages on Ember Observer, I've noticed a pattern that a handful of people are involved in all those packages. They are not exclusively involved, but they are still involved.

I have a feeling that also used to be the case for Django as well but that a lot of the early Django package maintainers have either burnt out or moved on. Is this a sign that we are not taking good enough care of our package maintainers? Is it a sign that Django package maintainers are more versatile and get swept away to other technologies? Are Jazzband, or more recently Django commons, the solution to that?

I have no idea but I thought it might again be something to dig into.

Community tools

Both Django and Ember have active Discord and Discuss communities, although, for reasons that are not clear to me at the time of writing, I hear more and more often about the "Unofficial Django Discord". Is this a sign that the community is not as united as it used to be? Or was this discord simply created before the official one? I believe this deserves some investigating.

DEPs and RFCs

Django and Ember have a pretty similar process for proposing changes to the framework itself, they are respectively DEPs and RFCs.

Even though the Ember ecosystem tends to use RFCs for a wider range of changes, including smaller features or API adjustments while Django DEPs are typically used for more significant, framework-level changes, it is quite telling that the number of RFCs is in the 1000's while the number of accepted DEPs is 14.

I am sure that people who have seen small PRs to Django (or its documentation) rejected have a lot to say about that but this difference is striking and might warrant further investigation.

Core teams, boards and commitees

Both frameworks are being lead by a series of enties, Django has mostly boards and commitees while Ember has multiple core teams. As far as I understand it, it's mostly a nomenclature diffrence although... at the time of writing it has to be noted that Django has more entities geared towards the community (CoC Commitee, D&I Team) while Ember's has technical teams with narrower areas of focused (data, tooling and framework teams).

Comparison and friendly competition with concurrent frameworks

In the early days Django was often seen to be in direct competition with Ruby on Rails and aimed at providing "feature-parity" or better. It's not just features either. Some of the community efforts around Django have been inspired by Ruby on Rails, I'm thinking about Rails Girls.

Nowadays, it seems that Django, as a framework, is reluctant to work on new features even if "Laravel does it" or "Rails has it". The words that come to my mind are "maintenance mode". And it feels to me that the only competitor that is being taken into account is FastAPI. I will agree that a bunch of small powerful things have been added to Django, like computed fields or template-based form widgets but it also feels, to me, that the only major feature that has been worked on during the past 3 major release cycles is async.

On their side, Ember seems to still be looking at features React or Vue may have that would give them an advantage or what those frameworks do better. The project then tries to integrate them without compromising its own identity. Ask about Glimmer, Octane and Embroider and how they came to be (spoiler: they are a reaction to something another framework was doing better).

Choice of city for their European conference

I don't think this on has anything to do with either stability or stagnation but I've always found it funny that the conference happened several times (2016 and 2019) in the same city on the same year or a few years appart (also keeping in mind that Django Under the Hood happened 3 times in Amsterdam).

Or maybe, there is just not enough European cities!