In a very real sense, I have Django to thank for my entire career. As an undergraduate, my first academic job in a research lab had me building websites to promote the research in a lab. Django was brand new, and I was uninterested in petty concerns like stability and security, so I did everything in Django.
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.
It's not that Django has/had any reputation for those things -- it's that Django had no reputation at all since it was a nascent project with no track record. That means it had no proof points for being stable or secure. At the time I adopted it (~Nov 2005), the public release of the Django project was only a few months old, and indeed breaking changes followed soon after (the so-called "magic removal branch"). As I recall, there were also various template escaping security issues at that time.
> 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.
It has neither reputation, and to my knowledge, has never had serious incidents of either. It powers huge websites like pokemon.com
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.
Same here! Django was not only the first piece of software that allowed me to do real freelancing and software development, but also exposed me to high-quality Python source code and development practices taken from the development team.
I first started using Django in 2006, v0.95, the "magic removal" release. I was 19 and doing PHP at a small startup. I'd heard the hype around Rails, and wanted to check it out. Several hours and many head-desk moments later, I still couldn't get everything set up properly on my laptop (running Ubuntu). In my research, I discovered Python and Django and decided to give it a whirl. Twenty minutes later, I had the Django Hello Word page on my screen, and I haven't looked back since.
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.
I don't think you can honestly and objectively criticise something you don't truly know.
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.
Now Phoenix and Elixir are two technologies I love! But theyre admin offering is lacking. (Which is ok today in modern development and things like pgadmin)
Software is multilayered and you can prefer some layers over others.
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.
Same here: I started with PHP (and Zencart and the like) and moved on to Python and Django. When I had to step back to PHP for a while, Laravel was an island of sanity, just because it was clearly "let's do Django/Rails in PHP".
I've worked in Django across most of my career at a few places for many years.
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.
Working with Django for the past 15 years has been a pleasure. Joining the community was a revelation. Serving on the board and as president of the DSF was a privilege. I look forward to 20 more years of code and community.
Django just works out of the box. And if you hate JS, well… I am glad Django kept at it all these years despite all the JS frameworks gaining (and falling out of) popularity. So thank you to all those who contributed even when it wasn’t so sexy.
Out of curiosity, for people who have do projects in both Django and Ruby on Rails, which one would you prefer and why?
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.
Having done Rails and Django professionally for some time now I’d honestly recommend Django. While I love the meta aspects of Rails unlike other people I just think the Python library ecosystem is just so massive that you can quite literally do anything with Django without having to resort to multiple programming languages, etc.
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.
Depends on the project. I feel like Rails has better JS integration if your project really needs it. The out of the box JS experience with rails (import maps) is similar to django (static link from cdns), but the ability to set up esbuild from project generation makes it really easy
Literally just my opinion though, but I haven't been pleased with an extremely nice method to set up django with javascript that doesn't feel hacky for local dev and deployment
* 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.
That project (a local one to me; was created the next county over in the KC metro) put a lot of food on my table and made a lot of value for my business partners. Happy birthday!
django is the framework that made me fall in love with software development 18y ago.
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.
Love django. Whats the consensus on best way to use django in 2025? I've been going the headless route. Django for the backend and using vite or nextjs on the frontend with openapi specs auto-generated.
I've been a fan of Django templates and HTMX. I like how I can get interactivity without too much complexity. I do have specific parts of my website that rely on more complex tools, such as Codemirror. Even then, templates work well enough for me, so I haven't found a compelling enough reason to adopt more JS for my website.
It's still the best RDB schema creation/migration tool I know of. It has a crazy number of plugins to handle all sorts of unusual field types and indexing. I usually add django to any project I'm doing that involves an RDB just to handle migrations. As long as you avoid any runtime use of the ORM it's golden.
What is missing? The ORM works with asyncio, you can have async views, you can have long running connection-oriented async stuff for websockets etc (via django channels). Maybe there is something important that I'm missing but that seems more complete than most async-only frameworks.
Adrian and I co-created Django while I was working at LJW in a "year in industry" program from my UK university - which got me a student visa, so you could call it an "internship" but it was paid and 11 months long.
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.
Jacob joined a little later but I think of him as a co-creator as he worked on Django substantially prior to the initial open source release, then acted as co-BDFL with Adrian for the next decade.
Django was the whole start of my career and I still thank it for many of my opportunities. I started in 2012 to work with Django at Billogram, then founded a Django consultancy which lead me to work at King 3 years later.
Who knows where I would be today if not for Django!
This is surprising because the template language in particular feels so anti-PHP, it’s highly opinionated about not mixing code in with the template. I often wish it supported arbitrary Python.
Yeah, the template language was strongly influenced by NOT wanting to allow arbitrary logic like PHP does. I was already a fan of Smarty - https://www.smarty.net/ - which did a great job of separating out presentation logic in PHP.
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.
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.
It's likely the template-centric architecture with its own template language and the monolithic approach to web development - both Django and traditional PHP frameworks like Laravel share this pattern of tightly coupling views with server-side rendering.
I’ve also switched away from Django (to Litestar), but the ORM is the mean thing I keep missing from Django. SQLAlchemy feels really clunky by comparison
I think the ORM is fine. There's always some friction coming from mapping rows to classes and objects, but you can always drop down a layer and just pull raw tuples.
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.
I think FastAPI's one major design difference is its dependency injection mechanism. Django is designed to do things differently, with services provided through an app- or project-global collection of middlewares (although I haven't used it in a while, maybe something had changed since then) and while there are DI solutions for Django they don't feel "native" to me - not the way FastAPI does it. Either way works, of course - it's probably merely a matter of the preferred mental model.
Django is somehow the one thing in Python I never enjoyed working on. I recommend it thoroughly to people running teams since it keeps devs disciplined, but I've always been a Flask programmer at heart. To each their own. I'm glad Django exists, it's eaten plenty a share of the pie that would have otherwise gone to Rails maybe.
The couple of projects I was forced to use Flask, they both ended as a bunch of poorly assembled libraries to work like Django (admin + orm + migrations + cache) but worse.
The drift from a simple Flask to monstrosity Flasknjo was so natural that I suspect it happens to a lot of people.
They didn't manage to get a blog post that doesn't scroll horizontally in Samsung Internet on my Galaxy A54. Exciting times, but there is work to be done.
In a very real sense, I have Django to thank for my entire career. As an undergraduate, my first academic job in a research lab had me building websites to promote the research in a lab. Django was brand new, and I was uninterested in petty concerns like stability and security, so I did everything in Django.
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.
That early Python community was really nice. There were a lot of helpful strangers on the internet. Same with Ruby.
Does/did Django have a reputation for instability or insecurity?
Also, how on Earth did the ML PhDs decide physically segregated databases for each user were a requirement?
It's not that Django has/had any reputation for those things -- it's that Django had no reputation at all since it was a nascent project with no track record. That means it had no proof points for being stable or secure. At the time I adopted it (~Nov 2005), the public release of the Django project was only a few months old, and indeed breaking changes followed soon after (the so-called "magic removal branch"). As I recall, there were also various template escaping security issues at that time.
> 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.
how does one get to be a coder in a research project
It has neither reputation, and to my knowledge, has never had serious incidents of either. It powers huge websites like pokemon.com
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.
> trying to build a complex front end using Django's ORM with physically separate per-user MySQL database servers.
didnt they hear about sqlite, great for this setup
Same here! Django was not only the first piece of software that allowed me to do real freelancing and software development, but also exposed me to high-quality Python source code and development practices taken from the development team.
We had an in-person event in Lawrence, Kansas ten years ago for Django's 10th birthday. The videos of the talks from that event are here: https://pyvideo.org/events/django-birthday.html
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 first started using Django in 2006, v0.95, the "magic removal" release. I was 19 and doing PHP at a small startup. I'd heard the hype around Rails, and wanted to check it out. Several hours and many head-desk moments later, I still couldn't get everything set up properly on my laptop (running Ubuntu). In my research, I discovered Python and Django and decided to give it a whirl. Twenty minutes later, I had the Django Hello Word page on my screen, and I haven't looked back since.
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
As someone today who is an unrelenting critic of python.
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.
How can you be an unrelenting critic of Python but love Django?
I don't think you can honestly and objectively criticise something you don't truly know.
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 think Phoenix is very close to Django at fitting that bill.
Now Phoenix and Elixir are two technologies I love! But theyre admin offering is lacking. (Which is ok today in modern development and things like pgadmin)
Same way I can hate the drivetrain of a car but love the interior! They're separate systems that co-habitate.
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.
Software is multilayered and you can prefer some layers over others.
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.
Same here: I started with PHP (and Zencart and the like) and moved on to Python and Django. When I had to step back to PHP for a while, Laravel was an island of sanity, just because it was clearly "let's do Django/Rails in PHP".
I've worked in Django across most of my career at a few places for many years.
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.
Working with Django for the past 15 years has been a pleasure. Joining the community was a revelation. Serving on the board and as president of the DSF was a privilege. I look forward to 20 more years of code and community.
Django just works out of the box. And if you hate JS, well… I am glad Django kept at it all these years despite all the JS frameworks gaining (and falling out of) popularity. So thank you to all those who contributed even when it wasn’t so sexy.
Unquestionably the best framework I've ever used. I could never learn backend javascript because why would I put in the effort when this exists.
Exactly me!
But I still learn Javascript lol
Out of curiosity, for people who have do projects in both Django and Ruby on Rails, which one would you prefer and why?
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.
Having done Rails and Django professionally for some time now I’d honestly recommend Django. While I love the meta aspects of Rails unlike other people I just think the Python library ecosystem is just so massive that you can quite literally do anything with Django without having to resort to multiple programming languages, etc.
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.
Depends on the project. I feel like Rails has better JS integration if your project really needs it. The out of the box JS experience with rails (import maps) is similar to django (static link from cdns), but the ability to set up esbuild from project generation makes it really easy Literally just my opinion though, but I haven't been pleased with an extremely nice method to set up django with javascript that doesn't feel hacky for local dev and deployment
I've preferred Django for a few reasons:
* 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.
This makes me happy. I wouldn’t have a career if it weren’t for Django.
Not even with a different stack?
Everyone's career started somewhere, and Django has been launching careers for 20 years now.
That project (a local one to me; was created the next county over in the KC metro) put a lot of food on my table and made a lot of value for my business partners. Happy birthday!
Hi neighbor! :)
django is the framework that made me fall in love with software development 18y ago.
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.
Django is great! First web framework I really dove deep into, and still what I reach for first when I'm starting a new project in that space.
I've shed a tear.
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.
I haven't used Django in many years, but I have fond memories of learning it and building my startup as a Django app.
Is the start up still going well?
[dead]
Love django. Whats the consensus on best way to use django in 2025? I've been going the headless route. Django for the backend and using vite or nextjs on the frontend with openapi specs auto-generated.
I've been a fan of Django templates and HTMX. I like how I can get interactivity without too much complexity. I do have specific parts of my website that rely on more complex tools, such as Codemirror. Even then, templates work well enough for me, so I haven't found a compelling enough reason to adopt more JS for my website.
Lots of growing love for returning to the template system and using HTMX with a bit of alpine sprinkled in as needed for interactivity.
It's still the best RDB schema creation/migration tool I know of. It has a crazy number of plugins to handle all sorts of unusual field types and indexing. I usually add django to any project I'm doing that involves an RDB just to handle migrations. As long as you avoid any runtime use of the ORM it's golden.
Love Django + Django-ninja but the clunky and incomplete async support is painful.
What is missing? The ORM works with asyncio, you can have async views, you can have long running connection-oriented async stuff for websockets etc (via django channels). Maybe there is something important that I'm missing but that seems more complete than most async-only frameworks.
I know one of the co-creators (Simon W) is quite active on HN :)
Simon wasn't a cofounder. He was an early employee/intern for LJW though. Perhaps the first person other than Jacob or Adrian to work on it.
Adrian and I co-created Django while I was working at LJW in a "year in industry" program from my UK university - which got me a student visa, so you could call it an "internship" but it was paid and 11 months long.
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
Wikipedia says Jacob was hired shortly before Simon's internship ended though. Not sure why you are trying to imply that Simon wasn't a co-creator.
https://www.quora.com/What-is-the-history-of-the-Django-web-...
In general when an intern works on something before you get there, and then you do all the real work, the intern doesn't get co-creator status.
You have silly rules.
simonw co-created Django. It's a fact. You don't have to like it.
Django was developed by Adrian and Simon, and the django site was created by Wilson Miner.
Jacob joined a little later but I think of him as a co-creator as he worked on Django substantially prior to the initial open source release, then acted as co-BDFL with Adrian for the next decade.
Django was the whole start of my career and I still thank it for many of my opportunities. I started in 2012 to work with Django at Billogram, then founded a Django consultancy which lead me to work at King 3 years later.
Who knows where I would be today if not for Django!
A really wonderful framework.
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.
Many fond memories of Google AppEngine using django on top of their datastore back in the day. 15 years later and DX is still quite similar.
Not to conflate a framework and a language, but there’s something about Django that makes me feel like I’m writing PHP. What is this effect?
When Adrian and I first designed Django we were PHP developers switching to Python, so quite a few Django pieces were inspired by PHP.
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.
This is surprising because the template language in particular feels so anti-PHP, it’s highly opinionated about not mixing code in with the template. I often wish it supported arbitrary Python.
Anyway, thank you Simon :)
Yeah, the template language was strongly influenced by NOT wanting to allow arbitrary logic like PHP does. I was already a fan of Smarty - https://www.smarty.net/ - which did a great job of separating out presentation logic in PHP.
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.
Laravel keeps copying Django (I mean it in a good way)
Laravel’s ORM was originally inspired by my now-long-dead PHP projects Idiorm and Paris:
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.
I think Laravel copied/inspired heavily from Ruby on Rails initially.
What's been copied? I see some overlap/homage to rails and some .net, but not django.
It should copy the query builder, in many ways Laravel is nicer, but Django's query builder is way more powerful with fewer lines of code.
Laravel borrowed much from Rails, Django and others. But unlike them actually moved forward.
It's likely the template-centric architecture with its own template language and the monolithic approach to web development - both Django and traditional PHP frameworks like Laravel share this pattern of tightly coupling views with server-side rendering.
Fastapi has completely replaced django for me. I do not miss orm at all.
I’ve also switched away from Django (to Litestar), but the ORM is the mean thing I keep missing from Django. SQLAlchemy feels really clunky by comparison
I think the ORM is fine. There's always some friction coming from mapping rows to classes and objects, but you can always drop down a layer and just pull raw tuples.
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.
What made you choose Litestar over fastapi (which seems to be the most popular choice right now)?
"If you're not using Django, you're probably just rebuilding it poorly."
I think FastAPI's one major design difference is its dependency injection mechanism. Django is designed to do things differently, with services provided through an app- or project-global collection of middlewares (although I haven't used it in a while, maybe something had changed since then) and while there are DI solutions for Django they don't feel "native" to me - not the way FastAPI does it. Either way works, of course - it's probably merely a matter of the preferred mental model.
Django-ninja is a combination of Django with fastapi.
It's Django and Pydantic, not FastAPI.
Django is somehow the one thing in Python I never enjoyed working on. I recommend it thoroughly to people running teams since it keeps devs disciplined, but I've always been a Flask programmer at heart. To each their own. I'm glad Django exists, it's eaten plenty a share of the pie that would have otherwise gone to Rails maybe.
The couple of projects I was forced to use Flask, they both ended as a bunch of poorly assembled libraries to work like Django (admin + orm + migrations + cache) but worse.
The drift from a simple Flask to monstrosity Flasknjo was so natural that I suspect it happens to a lot of people.
[dead]
They didn't manage to get a blog post that doesn't scroll horizontally in Samsung Internet on my Galaxy A54. Exciting times, but there is work to be done.