What I'm not a fan of, is the query DSL. Normally, the developer works to figure out how to express their problem with SQL; then the DB engine works to figure out how to map that SQL to the data it has on disk. Now Django adds another layer, which is completely unlike SQL, has its own unique pitfalls, etc; sometimes I find myself just dumping the raw SQL, working on that to get the result I wanted, then working that back to the DSL.
I think SQLAlchemy gets it right. The query language is a thin veil over SQL, and mapping to objects is an explicit and clear operation. What does feel clunky to me, is setup: SQLAlchemy expects you to bring your own glue; Django is vertically integrated.
https://laravelpodcast.com/episodes/c7807d42/transcript (Search for “Paris” to find the relevant section)
https://github.com/j4mie/idiorm
https://github.com/j4mie/paris
Idiorm was started in early 2010 while I was still writing PHP professionally. I’d heard about Django from a talk @simonw gave at the FlashBrighton meet-up group in 2009 and immediately fell in love. Idiorm and Paris, although not direct attempts to duplicate Django’s ORM, came from frustration that such an elegant ORM and query builder didn’t exist in the PHP world.
So in a roundabout way, Laravel’s ORM was absolutely inspired by Django.
As a side note, I’m still doing Django 16 years later and love it more than ever.
Django's request.GET and request.POST were directly influenced by $_GET and $_POST.
Django's template language included ideas from the Smarty PHP template language.
Anyway, thank you Simon :)
I've been using Jinja for my own projects for a few years because I wanted more expressive Python code in my templates! I think we didn't quite get the balance right for that in Django.
https://www.quora.com/What-is-the-history-of-the-Django-web-...
simonw co-created Django. It's a fact. You don't have to like it.
Jacob joined shortly before I left, then Adrian and Jacob turned Django from a closed-source newspaper CMS project into open source Django. I think they deserve way more credit for the framework than I do, they made it open source and were co-BDFLs for the next decade of development.
I'll still take the co-creator credit though, because Adrian and I designed, built and sometimes even pair-programmed the core of the framework - request/response objects, view functions, template system - together during my year at the LJW.
If you're interested in more details I told a bunch of the story in this talk: https://simonwillison.net/2025/Jul/13/django-birthday/ - and more in this Fireside Chat interview at PyCon AU: https://www.youtube.com/watch?v=1E_UqhFmJQs
Years later (2009), I got to do interesting work in a cutting edge machine learning lab due to the expertise I developed in Django -- I was accepted into the lab specifically to clean up the mess phd students had made trying to build a complex front end using Django's ORM with physically separate per-user MySQL database servers.
All the things that came after -- being the first full time employee at a machine learning spinout from the lab, getting acquired by a big company and scaling up sensor-driven ML in the real world, quitting to co-found an ML-centered VC fund, starting a (now 10 year old) AI company -- none of it would have happened without Django.
Also, how on Earth did the ML PhDs decide physically segregated databases for each user were a requirement?
And if you spend any time working with a group of PhDs, you'll be shocked at some of the harebrained schemes they come up with. Dumb people are dumb in simple ways. Smart people are dumb in genius ways.
> Also, how on Earth did the ML PhDs decide physically segregated databases for each user were a requirement?
I worked at several labs at top academic institutions, on everything from supercomputer MPI work for multi-agent sims to image pipelines for large weather simulations, and one thing I learned is that being a good coder is orthogonal to being a good researcher. In that particular case, the person who wrote the code made the assumption that the "customers" would not allow their sensor data to be stored alongside the data from other customers, and separate databases with separate passwords was the solution they came up with. Somehow they did not notice that the terrible ergonomics of this solution meant there was probably a better way. Once I ripped out MySQL in favor of Postgres (since it had proper security) and removed the cumbersome middleware layer performance improved by over 100x.
didnt they hear about sqlite, great for this setup
Every time I work with another framework I am reminded of how well Django has adhered to initial principles (batteries included) while adapting to changes with new technologies.
It has a great community behind it and for that to exist for so long is something remarkable. Other frameworks have advantages in some places. But for overall tooling I think it still is the best choice for anything large and complex yet not a bad choice for micro projects either.
I have to say thank you to Simon and the Django community as a whole.
Its a wonderful "batteries included" framework that has launched many successful projects, companies, and careers. Mine included.
And I'd be lying if I didnt say I still use pgadmin as my benchmark for evaluating admin panels in other ecosystems.
What you all created with Django is amazing.
We'd all be much further behind in tech without it.
Thanks absolute heaps.
There's still no framework in e.g. Go that comes anywhere close to matching Django. It's pragmatic, doesn't do too much meta-magic (I still don't "get" Rails), lets you strip away any layers you don't need, etc.
I am huge fan of Python and Django. I despise PHP with the force of a thousand suns but I give enormous credit to Laravel as a well-designed framework that makes life bearable when working with PHP.
Specifically for python vs django, most of the things I dont like are actually attributable to decisions by the python team, not necessarily Django.
But many of the things I do like are attributable to the Django team.
everything just worked out of the box (compared to using java + spring and their endless xml config files), the orm was (and still is!) lovely compared to other solutions, and there were so many things included, that i never really had to go integration hell.
Who knows where I would be today if not for Django!
I learned Python more than 10 years ago, but later chose Rails to be my first web framework to learn, as I also wanted to learn more about Ruby, hence the question.
* I've always preferred Python over Ruby. Explicit imports, namespaces and the "only one way to do something" philosophy have felt more scalable. In general the language does not promote as much implicit magic
* Django reflects the same philosophy: more explicit definitions, a slight bit more configuration and ceremony but easier debuggability.
* The Django docs are, to me, some of the best there is in documenting the framework extensively but also teaching good practices. I've always felt the Ruby docs to be lacking in the latter department so you see more drift in Ruby projects on how to approach the same problems
* Django has felt much stable over the years. Migration between major versions is a breeze.
* The Python library ecosystem is much larger
* The Django admin and Rest Framework are some of the biggest timesavers I've seen. Rails has similar projects but they don't quite make it
Unless you're doing a GIS or project with scientific computing I would not let these factors go above personal preference, as Rails is still an excellent framework.
Lot of the places I see that use Rails now has a separate codebase for their Python work that has to be accessed via separate querying versus just using the Django ORM.
For most cases I would recommend Django to be the main framework for startups. But if you don’t intend to do any ML/AI and only need a defined set of libraries and you are a one man shop then Rails dev speed is so fast.
But I still learn Javascript lol
I celebrated the 20th birthday yesterday by writing up an annotated transcript of my talk from the 10th - it tells Django's origin story: https://simonwillison.net/2025/Jul/13/django-birthday/
I've only worked with Express js as an alternative and I just love how Django handles lots of things for you and let's you focus on the core logic.
I was still at uni (2008) when I got my first PHP job. I've shown Django to my boss. He's never started another PHP project since.
Django is now older than I was when I first used it. To another 20 years.
The drift from a simple Flask to monstrosity Flasknjo was so natural that I suspect it happens to a lot of people.
It wasn't long before newforms became a thing, and the 1.0 release, lots of cool database features, migrations (I remember debating South vs. Nashvegas at work), class-based views (amazing!), Postgres-specific features (built-in JSONField, finally!), Py3k support, ASGI... It's been a long, cool, productive road.
I was at the first DjangoCon in 2008 (leaving my wife at home with our two month old!), and giving a conference talk for the first time a decade later at DjangoCon 2018.
I owe my career to Django. It has been my framework of choice for projects large and small, and I've always felt solid in that decision -- thanks in no small part to the community.
HBD Django! <3
hnarayanan•13h ago
nanna•6h ago
rollcat•3h ago