Happy 20th Birthday, Django | Hacker News Reader

Happy 20th Birthday, Django

djangoproject.com

578 pointsdavepeck185 comments

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.

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 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.

> to my knowledge, has never had serious incidents of either.

The magic removal branch in 2006 was one such case (of API instability). I recall another case circa 2007(?) with a "new admin". But, importantly, pre-1.0 Django made no guarantees of API stability. Post-1.0 Django has had a pretty rock-solid reputation for stability and security.

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.

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.

> 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

It was added over a year after we needed it (back in 2008/2009). I'm pretty sure our use case was taken as an input into the design of Django's database routing. We were certainly loud enough about it.

Haha well in that case thanks!

That early Python community was really nice. There were a lot of helpful strangers on the internet. Same with Ruby.

Indeed it was.

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...

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.

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.

Wasn't Django inspired from Rails

Not really, it was a strong inter-connection between the two at the beginning, going both ways, but I'd say that Django's design philosophy was its own thing. Granted, as time goes on things have started to become fuzzier and fuzzier in my head, and not only when it comes to programming languages/web frameworks and the like.

Source: me, I was programming in Zope 20 years ago (mostly hated it, although there were lots of interesting things in at a conceptual level), switched jobs at the beginning of 2006 and thanks to the new boss I got to use Django since February of 2006 (I think I still have a 0.96 version installed somewhere on an old instance, still does its thing).

Zope, shudder. It had some amazing ideas and I built a reasonably large app on it, but I’d rather swallow my own tongue than work inside an application server again.

Django and its contemporaries, like TurboGears and Pylons, were a breath of fresh air.

I liked Turbogears, but their approach of using "best in breed" libraries kinda burnt them as what that meant kept changing and leaving them behind.

It did. I think it was a great idea but other things skipped past it. I used Pyramid for a while and still appreciate it, but I can't imagine using it for my own new projects in a world where Flask and FastAPI and others exist.

Not exactly. Development on what become Django began sometime in 2003, before Rails was released.

Certainly the release of Rails — and, more importantly, the questions in the Python community about what _our_ web dev story would be — inspired us to extract the framework from the rest of our code and release it. And over the years we’ve taken some inspiration from Rails (as well as anywhere else we see good ideas). The biggest one probably being the basic ethos that web development should be easy — the focus on what we now call “Developer Experience” is the best thing Rails gave the world, I think.

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.

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)

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.

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.

Oh, I've been disagreeing with this take on the admin for such a long time!

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.

Many frameworks have the "admin" sections with very similar drawbacks. It gets you 80% of the way there in 20% of the time, but the remaining 20% is very difficult to get done.

One framework which does not have this problem - or at least minimises the problem, is the Yii framework for PHP. A very nice and underrated framework

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.

> 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/

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".

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.

> How can you be an unrelenting critic of Python but love Django?

Writing a Django app is like writing Python, but it's more like writing Django.

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!

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 also started my career with Django using 0.96 in college and 1.1/1.2 with my first industry jobs. It was a really empowering framework and it is surprising to me that I still pick it up today for new projects when appropriate. I started attending the Seattle Django Users Group and discovered there were a decent number of "ex-pats" from the Lawrence Journal-World who were there as it was being developed.

Before I knew it I was helping organize the user group including our weekly coffee shop meetups in addition to the monthly lecture gatherings. There were a lot of local startups (including some very well known businesses and non-profits today) very actively collaborating on these tools. Django was really evolving the way a lot of companies used software and automation.

It wasn't only the engineering, the community ethos of Django both at the local and international scale (and the Python community as a whole) really made it possible to branch out and accelerate my personal software engineering journey.

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.

My favourite thing about Django is the versioned documentation. Land on a page - any page - and you can trivially read the docs on that subject all the way back to 1.8. That's ten years old. And it works, because Django knows how to patiently deprecate APIs and migrate things. They built one docs site, and it still works. It didn't bitrot. The URLs haven't changed. They didn't restructure everything and force people to rewrite their entire projects or be judged quietly. Every single time I end up working with a framework where docs are littered across a handful of different websites for different versions and types of docs or whatever, I think of Django and I wonder why people have such terrible taste.

Alas, that tends to be the majority of my experience with Django. Using it for one-off personal projects and quietly wishing for the current new shiny JavaScript thing to go away. It still feels like home, but most of my time is somewhere else.

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.

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.

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

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!

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.

Yeah, that is a bit disheartening. It’s a reminder of how vital it is to support open source tools, especially when they’re going up against massive, well-funded competitors. These projects often power the backbone of the internet and tech ecosystems, but they can’t survive on goodwill alone.

If we want innovation, transparency, and community-driven development to thrive, we have to step up — whether it’s donating, spreading the word, or helping out however we can.

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.

Perhaps. But there was a confluence of things that naturally fit with Django (and Python) that worked well for me.

It feels surreal that every time a Django topic comes up on this site it's flooded with people praising it and proclaiming how much they love it.

I honestly found it to be the absolute worst Python framework I've ever worked with. I found it so hard to intuitively write code for it because it just does stuff for you in the background and you can't always see the execution order of code, especially when leveraging that default dashboard feature. I lasted 11 months in a role that used Django exclusively. I'm happy for people that built a career with it, but it just blows my mind people aren't more critical of it. Not that they necessarily need to be though.

It's probably because you never did the Django tutorial. Once you understand what what does, it's actually very nice, because you don't have any boilerplate. Django takes care of the boring parts, and you can focus on making the app. But at the same time you still have control to customize everything to your liking. And the docs are very good and complete, so you can always look up stuff if you don't understand it.

Two things are true for me:

* I think Django is an amazing piece of software, developed by a lot of clever, brilliant people.

* I don’t want to use Django.

I think Django is unmatched for building a Django app. That is, if you want to connect to a relational DB, make CRUD queries with its OR , and spit out the results in the exact HTML or JSON it supports, you’re going to have a great time. If you want to hit non-relational backends (including APIs), form your own outputs, or reuse the SQLAlchemy models you built for another part of the project, you’re entering a world of pain. Mark it zero and move on. Turns out most of my stuff is doing non-Django patterns. But if that were different, if I were building a traditional website on top of PostgreSQL and starting with a blank slate, sure, it’d be high on my list of options.

It’s a little clunky in places, but it’s fantastic at having a solution ready for almost any problem.

The one thing that still bugs me is that you have to wire everything together manually. But other than that, much better than most.

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.

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.

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 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

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.

Understand you're going to get a bit of self-selection bias as the people reading the comments for this article are likely to be Django fans.

As someone who has used quite a few MVC frameworks professionally, in my opinion, Ruby on Rails continues to be the gold standard in many ways. Django feels more like a toy framework which, if I may say so, appeals mostly to developers who picked up Python as undergrads and then were not impelled in their particular careers to master other languages.

Instagram doesn’t agree.

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'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 love Django. I still reach for it for most projects. I really wish they would introduce a more modern frontend system though. I find it hard to go back to templates after using react. It’s easy enough to use Django and react, but it would be amazing if there was a more modern solution within Django for frontend.

Agreed

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…

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 is timely given the discussion under this yesterday: https://news.ycombinator.com/item?id=44557115

A lot of engineers owe their careers to the framework, including me. Thank you Django. Happy Birthday.

I started with Django as my first "proper" web framework, have explored quite a few others since but always come back to Django eventually. It's just such a good baseline for a framework, not just in its features, but also in it's strong philosophy (many frameworks I've found lack this, a lot of good ideas but no cohesion between them), stability and perhaps most importantly, it's incredible work on documentation.

Thank you to all the contributors!

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 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 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?

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.

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...

The web framework for perfectionists with deadlines.

The coolest tagline ever.

For something to endure so long in the web dev world is a real testament to all the people in the community that do the mundane 'gardening' work each day. Pruning back 'dead' parts of the framework and smoothing out rough edges as the world evolves.

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.

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 + 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.

There are numerous things still missing in terms of async support. Most notably for me is DB transaction support which leads to most non-safe endpoints running on the shared sync_to_async thread and me having to separate my code into one async function calling another sync function wrapped in sync_to_async.

In fact if you look at the source there is a lot of async methods in the framework itself which just straight up calls sync_to_async e.g. caching. This doesn't matter as much as hopefully it will get added proper async eventually. But I think believing your requests wont block just because you're using async is a bit naive at this point in Django and the async implementation has been going for years.

Not to mention that the majority of third party libraries lack support for async so you'll probably have to write your own wrappers for e.g. middleware.

> But I think believing your requests wont block just because you're using async is a bit naive at this point in Django

TBH personally I have yet to work on any professional async Python project (Django based or not) which did not have event loop pauses due to accidental blocking IO or CPU exhaustion.

I take your point fully though that a lot of Django's "async" methods are really using a thread pool. (True for much closed source async code as well!)

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.

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.

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.

I wanted to like HTMX and Alpine. But after a few medium sized projects with it I went back to vite/react for larger frontend. I found it so difficult to come back to old htmx/alpine code. If you got a complex UI to maintain I would personally recommend the React route. It is very easy to setup with Django.

Happy birthday, Django. I've used, read and loved just about every part of you from the magic-removal days onwards when I had the Rails book on my desk and your docs in my browser, and you (and Python) won. I loved spending thousands of lines in a models.py modelling all sorts of problems before I touched a single line of other code. You got me into open source and then you got me into writing JavaScript seriously via the first large library I ever wrote in it (a port of what was then django.newforms - thanks and vale, Malcolm - for Node.js and the browser). You're my favourite framework I haven't actually used for a decade.

Django's docs can't be praised enough, they've always been the gold standard that I aspire to, taking a similar approach to documenting my own stuff seriously leveled me up, and great docs written for humans by humans stand out even more amongst the painlessly effortlessly generated slop of the day that's painful and effortful to read.

Template inheritance was so elegant and simple compared to the Java and PHP I was professionally and personally using at the time, but 20 years later and after having used Hono, one thing I'd love to see in Django is... JSX in Python! Imagine:

    def Layout(title: str, children):
      return (
        <html>
          <head>
            <title>{title}</title>
          </head>
          <body>
            <h1>{title}</h1>
            {children}
          </body>
        </html>
      )

    def message_list_view(request):
      messages = ['Good Morning', 'Good Evening', 'Good Night']
      return render(request,
        <Layout title="Messages">
          <ul>
            {[<li>{message}</li> for message in messages]}
          </ul>
        </Layout>
      )

I'm newish to Django. Been using it for about a year. I had some experience with React earlier. But I'm more of a data engineer.

Django Cotton [1] scratched my itch fully. Very composable. Being able to pass HTML to components (E.g. you create a modal which takes a content slot) removed so many of the warts I felt using the standard Django templating.

It's not JSX, but it plays well with Django and makes it feel like I can create a real design system of components without a ton of JINJA.

https://django-cotton.com/

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.

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.

This sounds like the Musk rule of company founding

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

Hey Simon and everyone else.

I was write to be downvoted. Apologies for getting it wrong. I started using Django in 2008, and Simon's influence was very apparent at that point - my comment was not meant to belittle his contributions (I also follow him on Mastodon - big fan of his comments on HN and there).

I guess my memory was just wrong. I knew Jacob was hired after Adrian - but I thought they both started Django after Jacob joined, and Simon was an early intern. I had the ordering totally wrong.

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.

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.

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.

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...

The ORM+migrations bit at least is pretty solid with Flask. I quite like bolting little bits on that I might need or not need.

It's like saying Django+DRF is a monstrosity compared to FastAPI/Litestar.

Having been using Django for more that a decade, I will continue to bet on Django for the next 10 years

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.

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.

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.

I owe my career to Django, I used it to build some projects when I first started my career, and recently reached for it when I was asked to build another huge project. The built in admin panel is the killer feature.

I remember when Django first came out, and I loved using it. For old time sakes, I went back to their website and they still have the tool bar on the right side, which I use to love. Happy birthday 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.

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.

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?

Laravel keeps copying Django (I mean it in a good way)

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.

I think Laravel copied/inspired heavily from Ruby on Rails initially.

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 do love Django too! and my developtment with more users (not most deployed) is running on Django :)

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.

Right now that is my biggest pet peeve with Django, in the marketing area is a bit outdated and boring. What was about the Django Unicorn logo?

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.

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.

I think a great combo would've been Django's features, packaging and most importantly documentation, but with SQLAlchemy and Jinja2 technologies underneath.

That would have been hard since both of those projects came out after Django, but just an FYI Jinja2 templates are supported and nothing stops you from using SQLAlchemy. Granted you lose a lot of the tight intergration that makes Django great to use.

> That would have been hard since both of those projects came out after Django

Well, yes I didn't mean Django from the start! I mean now.

The nice thing about Django is that there's nothing stopping you from doing that. You'll have to give up the Django Admin if you use SQLAlchemy for models but you can still do it. I have several projects that use Elasticsearch as a backend and one that's based on JSON documents in Git repositories. You can totally do it!

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-...

Happy to see Django still thriving, after flask it became my favorite web framework. Congrats to Django and he community!

I hear about the "Django philosophy" in this thread. What exactly is it?

Poorly and partially re-implementing Ruby on Rails.

It pretty well explained in their docs: https://docs.djangoproject.com/en/5.2/misc/design-philosophi...

If you had to learn Django today in 2025, what resources would you recommend?

Django docs are still the best way to learn it.

I have made some money by building Django apps in the past.

I remember the Django movies.

Fastapi has completely replaced django for me. I do not miss orm at all.

Django-ninja is a combination of Django with fastapi.

It's Django and Pydantic, not FastAPI.

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.

This is my pain point in Django as well, the query DSL. 10+ years with Django and I still don't know how it's supposed to work, given it's all done within the namespace of a function call.

Fortunately, I now have AI to write any Django queries for me.

There's nothing stopping you from using Django with SQLAlchemy or even raw SQL.

What made you choose Litestar over fastapi (which seems to be the most popular choice right now)?

Mostly the better documentation (last I checked FastAPI docs felt more like a series of blog posts than actual docs, but maybe that's improved). I also preferred the community-driven approach of Litestar as opposed to FastAPI's BDFL-type development structure.

I think there were also some technical details I liked better about Litestar where it was more explicit about things while FastAPI was more "opaque magic happening in the background", but to be honest I don't remember all of those.

We chose Litestar over FastAPI mostly because they seemed very similar, but Litestar had a more distributed governance; i.e. a larger bus factor.

We are jealous of some FastAPI features though, so it's possible we could migrate, as Litestar's mapping between domain models, database models and API models isn't as flexible as we'd like.

"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.

Lawrence Journal World birthed Django, and now runs on Wordpress.

https://www2.ljworld.com/news/2018/jun/26/redesign-ljworld/

https://en.wikipedia.org/wiki/Lawrence_Journal-World

Yeah after the acquisition I’m sure they moved everything to whatever the parent company was using which totally makes sense.

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.

Reply on news.ycombinator.com