I don’t write much Python anymore. Most of my work is in JavaScript: edge functions, lightweight deployments, cheap infrastructure. But if you asked me which tool had the biggest impact on how I think about code, I wouldn’t name a language or a library. I’d say Django.
The framework that taught me to think about architecture
I’m self-taught. I have no CS degree and never had a bootcamp curriculum walking me through design patterns. I learned by building things, breaking them, and figuring out why they broke.
Django was the first tool that told me how to organize things, and meant it.
Every Django project has the same skeleton: apps, models, views, URLs, templates. Each piece has a job and each job has a place. You follow the structure without arguing, and somewhere along the way you realise it’s teaching you something.
That’s what MVC does when it’s done right. It keeps your data logic away from your display logic and your routing away from your business rules. Once you’ve learned that separation, you can apply it in other languages, other frameworks, and other problem domains.
Before Django, I wrote code that worked. After Django, I started writing code that was also organized.
A dinosaur, in the best way
Django was built in 2003 and open-sourced in 2005. The JavaScript ecosystem has gone through dozens of framework generations since then, and Django has outlasted almost all of them.
When you build on Django, you’re building on something that thousands of production apps have already stress-tested, run by teams of every size in industries from media to fintech to government services. The edge cases have been found, the security patches shipped, and the documentation is thorough because every question has already been asked.
I like working with something that mature. You spend less time wondering whether the framework will let you down and more time on the problem you’re actually solving.
The motto
“The web framework for perfectionists with deadlines.”
I used to think that was a clever tagline. After a few years of shipping things with it, I think it describes a real design philosophy.
Django gives you an ORM, an admin panel, authentication, form handling, and a migration system out of the box, without ceremony. You can have a working app with user login, a database, and an admin interface in an afternoon, and that comes from years of accumulated good design.
It respects your time. It doesn’t make you wire everything up from scratch to prove you understand it, and when you need to go deeper, the structure guides you instead of getting in your way.
The limitations
Django isn’t perfect.
Deployment is not its strong suit, at least compared with the zero-config experience of modern JavaScript hosting. You need a server, a WSGI setup, and proper database configuration. It follows older web conventions, and there are fewer one-click deploy platforms than in the Node world. Railway, Render, and Heroku make it straightforward, but it’s never quite as frictionless.
And if you’re building something that needs to run at the edge, close to users around the world, Django is the wrong tool. JavaScript runtimes win that one.
Why I structure my JavaScript like I never left
I work in JavaScript now because the deployment story is better for what I build. Edge functions, serverless, and cheap horizontal scaling all work more cleanly there.
What I noticed is that few JavaScript frameworks organize a codebase as cleanly or as meaningfully as Django does. The ecosystem is fragmented, conventions vary wildly, and the same kind of project can look completely different depending on who started it.
So I kept the pattern. My JavaScript projects are structured the way a Django project would be: clear boundaries between data, logic, and presentation, and each module with a single purpose in a predictable place.
It isn’t fashionable, and it isn’t what the tutorials show. But when I come back to a project six months later to fix a bug or add a feature, I know where to look. The code is boring in all the right ways.
I’ll take boring and predictable. When you’re debugging something under pressure months later, you won’t be grateful for the clever, anything-goes approach. You’ll be grateful for the structure.
What Django gave me
Django gave me a vocabulary for architecture. It showed me what organized code looks like in practice. I came to care about structure because I could feel the difference between code that had it and code that didn’t, not because someone told me to.
If you’re self-taught and want to take your code quality seriously, including how the code is built and not just what it does, spend some time with Django. Even if you never ship a Django app to production, the way of thinking sticks. Mine certainly did.