Some more things about Django I've been enjoying

I don't think the performance issues here are a result of Django. The author says only 2-3 requests per second (rps). Even in debug mode just using django runserver I can get 60~ rps on my $WORK repo. Part of this is likely their choice of only using '-c 1', which doesn't accurately represent a web workload.

For example on a local dev server I get (in format -c n. rps)

1. 58
2. 61
3. 55

as expected because we only have 1 worker, in debug with little caching.

but when looking at an example production config we see

• 1. 11
• 2. 23
• 5. 54
• 10. 95
• 20. 153
• 30. 165
• 40. 177
• 50. 192

and so on....

All of these are far in excess of the 2-3 observed by the author.

Note these will heavily depend on how many database hits you have per request as that is the majority of workload, as well as your http server such as using http 1/2/3, and the TLS settings used etc...

One of the things that seems most right about frameworks like Django (and Rails etc.) is that you have some nouns (your types), relationships, verbs (list/search, add, edit) and build a good toolkit around those, and it takes you a long way. There are other modern tools that define schemas, like Pydantic, but I think Django gets mileage out of spanning all the layers, from declaring the schema to building queries and migrations to rendering admin forms.

There were tasks I wouldn't have thought of as CRUD before Django that, once you get used to it, turn out to fit well. I think there are a few categories:

• Sometimes the problem wasn't the relational model but the boilerplate. For example, managing many-to-many relations or owned objects with inline tabular forms could previously be a lot of work, and that work could make a nonrelational approach (e.g. 'has many' via a string or JSON list) more tempting. A framework that does the predictable parts for you helps.
• Some things take some tweaks to typical relational models but are basically compatible with it:
  • Cosmetics. A lot of things are fine to store relationally, but most natural to show or edit with some sort of custom widget. I feel like this could be more elegant with Django, but it's still easier than it would be without it.
  • Schema extensions like history, ID-name-value tables, common metadata, or the occasional blob. Like with the many-to-many editors, you just want to factor the predictable parts.
• Sometimes there is deeply nonrelational stuff and building it around other, relational parts is is fine. We have query builders and so on that really do have weird stuff going on, and Django is essentially part of the serialization layer for them.

I haven't really ventured out much to compare, but I suspect one of the places that Django can show its age is just the implementation. Like, we scale to what our customers need OK, but I think we suffer some in hardware requirements compared to what is possible. Another thing is acommodating when a project wants to do something a little different from what comes in the box--Django makes a real go at exposing hooks but, as I mentioned, it sometimes feels like it ought to be easier. Pieces that fit together well made the good parts of Django work, but pieces that are really independent is a great thing about other ecosystems. I don't know the answer there.

The "making websites like it's 2010" framing is fun; I'll see advice online like "try server-side rendering to speed your page loads" and I'm like, hey, I never stopped! I think things like FileMaker or HyperCard or 2000s-era desktops are interesting to mine for what was good about them; maybe Rails and Django and Laravel and so on carry wisdom of the ancients as well.

I like the template tags, too. If I were writing my version of that section, django.contrib.humanize would need a mention.