20 years is an eternity in web development, and Django's longevity is a testament to its brilliant design philosophy. Happy birthday to the framework that gets things done.
Django is pragmatic, secure, and unbelievably stable. It's the framework you choose when you want to build a real business, not just chase the latest trend. It has powered some of the biggest sites on the web, and it's still the best choice for a huge number of projects.
Here's to 20 more years.
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
As a student, ask around or check with your advisor. Most labs will have positions for students interested in coding "grunt work" because students are cheap.
As a professional, apply to Masters/PhD programs in your area of interest, or be young and an expert in an obscure technology the lab uses. Some labs will hire out contract work, but can't pay well (hence be young). Other labs have grant money to bring in non-phd researchers, but to get the job you'll both have to be an expert in a required technology, and be able to contribute actively to the research area of the lab. At Yale, I did this, as second author on a conference paper showing novel methods for applying machine learning in multi-agent, sensor -driven environments. It justified my paycheck as a researcher while I spent the other half of my time fixing broken code for other researchers and writing the first version of the software for our lab spinout.
Edit: I just want to clarify that my experiences with this don't go past 2010, so YMMV. Getting old is tough sometimes, it still feels like almost yesterday.
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.
I also started my programming career thanks to Django, and I started using it while working at a local newspaper, so bonus points there! We built a system that our sales people could book ads, and then we could layout the newspaper through a canvas based tool (used Fabric.js for that), and then send the pages + ad stack to InDesign to be built. Was great to work with the whole process and Django was really never a limitation. I ended up moving on, but it'll always have a place in my heart.
Same here. Built first web application in Django, have tried all the other frameworks over the years, and am now back to building another webapp in Django...
> 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
I don't think Django could have talked to sqlite over the network, or would have really solved any problems. When I say physically separate, I mean it in the pre-cloud sense: one front end server (Django) dynamically connecting to a database on a remote server (based on the user account), which had a database continuously logging streams of sensor data from local IoT devices.
What I did was change the architecture to support centralized aggregation in a large co-located Postgres server, implementing security to managed permissions for writers (sensor gateway) and readers (user accounts).
Eventually we had to write a pg backend similar in concept to timescaledb to handle the massive scale of sensor data we were ingesting...but that's another story entirely.
Django has supported database routing for ages. I've abused it for setups like yours (at least as I vaguely understand from the post details) to avoid using a datalake
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 am from the area so was at that event. I still have my bamboo badge.
The Documentation as Empathy talk is one that I still think of often. It was fun to hang out with those guys after too. Lovely folk.
Thanks for mentioning this talk, very nice to see it laid out.
I'm a really happy Django user for 15 years and hopefully I'll still use it for at least another 15!
Django has a lot of beloved features but I think one of the most important is it's stability through the years: I actually have production apps that started on Django 1.4 and python 2.6 and now are updated and with with Django 5 and python 3.13.
All this without too much effort on my side or paying companies to support my projects.
So thank you Django people for the hard work!
It's nice to see software last like this. Some personal anecdotes
Back in the day, when I was first picking up on frameworks, I saw Django and TurboGears. A friend of mine went with Django while I went with TG. I don't really know what the status of TG is anymore but back then, I thought SQLObject, Mochikit etc. were awesome. I think I took the wrong fork in the road then.
I once attended a "web" panel at PyCon India where there was a discussion between proponents of various frameworks. The Django guy had a nice quote - "I don't know what the standard Python web framework of Python will look like in another 20 years but I'm quite sure that it will be called Django". His point was about the longevity of the project and it's ability to adapt.
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.
> There's still no framework in e.g. Go that comes anywhere close to matching Django.
I don't think Go is an apt comparison. Its philosophy is to eschew traditional frameworks in favor of relying on the rich standard library as much as possible, and on small external libraries when needed. This does lead to a duplication of effort and bespoke mini-frameworks that only technically have a fraction of the features of a typical framework, but the end result is much simpler, more understandable and flexible. All in a highly performant language with a great ecosystem, packaging, and tooling <3
That said, Django is an amazing framework that has stood the test of time. Like many here, it was one of the projects that kickstarted my web development career. Kudos to the team and community, and here's to another 20! \o/
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)
Django Admin is a bit of a trap though ;) it's powerful enough that you can build an entire application with it, custom views and powerful filtering and ACLs and whatnot, it easily gets 80% of your job done with almost nothing but a declarative DSL.
But the remaining 20%? Now you've dug yourself a hole with no recourse but a complete rewrite. It's time/money you would've otherwise spent anyway, but that sunken cost fallacy hits hard.
The Django docs do explicitly state that the admin is just meant for when you need a quick admin dashboard for internal applications. Anything outside of this domain or more complex, you should consider building your own.
Oh, I've been disagreeing with this take on the admin for such a long time!
Yep. Unfortunately the trap extends further than just the Django admin site itself. ModelForm and generic views are what power the admin site and they're exposed and you're encouraged to use them. Same with the low level crud permissions it creates. Once junior devs start doing the remaining 20% without rewriting you end up with something really difficult to maintain.
It's not just the junior devs. A client once came to me with something that looked like 99.9% is just ModelForm, some CSS, and money. I should've taken 25% upfront and said no to the increasingly absurd change requests, but oh well.
https://backpex.live/ is a pretty good Phoenix Admin. Django's admin is still unmatched though.
Sometimes I think it's better to think of rails as a dialect of Ruby.
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.
I'm not sure how this is even a question. I love Java, I hate a number of its frameworks. I've used Django and really liked it but I find Python awful for large codebases. Languages and tools made with the language are two different things.
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 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
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.
I’ve used Django since 0.96 and keep coming back to it any time I need a web site that works. I’ve dabbled in other stuff but this one just clicks for me.
Here’s to another 20!
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.
Of our US $300,000.00 goal for 2025, as of July 13th, 2025, we are at:
- 25.6% funded
- $76,707 donated
:(
This funding gap highlights the persistent challenge of sustainability in open source - Django powers billions in business value but struggles to secure a fraction of that for its own development.
The only issues I see with Django these days are a lack of native python types and especially these days with type hints included in the language I think there should be efforts taken to have this present within the framework itself. I know there's packages that provide it but I'd prefer if it was coming from Django itself.
Otherwise it's a fantastic framework that's extremely flexible and a joy to work with most of the time. Due to its longevity, it has such a rich ecosystem that's enviable and only mirrored by the likes of rails.
Yeah, to have a properly typed codebase I'm basically isolating the ORM and models from the rest of our app. So there is a selector layer that fetches data, and then maps that do dataclasses/pydantic, instead of passing the django model objects around.
It's a good practice anyways I feel, as the application grows you don't want different "apps" to know too much about models in other apps.
But even with this flow, in my selector layer I still have to do "# type: ignore" any time I've used an annotation. Especially due to python's lacking lambdas, when I map data from a queryset it often has to be a properly defined function, but then whatever annotation django-stubs managed to apply is lost anyways.
This is timely given the discussion under this yesterday: https://news.ycombinator.com/item?id=44557115
Django was the first Python framework that made sense to me and that I enjoyed working with. Also got me my first Python job after years of Java development.
I have moved on to other things since, but I miss it's simplicity and the general "it just works" aspect of the framework.
Happy Birthday, Django! If you were a music genre, you’d be heavy metal — loud, structured, and built to last.
5.2 release was recently discussed here on HN: https://news.ycombinator.com/item?id=43556656
I would’ve thought jazz…
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.
I haven’t done a ton with Rails professionally - but in my mind, if I was doing customer facing CRUD I would reach for rails, I think the deployment ecosystem and development experience is a bit better.
Django, however, is wonderful for internal tooling, or anything where you need to plug in Python libraries. GIS is a clear win for Django, as well as custom BI work or data analytics
Django, however, is wonderful for internal tooling, or anything where you need to plug in Python libraries. GIS is a clear win for Django, as well as custom BI work or data analytics
Can you share more here? Would you go the route of django templates for internal tooling?
How is GIS a clear win for Django, when the largest gis project on earth (OpenStreetMap) runs on rails?
How is the largest GIS project, or OpenStreetMap, relevant example for most projects?
But, to help those wondering about RnR vs Django for dealing with GIS data, the answer is the python ecosystem is just larger for dealing with GIS data. There are more libraries like fiona, shapely, gdal examples, etc. Django ORM supports all of the PostGIS functions, geos and ogr object helpers.
Rails does not have an alternative for PolygonField, Raster support, or geometry field queries like filter(geom__intersects=area)
I've dabbled with some ruby and jruby with rails about 12 years ago. It was fine. I used Django briefly around the time 1.0 was about to be released sixteen or so years ago. And I later encountered it again on some different projects.
Neither Python nor Ruby are my main languages. I used to do a lot of Java and the last eight years I'm using Kotlin mostly. But I've done a lot of freelance and consulting projects as well where I'm happy to use whatever people are using there. I did some pyton and typescript+react recently. I've dabbled with a few Go and Scala projects even. And I'll grudgingly admit to having touched some Php even.
So here's my view:
For me, Django is slightly better than Rails because the people seem to prioritize it just being rock solid, stable, and simple. Python isn't the best, or most elegant at anything it does IMHO. But it's always simple and rock solid and I love it for that. That's what makes it a popular choice for non computer scientists working with data, people in university doing whatever, etc. Ruby was always the more esotheric choice. Lots of people obsessing about meta programming, programming esthetics, and changing their mind about how stuff should be done every 3 months. I found rails to be a bit limited and convoluted. Django and rails do similar things in the end.
The last time I did python, I picked Fastapi and ignored Django. Ruby is fine as a language but it seems to have gone out of fashion a bit. The last time I used it I was using Sinatra, not Rails.
I just prefer light weight frameworks. And I'm a bit opinionated on being able to use the full power of SQL and not having to proxy everything I do through some straight jacket ORM framework that does a lot of magical things in some mediocre way. I can create a table myself and mapping rows to objects isn't rocket science. And I'll write and optimize my queries myself. It's not that hard, and it's not consuming a lot of my time generally. So, the value of optimizing that time is not very high too me. The value of changing and optimizing it when I need to is. And so is the value of just doing it right the first time. And LLMs allow me to generate a lot of the boiler plate stuff (because it is so easy and straighforward). And I'm pretty good at abstracting and encapsulating that. ORMs don't really solve a problem I have.
In the same way server side model view controller (rendering HTML and serving it to the browser on every request) went out of fashion ages ago. Most web and mobile apps use APIs instead. And while server side rendering still is a thing these days, I don't really see a big need for that. It's an optimization. And not one I find I need a lot.
And since server side MVC and ORM are the main point of using Rails or Django, I don't really use either a lot these days.
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.
Corey Schafer also has a beautiful playlist on Django making learning how to use this framework a cakewalk: https://www.youtube.com/playlist?list=PL-osiE80TeTtoQCKZ03TU...
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.
+1! It may not be sexy, but its lindy and worthwhile the time investment. Likely to last 10-20 more years
I owe the current (probably final) phase of my professional IT career to Django, now having used it in production of ~15 years. I got in around the 1.0.* release mark so I missed any possible early instability, and have found it an absolute pleasure to build with since. It's been stable, reliable, regularly updated and (importantly) easy to teach to new devs. The documentation and API have only gotten better in the intervening years. It remains (along with PostgreSQL) one of the few technology choices that have we have never regretted or second-guessed in my organisation.
This makes me happy. I wouldn’t have a career if it weren’t for Django.
Not even with a different stack?
Perhaps. But there was a confluence of things that naturally fit with Django (and Python) that worked well for me.
Everyone's career started somewhere, and Django has been launching careers for 20 years now.
Django + REST framework is what I cut my teeth on doing web programming in my first job. It's a wonderfully written codebase, I'm very thankful I had some great code to learn from, and it wasn't even 10 years old then, I didn't even realize.
Congrats team! Glad to see it's still thriving and a great option to pick up for beginners.
Django I love; last time I tried REST framework it felt like the polar opposite of DRY. Not sure if this was intentional or not.
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.
The most amazing and well thought out web framework I’ve ever used.
Cannot wait for the async and bg work interface!
Happy birthday Django you cutie
I started with Django 1.6 and it got me my first job. Although I generally use flask now. Thank you Django.
I started with 0.96 and it got me my first job. The admin was a blast. Thank you django.
Happy 20th birthday, Django! You've certainly unchained a lot of startups, businesses and enterprises to build out a ton of cool things.
Thanks to the creators, contributors, community, and maintainers.
I'm more of a Rails and Phoenix guy myself, but I have a lot of respect for this project. Never worked super deep with Django, but have worked with Flask and Tornado in the past.
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! :)
The web framework for perfectionists with deadlines.
The coolest tagline ever.
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.
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.
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]
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!
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.
Lots of growing love for returning to the template system and using HTMX with a bit of alpine sprinkled in as needed for interactivity.
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.
This damn framework has provided me more value than almost anything else I've ever used in my 20+ career.
It's also somehow wound up being a north star of sorts when I find myself needing to reimplement behavior in other web stacks; I usually just go read how Django has done it, then adjust as necessary.
Hell of a run, here's to the next 20.
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.
This sounds like the Musk rule of company founding
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.
I have made some money by building Django apps in the past.
Happy birthday! I've been using it for almost ten years. It was already mature at the time. Such a well-thought, perfectly documented framework.
Happy to see Django still thriving, after flask it became my favorite web framework. Congrats to Django and he community!
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.
As a Flask/Fastapi guy I lately made a project with Django and I have to say I am very impressed with how much the defaults worked for my project and how much of the complicated issues were taken care of (e.g. database migrations, prrmission structures).
I'm a Django guy and I recently wrote a FastAPI because it needed some async stuff. But that's a rare exception. Most times I will still choose Django and just go sync, which will still scale quite a bit. I might rewrite the FastAPI app in Zig, come to think of it.
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.
Custom tags and filters have been my escape hatches when the DTL is not taking me where I need to go.
https://docs.djangoproject.com/en/5.2/howto/custom-template-...
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.
> But unlike them actually moved forward.
Right. I love Python and Django but the "batteries included" claim seems like an anachronism.
Job queues, WebSockets/SSE, setter/modern form rendering, API framework, components, comprehensive CLI, frontend support etc are what the competition have better integrates and/or first party.
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.
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.
Active Record pattern forces the architecture into a big ball of mud. But hey at least you get "views.py" etc...
[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.
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.
I remember the Django movies.