Django's goals are probably not our goals for our web application

July 4, 2019

Django bills itself as "the web framework for perfectionists with deadlines". As a logical part of that, Django is always working to improve itself, as are probably almost all frameworks. For people with actively developed applications (perfectionists or otherwise), this is fine. They are working on their app anyway, constantly making other changes and improvements and adjustments, so time and Django updates will deliver a continue stream of improvements (along with a certain amount of changes they have to make to keep up, but again they're already making changes).

This does not describe our goals or what we do with our web application. What we want is to write our app, reach a point where it's essentially complete (which we pretty much achieved a while ago), and then touch it only on the rare occasions when there are changes in the requirements. Django provides what we need in terms of features (and someone has to write that code), but it doesn't and never will provide the stability that we also want. Neither sharks nor frameworks for perfectionists ever stand still.

This creates an awkward mismatch between what Django wants us to do and what we want to do, one that I have unfortunately spent years not realizing and understanding. In particular, from our perspective the work of keeping up with Django's changes and evolution is almost pure overhead. Our web application is running fine as it is, but every so often we need to go change it in order to nominally have security fixes available, and in completely unsurprising news I'm not very enthusiastic or active about doing this (not any more, at least; I was in the beginning). The latest change we need is an especially large amount of work, as we will have to move from Python 2 to Python 3.

(We don't need bug fixes because we aren't running into bugs. If we were, we probably would have to work around them anyway rather than wait for a new Django release.)

I don't know what the solution is, or even if there is a solution (especially at this point, with our application already written for Django). I expect that other frameworks (in any language) would have the same bias towards evolution and change that Django does; most users of them, especially big active ones, are likely people who have applications that are being actively developed on a regular basis. I suspect that 'web frameworks for people who want to write their app and then walk away from it' is not a very big niche, and it's not likely to be very satisfying for open source developers to work on.

(Among other structural issues, as a developer you don't get to do anything. You write your framework, fix the bugs, and then people like me want to you stop improving things.)

PS: I don't think this necessarily means that we made a bad choice when we picked Django way back when, because I'm not sure there was a better choice to be made. Writing our web app was clearly the right choice (it has saved us so much time and effort over the years), and using a framework made that feasible.


Comments on this page:

Hi! Nice post, and I sympathize. However, I can't help thinking that, for web apps in particular, it is risky to have the idea of software you don't have to touch anymore (except for security updates). The browsers which are used to access it also change. I have seen web apps that relied upon Flash, or relied upon access to the user's webcam, which did not have baked in the idea that they would need to be rewritten every few years. Browser attitudes towards what javascript will work, what css will work, whether http is cool instead of https, etc. change over time. Plus, which browser your users have, changes over time (many web apps were written for Internet Explorer only, once upon a time).

I don't think these are one-off changes, I think it's part of a general trend. If it's software that runs on your computer, you can just leave it be. If it's a web app, a big part of it is running on someone else's computer, using their web browser (a piece of software you don't control). You will need to update it from time to time. Like Alice's Red Queen, you will have to keep running just to stay in place. I think that's intrinsic to the web as a computing platform, where the hardware an a good chunk of the software is routinely changed by the client, without much warning.

Convincing whoever has to approve programmer time to maintain it, of course, is a problem. But, I just mean to say, I don't think you would have been better off if you had chosen, say, Ruby on Rails to develop in, or if you chose Flask now, at least not for this reason.

By Yeah at 2019-07-07 20:50:46:

Pyramid is a pretty good choice for a write-and-walk-away app.

Sorry, I'm having trouble sympathizing here. How is Django "not stable?" Its stability is one of its huge enterprise selling points. Upgrades are almost always painless, and Django apps don't need to be touched very often.

Of all of the web frameworks I've worked with, Django updates seem to be the easiest to manage.

The case you cite involves an update to the underlying language, and that's a whole 'nuther matter. Maybe your complaint is really just the usual "The switch from Python 2 to 3 was harder than expected?" i.e. It sounds like you are frustrated with the Python upgrade, not the Django upgrade?

Written on 04 July 2019.
« Converting a variable to a single-element slice in Go via unsafe
My plan for two-stage usage of Certbot when installing web server hosts »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jul 4 21:30:02 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.