Django 4.0 alpha 1 released
djangoproject.com
djangoproject.com
Been using it for more than a decade and never it has disappointed me.
Every release comes with excellent features and polishes.
Everything in Django is well mature, properly maintained and built for maximum productivity and maintainability.
One of the best thing about Django is, it's never gets involved with bubble type technologies until proven reliable and useful.
Either be it async, websocket, NoSQL, fancy SPA, AMP, or any specific frontend framework integration.
Some parts of the framework feel a little long in the tooth. The admin could use a rewrite with CBVs; the forms API just doesn't look so good compared to serialization abstractions in Rest frameworks nowadays.
Still, it is a weapon, combined with Postgres, container-based deployments and a half dozen Django apps, there's few frameworks that come even close in terms of productivity and polish.
I used pretty much many framework before settling on Django and polishing my knowledge and skills on it.
Some places of Django could annoy me a bit, for instance Admin customization, but I got to conclusion that it's impossible to make Django customizable to every needs. The best would be create an admin dashboard for your own stuff. Charts, reporting, backoffice type are. Although it's possible to do so with current admin, but it's get annoying and after a while I see it be much better served if my requirements get created separately without poking around the admin so much. I usually create a separate app then include all the business requirements that don't fit in admin.
Probably admin could expose a REST API? meh!
Been a very long time that haven't worked with Forms, but compared with what comes out from DRF serializer etc, indeed would need some love. However, it's been years since majority of apps are built by frontend frameworks and using Django via DRF.
The integration that comes with PostgreSQL and everything around Django ecosystem is mad productive.
It takes a very short time to prototype and containerize the whole thing and have it on production.
Fortunately or unfortunately, since I got comfortable with Django, I compare everything with it and it's really really really hard to swap it with something else.
> One of the best thing about Django is, it's never gets involved with bubble type technologies until proven reliable and useful.
Django has also chosen not to get involved in tech that *has* been proven reliable and useful.
For example moving to incorporate a formal API library like DRF years ago. It also has not indicated plans to adopt a type-based API library like FastAPI or Ninja.
Often this idea of supporting REST API building as a battery of Django is used as a cudgel against modern front-end frameworks. The comments are generally aimed at React, but broadly anything in Javascript that requires an API.
However, doing so has also been expense of making Django a first choice for microservices and ignores the important role of serving mobile app clients.
Django has also been slow to discard technology that is no longer reliable or useful. For example, jQuery is still endemic in the ecosystem.
I'm all for stability--I've invested a lot of time in Django and it is very productive. However, the biggest threat to this framework is the effusive self-praise for this attribute.
People would do well to remember that Django displaced Drupal because Django was iterating rapidly even though it made upgrades very challenging at times.
FastAPI and now SQLModel are showing how valuable adoption and use of Python's type system can be.
There is no reason why a new Python-based framework (apart from Flask) could not unseat Django as the framework of choice. It wouldn't even endanger Django. People still build using Drupal today.
But more to the point, I feel like DRF is kind and of a weird solution anyway, like the request object is different from Django, it doesn't support schema generation without some third party libraries...
Frankly, FastAPI with an orm sounds like the ultimate python microservice framework, anyway. Pgcli works as an admin interface in a pinch.
I've written my latest api w/Starlette and found it to be excellent.
I've never actually used starlette directly, but it doesn't sound very ergonomic
A consistent DB interface, ORM and migration system (independent of the underlying DB), same for cache (similarly you can swap Redis for Memcache and your code doesn't have to change), same for e-mails (swapping e-mail providers is a matter of writing a new backend, application code doesn't change), etc.
Sure, you could do all this with Flask and SQLAlchemy, but Flask and these minimalist frameworks always feel like they lack structure and good conventions which means every project does its own thing. In Flask & SQLAlchemy I still don't have a good way of organizing my application and model classes considering they have to inherit from an instantiated DB connection object. I'm sure there's a way and I haven't researched enough, but why bother when Django solves this problem with "one true way" that everyone conforms to?
Also keep in mind that despite Django having many features, only those that you actually use will be invoked; you can slim it down further by removing some middleware (hooks that run upon every HTTP request lifecycle) but even in its default configuration it's pretty light - for example the admin is not loaded nor evaluated unless you actually assign it to a URL route and a request hits it. Same for the HTML templating support - unless you actually render a template from a view it's as if it didn't exist - you only waste some disk space but there's no runtime performance hit.
I used it a few years ago for a startup and I liked it. It also has a user management system built in also .
It’s a reasonable ORM, but doesn’t compare to SQLAlchemy.
A dirty-tracking mode would be great. This is really useful if you want to have code that builds up a list of sub-objects, and then _maybe_ commits them, but maybe rolls back after creating most of the Python objects. The naive Python you want to write is `for i in range(10): foo.bars.add(Bar(i))` which in the Django ORM triggers a DB write for each bar, even if you error out on the 10th Bar.
As you say, another area where the ORM can bite you is the always-on foreign-key-traversal logic. So if you have loaded model foo, then accessing foo.bar will trigger a SQL query under the covers, if you didn't select_related/prefetch_related properly. This is great for simple use-cases and exploratory coding, but can make it very easy to write code with horrendous performance. Naively-coded views often have hundreds of DB lookups and it's hard to track down where these are coming from when the app is complex and especially when you've got _some_ *_related in place, but you're missing a prefetch somewhere.
The request-handling and template rendering is in my mind the weakpoint.
> I mean, Instagram server is still a big Python codebase. It's Django at the core, I mean, it still runs through the Django request handling stack, and the middleware and views and URL routing, all of that is still Django. It looks familiar to any Django developer. Just very big, lots of views, lots of URLs, lots of code. There's a lot of, I mean, obviously, the ORM we don't use anymore, the admin is very much based on the ORM, so that's not in use anymore. And there's a lot of components, where Django provides kind of pluggable back ends, like sessions and authentication, and for all of that stuff, we've essentially rewritten the entire system. But we're actually still using the sort of Django API for those things, because it's pluggable. So I would call that a success story, I mean, in that we've been able to very smoothly migrate away from the components that that no longer worked at our scale, in many cases without even having to change the client code touching those subsystems because Django provides this ability to swap out the back end. So yeah, and you know, the Django core requests support that we still use, we're 100% async now, so already a few years ago, we kind of forked and modified a bunch of that to support async, or concurrent handling of multiple requests using async IO. So there have been some changes.
I would say it is a Django success story but given how much has been replaced it sounds more like a Python success story to me.
Anyone have experience upgrading django? Does it go well?
I see many announcements where it is difficult to find.
How viable? More viable than the newer systems you mentioned, clearly.
When it comes to web applications tho, Django is not as pollished as Laravel/Symfony. There is no webpack integration (or any other npm frontend tool). built-in authentication is very basic, hosting is a pain.
The thing is a haven't written a single line of code in Django, but modern PHP and it's ecosystem looks more fun from a front-end, JS developer's perspective
Laravel is a great framework, but the tooling in PHP is amateur hour by comparison. The app ecosystem in Django is only comparable to Rails'.
Looks like maybe the ignorance goes both ways? People really underestimate the size and maturity of the PHP web development ecosystem and it's professional community, and there's no shortage of tooling to build and support apps on the language.
Django: 34,019, Laravel: 26,881, Rails: 9,300
https://github.com/topics/django
https://github.com/symfony/symfony
Modern PHP ecosystem is a shadow of their former self, in a positive way.
Even the top packages are pedestrian things like logging, event dispatching, sub-process management, and testing.
But PHP has a Microsoft-level of baggage, and those bridges can't be unburned.
It's pretty fast to prototype and then cut stuff you don't need.
Rails and Django are the pieces of web tech most likely to stay in the game.