Django was my first big freelance project, and still feels tremendously cozy to use. I've done some goofy things with it and it's always served me really well. Thank you Django
Django is awesome, but I wish there was an easy way to use modern web frameworks with it.
A lot of times it's either through Nextjs/Nuxtjs + Django as an API or complex bundling process which requires a file where you register bundle versions/manifests then another build process which embeds them into template
Yes the API process is very complex and then you have to have a team with proficiency in two parallel sets of web technologies -- python vs javascript. That said, the fact that you can go that route means that Django can be a good pick for early-stage projects where you don't need a frontend framework, because there's the optionality to add it later if your project really requires it.
I really love django and everything around it, but I would also like to write a webapp in Java.
Getting django + rest_framework up and running and actually be productive takes me max 10 minutes, trying to do the same with spring boot I am a week in and I had to open the jakarta specs to understand the magic.
One thing Django has going for it is that the "batteries included" nature of it is perfect for AI code generation.
You can get a working site with the usual featuers (admin panel, logins, forgot reset/password flow, etc) with minimal code thanks to the richness of the ecosystem, and because of the minimal code it's relatively easy for the AI to keep iterating on it since it's small enough to be understandable in context.
why would you need batteries included? the ai can code most integrations (from scratch, if you want, so if you need something slightly off the beaten path it's easy
I think the logic can be applied to humans as well as AI:
Sure, the AI _can_ code integrations, but it now has to maintain them, and might be tempted to modify them when it doesn't need to (leaky abstractions), adding cognitive load (in LLM parlance: "context pollution") and leading to worse results.
Batteries-included = AI and humans write less code, get more "headspace"/"free context" to focus on what "really matters".
As a very very heavy LLM user, I also notice that projects tend to be much easier for LLMs (and humans alike) to work on when they use opinionated well-established frameworks.
Nonetheless, I'm positive in a couple of years we'll have found a way for LLMs to be equally good, if not better, with other frameworks. I think we'll find mechanisms to have LLMs learn libraries and projects on the fly much better. I can imagine crazy scenarios where LLMs train smaller LLMs on project parts or libraries so they don't get context pollution but also don't need a full-retraining (or incredibly pricey inference). I can also think of a system in line with Anthropic's view of skills, where LLMs very intelligently switch their knowledge on or off. The technology isn't there yet, but we're moving FAST!
Do you guys find Django includes enough batteries? Why or why not?
I find myself using Cookiecutter Django [^1] more often than not, better auth, a bunch of boilerplate configs, S3 and email setups if you want, and other stuff rather than have to jiggle with "Django infra" myself
Because the web was made to render documents, but users want apps. CSS in part is so confusing because its original incarnations pulled heavily from traditional print media layout terms.
Everything since then was an attempt to leverage JS to turn documents into applications. Why? Ask any user.
I'm not in web anymore but, to me, it seemed easier to visualize richly linked data in Angular than having a Django template render it. Once you have the mindset of making your website into an app, you are tempted to move navigation to the app too. That way your app can keep delivering its core user function without the interruption of a page load.
In retrospect it was slightly hubristic, as in reality you sometimes have to force reload SPA's, and if you're integrating on top of legacy systems that you just link to, you're not really avoiding the bad UX of a jarring page load. But I do find it elegant to separate presentation from data.
Aside from the usual separation of tech stacks for different teams, the big thing for me is lack of any sort of type hinting or safety in templates at least in the big frameworks such as Django, Rails etc. I would much rather work with a separate build process that utilizes typescript than deal with the errors that come out of incorrectly reading formless data and making typos within templates.
- Strict team separation (frontend versus backend)
- Moving all state-managament out of the backend and onto the frontend, in a supposedly easier to manage system
- Page refreshes are indeed jarring to users and more prone to leading to sudden context losses
- Desktop applications did not behave like web apps: they are "SPA"s in their own sense, without jarring
refreshes or code that gets "yanked" out of execution. Since the OS has been increasingly abstracted under the browser, and the average computer user has moved more and more towards web apps[1], it stands to reason that the behavior of web apps should become more like that of desktop apps (i.e. "SPA"s)[2]
(Not saying I agree with these, merely pointing them out)
[1] These things are not entirely independent. It can be argued that the same powers that be (big corps) that pushed SPAs onto users are also pushing the "browser as OS" concept.
[2] I know you can get desktop-like behavior from non-SPAs, but it is definitely not as easy to do it or at least to _learn it_ now.
My actual opinion: I think it's a little bit of everything, with a big part of it coming from the fact that the web was the easiest way to build something that you could share with people effortlessly. Sharing desktop apps wasn't particularly easy (different targets, java was never truly run everywhere, etc.), but to share a webapp app you just put it online very quickly and have someone else point their browser to a URL -- often all they'll do is click a link! And in general it is definitely easier to build an SPA (from the frontender's perspective) than something else.
This creates a chain:
If I can create and share easily
-> I am motivated to do things easily
-> I learn the specific technology that is easiest
-> the market is flooded with people who know this technology better than everything else
-> the market must now hire from this pool to get the cheapest workers (or those who cost less to acquire due to quicker hiring processes)
-> new devs know that they need to learn this technology to get hired
-> the cycle continues
So, TL;DR: Much lower barrier to entry + quick feedback loops
P.S (and on topic): I am an extremely satisfied django developer, and very very very rarely touch frontend. Django is A-M-A-Z-I-N-G.
This would make an interesting poll. I think that's possible here? Maybe with some karma threshold, I don't seem to be able to make one.
We use flask and go at work. I've been micro-framework or roll-my-own-framework most of my career. Go is new for me though, and it's grown on me enough that it's what I prefer for new web-facing projects even for little personal things.
I"m almost entirely dotnet these days, with a smattering of Go here and there.
I work in ops though, so I'm not building consumer-facing products but mostly IT glue code and internal tooling (mostly Go), dashboards, business report generators, gluing SaaS together, etc. (mostly dotnet/C#).
I agree that Go is a good choice for web services. I disagree that it's the only thing Go is good at. DevOps tooling and CLI tools immediately spring to mind.
I started using Django before the official 1.0 release and used it almost exclusively for years on web projects.
Lately I prefer to mix my own tooling and a couple major packages in for backends (FastAPI, SQLAchemy) that are still heavily inspired by patterns I picked up while using Django. I end up with a little more boilerplate, but I also end up with a little more stylistic flexibility.
I target 5.10.1 mostly. This is for a project I started in the late 90's. It uses CGI::Application, which is less a framework and more a method lookup table converter of queries (although I built a path info convertor on top of that). It's still maintained, although before Covid, it was my livelihood.
About a quarter of a million lines of code, excluding the libraries I pull in. I'm mostly self-taught, they wouldn't even let me get a minor in Comp Sci, since I didn't have the math background (Needed Calculus, I completeled Algebra 2 in hs). Boneheaded Uni.
Raku: Second-system effect poster boy. Sensationally dysfunctional community. I think Pugs is what was actually really incredible and Audrey is probably one of the most intelligent people in... the World? Up for contention, but top 10.
Django was my first big freelance project, and still feels tremendously cozy to use. I've done some goofy things with it and it's always served me really well. Thank you Django
Django's batteries included setup makes it a no brainer for almost any project big or small. Kudos to the team and contributers
Django is awesome, but I wish there was an easy way to use modern web frameworks with it.
A lot of times it's either through Nextjs/Nuxtjs + Django as an API or complex bundling process which requires a file where you register bundle versions/manifests then another build process which embeds them into template
both are so complex
Yes the API process is very complex and then you have to have a team with proficiency in two parallel sets of web technologies -- python vs javascript. That said, the fact that you can go that route means that Django can be a good pick for early-stage projects where you don't need a frontend framework, because there's the optionality to add it later if your project really requires it.
Have you tried Django with Inertia.js?
https://inertiajs.com/
Django + AlpineJS + HTMX is pretty nice.
Especially with template partials now in the core of Django 6.
What is the Java equivalent of Django?
I really love django and everything around it, but I would also like to write a webapp in Java.
Getting django + rest_framework up and running and actually be productive takes me max 10 minutes, trying to do the same with spring boot I am a week in and I had to open the jakarta specs to understand the magic.
How about this? https://github.com/dropwizard/dropwizard
One thing Django has going for it is that the "batteries included" nature of it is perfect for AI code generation.
You can get a working site with the usual featuers (admin panel, logins, forgot reset/password flow, etc) with minimal code thanks to the richness of the ecosystem, and because of the minimal code it's relatively easy for the AI to keep iterating on it since it's small enough to be understandable in context.
why would you need batteries included? the ai can code most integrations (from scratch, if you want, so if you need something slightly off the beaten path it's easy
I think the logic can be applied to humans as well as AI:
Sure, the AI _can_ code integrations, but it now has to maintain them, and might be tempted to modify them when it doesn't need to (leaky abstractions), adding cognitive load (in LLM parlance: "context pollution") and leading to worse results.
Batteries-included = AI and humans write less code, get more "headspace"/"free context" to focus on what "really matters".
As a very very heavy LLM user, I also notice that projects tend to be much easier for LLMs (and humans alike) to work on when they use opinionated well-established frameworks.
Nonetheless, I'm positive in a couple of years we'll have found a way for LLMs to be equally good, if not better, with other frameworks. I think we'll find mechanisms to have LLMs learn libraries and projects on the fly much better. I can imagine crazy scenarios where LLMs train smaller LLMs on project parts or libraries so they don't get context pollution but also don't need a full-retraining (or incredibly pricey inference). I can also think of a system in line with Anthropic's view of skills, where LLMs very intelligently switch their knowledge on or off. The technology isn't there yet, but we're moving FAST!
Love this era!!
Whenever I use Django, I enjoy it. Simple as.
Do you guys find Django includes enough batteries? Why or why not?
I find myself using Cookiecutter Django [^1] more often than not, better auth, a bunch of boilerplate configs, S3 and email setups if you want, and other stuff rather than have to jiggle with "Django infra" myself
[^1]: https://github.com/cookiecutter/cookiecutter-django
Can someone remind me how we ended up in the SPA era and why exactly? Was it about not seeing the loading spinner? Or there were more reasons to it?
Because the web was made to render documents, but users want apps. CSS in part is so confusing because its original incarnations pulled heavily from traditional print media layout terms.
Everything since then was an attempt to leverage JS to turn documents into applications. Why? Ask any user.
I'm not in web anymore but, to me, it seemed easier to visualize richly linked data in Angular than having a Django template render it. Once you have the mindset of making your website into an app, you are tempted to move navigation to the app too. That way your app can keep delivering its core user function without the interruption of a page load.
In retrospect it was slightly hubristic, as in reality you sometimes have to force reload SPA's, and if you're integrating on top of legacy systems that you just link to, you're not really avoiding the bad UX of a jarring page load. But I do find it elegant to separate presentation from data.
Because JS is bad, and JS have a MASSIVE user base, so whatever they do is the web.
And because JS is on the frontend, solutions are front end, even the ones that eventually run on the (js) back-end.
Is like how people use a RDBMS but never do foreign keys, views, etc and re-invent all, poorly.
Aside from the usual separation of tech stacks for different teams, the big thing for me is lack of any sort of type hinting or safety in templates at least in the big frameworks such as Django, Rails etc. I would much rather work with a separate build process that utilizes typescript than deal with the errors that come out of incorrectly reading formless data and making typos within templates.
- Strict team separation (frontend versus backend)
- Moving all state-managament out of the backend and onto the frontend, in a supposedly easier to manage system
- Page refreshes are indeed jarring to users and more prone to leading to sudden context losses
- Desktop applications did not behave like web apps: they are "SPA"s in their own sense, without jarring refreshes or code that gets "yanked" out of execution. Since the OS has been increasingly abstracted under the browser, and the average computer user has moved more and more towards web apps[1], it stands to reason that the behavior of web apps should become more like that of desktop apps (i.e. "SPA"s)[2]
(Not saying I agree with these, merely pointing them out)
[1] These things are not entirely independent. It can be argued that the same powers that be (big corps) that pushed SPAs onto users are also pushing the "browser as OS" concept.
[2] I know you can get desktop-like behavior from non-SPAs, but it is definitely not as easy to do it or at least to _learn it_ now.
My actual opinion: I think it's a little bit of everything, with a big part of it coming from the fact that the web was the easiest way to build something that you could share with people effortlessly. Sharing desktop apps wasn't particularly easy (different targets, java was never truly run everywhere, etc.), but to share a webapp app you just put it online very quickly and have someone else point their browser to a URL -- often all they'll do is click a link! And in general it is definitely easier to build an SPA (from the frontender's perspective) than something else.
This creates a chain:
If I can create and share easily
-> I am motivated to do things easily
-> I learn the specific technology that is easiest
-> the market is flooded with people who know this technology better than everything else
-> the market must now hire from this pool to get the cheapest workers (or those who cost less to acquire due to quicker hiring processes)
-> new devs know that they need to learn this technology to get hired
-> the cycle continues
So, TL;DR: Much lower barrier to entry + quick feedback loops
P.S (and on topic): I am an extremely satisfied django developer, and very very very rarely touch frontend. Django is A-M-A-Z-I-N-G.
Thanks to Django. I got into the webdev world so easily.
Curious, how come Django started to make major versions instead of 1.*?
Can be the decreasing in popularity the reason to make Something to change it?
It didn't - https://www.djangoproject.com/download/#supported-versions
Oh, looks more transparent.
Blog post yesterday: https://www.djangoproject.com/weblog/2025/dec/03/django-60-r... (https://news.ycombinator.com/item?id=46136516)
Show of hands for backend web services development -
Who uses Django, Rails, or similar full-featured frameworks?
Who uses micro-frameworks like Flask?
Who uses enterprise Java, Jetty, Dot Net, etc.?
Who uses an entirely Javascript stack?
Who uses a non-traditional language that has become more web-servicey, like Go, Rust, or Swift?
Who uses something so wildly untraditional that it's barely mentioned? OkCupid using C++, etc.?
Who uses an entirely custom framework (in any language)?
Would really love to see a break down of who is using what, how people feel about their tech stack, etc.?
This would make an interesting poll. I think that's possible here? Maybe with some karma threshold, I don't seem to be able to make one.
We use flask and go at work. I've been micro-framework or roll-my-own-framework most of my career. Go is new for me though, and it's grown on me enough that it's what I prefer for new web-facing projects even for little personal things.
What should the options be? Were the ones I suggested coarse grained enough to capture everyone, or should I/we re-group or add more?
One proxy might be to look at the upvote counts for each of their respective latest release HN posts.
Eg, this post has ~50 (though only posted an hour ago)
Rails 8 had ~550
https://news.ycombinator.com/item?id=41766515
Rails might not get a lot of new articles about it, and the chatter might have died down, but I think a lot of people still use it.
I"m almost entirely dotnet these days, with a smattering of Go here and there.
I work in ops though, so I'm not building consumer-facing products but mostly IT glue code and internal tooling (mostly Go), dashboards, business report generators, gluing SaaS together, etc. (mostly dotnet/C#).
In what sense is Go not a traditional language for web services? They're almost the only thing it's good at, and it's been doing them for 13 years.
I agree that Go is a good choice for web services. I disagree that it's the only thing Go is good at. DevOps tooling and CLI tools immediately spring to mind.
I started using Django before the official 1.0 release and used it almost exclusively for years on web projects.
Lately I prefer to mix my own tooling and a couple major packages in for backends (FastAPI, SQLAchemy) that are still heavily inspired by patterns I picked up while using Django. I end up with a little more boilerplate, but I also end up with a little more stylistic flexibility.
> I started using Django before the official 1.0 release
Indeed. I'm still using the 0.97beta. It's perfectly good for production use!
</obscure joke>
I still have some very old Django projects that I'm maintaining for > 15 years. It's an absolute delight.
Yes. I'm still maintaining a Django site that I helped get live in 2007. I started learning Django in 2006.
At work, it is mainly Kotlin and Go webservices with some Rust for very specific use cases
- Have written Rails and Django both
- Have written SPAs (React/Svelte)
- Have written Go based services
Each has their on pros and cons.
Perl, CGI.
Love it!
Which version of Perl are you using, and what type of service(s) are you maintaining?
Is this older software, or do you use it for new projects too?
Have you rolled any sort of framework yourself?
What are your thoughts on Raku?
I target 5.10.1 mostly. This is for a project I started in the late 90's. It uses CGI::Application, which is less a framework and more a method lookup table converter of queries (although I built a path info convertor on top of that). It's still maintained, although before Covid, it was my livelihood.
About a quarter of a million lines of code, excluding the libraries I pull in. I'm mostly self-taught, they wouldn't even let me get a minor in Comp Sci, since I didn't have the math background (Needed Calculus, I completeled Algebra 2 in hs). Boneheaded Uni.
Raku: Second-system effect poster boy. Sensationally dysfunctional community. I think Pugs is what was actually really incredible and Audrey is probably one of the most intelligent people in... the World? Up for contention, but top 10.
Fable (just for the fun of it) and the new one dot net one file web services that resemble flask
Duh-jango