Django 4.0 (opens in new tab)

> function based views

Class-based views, in their most basic form, are a lot easier to read. E.g. look at the DRF CBVs I have here:

https://github.com/Alex3917/django_for_startups/blob/main/dj...

If you can avoid Generic CBVs (things like ListView) and inheritance, then the only difference between FBVs and CBVs is that CBVs make it easier to see what's a GET / PUT / POST / DELETE by adding some syntax highlighting that makes it easier to visually differentiate which code goes to which method. You don't need to know anything about classes in Python in order to use them.

It's not at all difficult to switch from FBVs to CBVs later, and most people (myself included) use FBVs when getting started. But I'd also say that if you're willing to push through the initial discomfort and spend the extra half hour or whatever on YouTube in order to understand them, then you do get a little bit of a nicer overall development experience.

>avoid fat models, use a service layer

I had not heard the term "fat models" before so I googled it. It did not go in the direction I expected.

It's great for getting things up and running. And can last a long time. But now that we're 40 devs or so working in the same 400k LOC codebase, I'd prefer Java/Spring (or really, Kotlin). So hard to maintain django in the long run, need to be really strict, or one ends up with each app spaghettied with other apps. Doing queries where you filter deep on other apps' models, and since it's only done as kwargs with no typing nothing stops that from exploding runtime when someone changes a model somewhere. Too easy to send fat objects around everywhere, accidentally doing heavy db stuff when using a property. Also makes it harder to test, because everything leaks.

I think CBVs get a lot of unnecessary hate. DetailView, ListView, DeleteView, etc save so much time and repetition for basic CRUD pages. Once things get complicated and you start having to override too many methods, it's often best to write the post(), get(), put(), etc methods explicitly. At that point you are still writing CBVs but it's much more organized.

I’ve found managed databases to be quite expensive at places like Azure and AWS. Especially compared to just installing pgsql on raw compute.

What managed databases do you recommend that adequately meet price/performance needs of indie developers?

Ideally try to avoid using Celery at all. It's the most consistently buggy, poorly documented, worst quality major Python project I have used so far.

Here is a fresh example: they deprecated CELERY_ prefixes in Django settings for some reason, which makes zero sense [1]. But because it's Celery, they only warn on a few properties but not others, and the tool they ship inexplicably renamed completely unrelated settings for me [2]. And yes, apparently the new way doesn't work either [3].

It's very characteristic of what I've seen from Celery over the last few years of working with it. If you are doing anything greenfield, it's best to avoid it altogether.

[1] https://stackoverflow.com/questions/65554242/celery-imports-...

[2] https://twitter.com/lambdadmitry/status/1468337594358546435?...

[3] https://github.com/celery/celery/issues/7140

I recommend this post when thinking about fat models/service layers

https://www.b-list.org/weblog/2020/mar/16/no-service/

May I ask what the projects were?

+1 for trying to avoid celery. Too much complexity for simple asynchronous tasks. You should use it however if you are instagram (I think they use a customized Django and Celery).

I’m sorry but I don’t buy that. Spring Boot is very highly productive — I really don’t believe any other stack would fare better by a significant margin.

Did you ever have to use Vue or other reactive frameworks with Django? Do you use DRF at all or just mostly Django?

please point us at your side projects - and congratulations that's a fantastic outcome

The one that you sold… what made you decide to sell, if it was a money maker for you?

You can also replace the template system with something else like jinja2.

Hey! FastAPI author here. I do have a bunch of issues and PRs to review across the projects. But as I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates) it's taking me a bit to handle them all, but I'm on it. I even changed my working structure to optimize for more open source. Sadly, new issues and new discussions like that one linked asking why the other issues are not solved, don't really help, as they just add another issue for me to read and take care of. I'm also prioritizing the work that can have the most impact. For example recently I was helping a bit with AnyIO and Trio, as they are used underneath by FastAPI. And now I'm working on something for Pydantic, that would be used by SQLModel and FastAPI.

If you want to see faster progress, there are several ways to help, they are all documented here: https://fastapi.tiangolo.com/help-fastapi/

One of the things that consumes time the most is handling issues by others. If you go and help them and they close those issues, that's a lot of minutes (in some cases hours) that you save me, and that I can then dedicate to review the other issues and PRs.

> typing

I believe there's a third-party package "django-stubs" that provides type hints for Django code. For your own code, it's just Python in the end so you can type-hint it as you normally would.

> Pydantic models integration

There isn't as far as I know. Django has its own model layer however unlike Pydantic, Django's is purely for the DB level, it's not there to (de?)serialize JSON.

In the Django world you'd typically use Django Rest Framework serializers for that. Now you can use Pydantic and it probably won't be too much work to make them work with DRF, but whether it's worth it is a different matter - DRF gives you a lot of stuff for free such as auto-generating serializers based on DB models (including validation and everything) which you wouldn't get with Pydantic.

Not to single you out, but are you or your business supporting the project (financially) in any way?

I share your thoughts on Typer[0]. It's a super cool project, but lacking proper hooking points to interact with the `click`[1] lib underneath [2], I am not sure if it would be the best decision to use Typer when we're rewriting our CLI.

[0]: https://github.com/tiangolo/typer/

[1]: https://click.palletsprojects.com/

[2]: https://github.com/tiangolo/typer/issues/77

Genuinely curious how you happened to choose FastAPI over something more in the middle, like Flask?

I tried a few tools in FastAPI, and it's fantastic for those, but I think I'd still stick with Flask for something more well rounded (not just as an API server).

Experience told me to be very conservative when picking frameworks. For small projects and personal, sure, just pick whatever you want and have fun! But for serious projects, you should stick with old and stable software.

I made the mistake of picking Flask for a really big project when these microframeworks were a fad and everyone was dismissing the big ones like Django and RoR. That was a very costly mistake. I learned the hard way provides way so many things out-of-box that I always took for granted but I had to manually implement in Flask.

Take tests for example, Django automatically makes sure that any DB operation is cleaned by the end of the test. That's sometimes that I never gave a thought until our Flask tests started leaking everywhere. The way that Django handles that problem is very clever and we had to manually do it Flask.

I'm thinking about using Starlette directly. It doesn't look that much more verbose than FastAPI and I already disagreed and bypassed a few FastAPI features. I wonder how much work would it take to hook the Pydantic models with their SchemaGenerator.

Have you considered moving to Starlette a la carte? I use marshmallow for schemas and a few other minimal deps and it's been a breeze.

Thank you very much! I've been running my own clobbed together version of a Django + Webpack configuration, and I'm very interested in learning from your code how you manage to run only one container with both Django and Webpack on dev mode.

> Making it more clear when you’re going to hit the database (explicit is better than implicit).

You might like https://github.com/dabapps/django-zen-queries

Gives you fine grain control about database queries

> - True async up and down the stack. Not a small task within the Python ecosystem, but I think for folks who are not already invested, looking at Elixir/OTP/Phoenix is too tempting. If you don’t have kids to transport with you, a Lambo looks much more fun than an S-Class Sedan.

This has been in the works for a few years. Everything in Django works with async except the ORM at this point. Which in practice, means it's not really async. But hopefully they are getting close.

that's super nice to know -- i need to upgrade a django app from 1.11 to 4 over the next couple of weeks!

Zope hails from the era when Python was trying to appeal to programmers by showing that it, too, could be a Serious Enterprise Language. Everything had layer after layer of abstraction and the code looked more like Java than Python. The Zope ORM was kind of nice in its own weird way, though.

Do you know if the ORM solution have the same `a` suffix for async interface? I really hope there is more elegant solution for all this.

The transitional USE_DEPRECATED_PYTZ setting might help.

Saw this in the extended release notes:

https://docs.djangoproject.com/en/4.0/releases/4.0/#zoneinfo...

> The Python standard library’s zoneinfo is now the default timezone implementation in Django.

> This is the next step in the migration from using pytz to using zoneinfo. Django 3.2 allowed the use of non-pytz time zones. Django 4.0 makes zoneinfo the default implementation. Support for pytz is now deprecated and will be removed in Django 5.0.

> …

> To give time for such an audit, the transitional USE_DEPRECATED_PYTZ setting allows continued use of pytz during the 4.x release cycle. This setting will be removed in Django 5.0.

What do you find hard in particular?

systemd service + gunicorn is not that bad, I think. You can have simple deployment and graceful restarts[0].

[0] https://nts.strzibny.name/gunicorn-graceful-restarts/

There are just so many makes and models of automobile and people get by. I remain so confused why choice paralysis is a thing in software.

Maybe the libraries need to cost 30,000$ ;-)

That's me. Once a year I get burned out from all the new languages and frameworks and decide to learn Common Lisp again for the 10the time.

It's actually a bit worse (or better) depending on how you see it. You get to invest (time, energy) in what will land you a job. 99% it's not what you want/like and not what is technically best. IT's just what came to dominate your job market.

At least if you're in a EU backwater country or in EU public sector-related projects. (Which usually means java/c# and to a much lesser extend a python tech stack).

PS: Loved the rant but you forgot to mention Golang :). "You're doing web backend and not using Go?!!"

There's also the part where you dig around to see what people use and recommand, and most of the answers are "use what you already know", which doesn't help when you don't know anything in detail. I feel like at this point the best strategy would be to list all the viables alternatives, pick one, and forbid yourself from using anything else for the next X months, but when thinking about that I have a huge fear of missing out.

You can experience all of this while staying in a single language ecosystem. Just recently, I had to build something in Javascript and got to know Express is no longer recommended. Fastify, Remix are the latest hotness. :)

Nah, Django makes you sad: async support is not full, migrations engine is pretty poor, not all database features are present, any kind of typing is hacky, very slow and so on

Yep, web solutions change too fast, with lots of legacy, and every solution is a compromise.

paradogm of choice

Django: Great if you are building only a backend or rest API with a separate frontend (an SPA in React, etc). The templates system is terrible, has no asset pipeline built in and frontend on it feels like developing in the 90s. You'll miss php a lot here.

Elixir: Technologically "mind blowing", although all the nice things come from the Erlang VM and not from Elixir itself in my opinion. You will likely not find any job using Elixir, if you do it is going to be full of people just learning the language so the codebase will be very likely a disaster. You will miss a lot of libraries and you will have to write code for things you'd take for given in the PHP ecosystem. Be ready to fight your editor plugins (depending on which one you use, and the degree of IDEisms you're used to).

I understand you want to learn something new, so the most "radical" one here that will teach you more new things is clearly Elixir.

But other than learning purposes, If I were to build something for real, I'd stick with PHP and Laravel, it's an incredible productive, well documented and well thought out platform to develop in.

No difference, it is just a matter of preference and selecting the best tool for the job. Often times the best tool for the job is the one that you know how to use really well.

If you’re good with Laravel for example, no need to switch to Django or Elixir and vice versa. Stick with what you know and you’ll be a happier developer.

IMHO, Elixir & Phoenix are such a breath of fresh air, plus power, plus adaptability, and I love the functional capabilties. On the other hand, if your want lots of numeric computation tooling, AI/ML, stats, etc. then Python & Django have better/more math-adjancent integrations.

For environment management have a look at poetry https://python-poetry.org/

I have a lots of experience with Django, and a few months experience with Laravel. I think Django is good at pure backend solutions. When you're not doing the frontend in Django itself but instead doing a separate SPA. Also the admin is a great tool as an internal CMS. Django rest framework is awesome too.

Laravel is a real "full stack" framework, it has a very powerful templating system (one of the best I've seen!) where you can do components instead of just includes. It has a powerful assets bundling pipeline, great integration with alpine, Vue, inertia and the super awesome livewire.

Laravel documentation is TOP.

As I'm not a fan of the SPA approach and still like frontend and building applications, I much prefer Laravel nowadays.

As someone who's used both - Rails packaging and environment maintenance has been so much less of a headache. Gems and Gemfiles and Gemfile.lock vs having to choose a Python package maintainer (Pipenv vs Poetry?) and deal with that has been worth it to me.

In terms of how they "feel" to develop with? About the same. Similar ideals - skinny models, service layers, REST-first but you can make it RPC-style if you want...

If you are starting a business, use whatever language you already know. The benefits of one framework vs. the other are a rounding error compared to language fluency. (They are both great, in other words.)

If you are learning both language and framework from scratch, check the local job market. 5 years ago in the Bay Area there were roughly 2x as many Rails job postings as Django, though I doubt it is this lopsided now. Also Python is used more broadly than Ruby, eg for ML and scientific/numeric work.

I'm biased because out of the two I've only used Django, however since learning Django my urge to learn Rails has gone down quite a bit. Its still there, and Rails does look fantastic, but so does the hundred other frameworks and languages on my todo list.

I guess the only takeaway you can get for that is that Django, at the very least, works fine, and probably will solve the problem you come in with unless you want it solved in a very specific way

If your application doesn't have to do anything other than basic webapp stuff, then Rails probably has you covered.

If you need anything related to ML or the sciences, go Python.

I recently built a fairly simple backend with a GraphQL API (fairly basic but bespoke e-commerce functionality, a few related models and a few queries/mutations) using Django, and then rewrote it in Rails, as a newcomer to them both (I knew bits of both languages but nothing really of the frameworks).

The reason I switched is more or less entirely that I hit performance issues with the Python Graphene library being really slow at returning larger datasets, and couldn't find a solution in a reasonable time frame.

My impression was that Django has a much more powerful and pleasant ORM – your migrations are derived from your models, so if you want to add or remove a field (for example), you update the model class then the migration command works out what it needs to do to make the database match the models. Rails works pretty much the other way – you create explicit migrations to add/remove columns, and the database is the source of truth - your model classes don't even have explicit accessors in the code for the fields you define in the DB. I found the Django way more logical, and I found things like many-to-many relationships much easier in Django, but the Rails way isn't too bad once you get used to it.

Rails is well known for being heavy on the "magic", which is quite expressive once you get used to it but I find it hard to know where to look if I want to e.g. know what methods a model has, whereas Django felt a bit more explicit in this regard. Personally, I find Python a more pleasant and easier to read language than Ruby, which has so many ways to express the same concept in different ways, but I am actually warming to Ruby.

If you're interested in adding type checking, it seemed that Python has better and more mature options here.

Ultimately though, for what I wanted (which was to build a backend with sensible defaults out of the box and really write as little code as possible), I think Rails is a better fit. The ecosystem of libraries seems more mature and better documented (I hit quite a few issues with Django related libraries which took a lot of Googling and some hacks to solve). The Ruby GraphQL library is much nicer to work with and much more performant.

The amount of code I have to write is generally pleasingly low (though I'll admit it's quite spaghettish already, I have been learning Ruby as I go and I can totally see how a large codebase could become a mess), and it's easy to Google for most stuff, and the defaults seem pretty sane. I will say on a slight tangent that I recently enabled GitHub Copilot, and am finding it surprisingly quite useful in a Ruby project, where I often struggle to know/remember the right syntax!

So... that's my experience. Ultimately it came down to a niche-ish requirement (performant GraphQL API) to force my hand, but I think I'm pleased with the end result. Both are impressive frameworks and I don't think generally you could go too far wrong, but for me Rails just feels that bit easier and more mature for bashing out a solo project.

Phoenix has a much smaller footprint than Django. I would put Phoenix closer to Flask in terms of how much work the framework does for you. Phoenix has lots of generators which make hooking into the database layer very easy and bootstrapping new endpoints is also fast in Phoenix. Django makes more decisions for you (authentication, permissions, admin, the ORM to name a few).

In the Phoenix ecosystem you bring each of those pieces in as you please (auth generator, Ecto + other libraries etc). So I would say if your really want to move fast, you will still get further, faster with Django - but the trade-off (as other posts here have alluded to) is that once you need to implement custom features or optimisations you will often fight against Django (or need to wade-through half a dozen classes in some inheritance tree to find the right hook).

Another big difference between Phoenix and Django is that building websocket services in Phoenix is an absolute breeze. The Elixir runtime maps perfectly onto any type of messaging service.

Django has more features, a _much_ larger ecosystem, excellent documentation.

Elixir is dramatically more performant and will scale better. A lot of people enjoy Elixir more or find it conceptually more interesting than Python.

IMO the number of packages and facilities provided by Django will outweigh Phoenix's performance for 95% of users.

Django, Rails, Phoenix, Laravel, etc are all pretty similar at a high level.

Phoenix is on a much better performance level compared to the other two.

I would start by replacing the dependencies that are not maintained anymore (i.e. that don't support a relatively recent Python 3.x) with more modern alternatives one by one instead of rewriting it. The migration of the Django application itself should not be that hard.

I had a project running on 1.3 until very recently. The was a lot of issues with the TZ datetime fields, migrations, Python2, etc. It was a lot easier to start a new project from scratch.

Django releases time based and a version 3.3. was part of the plan. 4.0 is released right now because it is December 2021. The versions after that will be 4.1, 4.2, 5.0, 5.1 etc. [0] It's different from how many other projects work but not unique, Ubuntu works in a similar way for example.

And although it might be different form what you're used to, I really like it. If you check their documentation, you can see exactly when they'll make breaking changes and features will be deprecated and removed.

[0] https://www.djangoproject.com/download/

Agree, doesn't deserve the 4.0 tag.

I was hoping for some progress on async ORM as well. Is there any word on when this is coming?

At this point I disagree - DRF is a verbose and somewhat dated architecture. I wish they would provide something like Django Ninja / FastAPI.

Plus it already has decent async support.

https://github.com/vitalik/django-ninja

> nowadays most people use Django to create REST API

I doubt that's true, but yes, having DRF merged in would be rather nice.