Thanks. Just went to bookmark it, but pinboard says I already did so in December of 2023.

All of Nick's repos are top notch and I high recommend them and reference them from my materials as well.

Nick, thank you for sharing so much in the open.

Hah, I used this a few years back on a project. Great work!

Very cool and can tell you keep up with it just with your addition of uv!

Do a guerilla port of it to modern Django.

Why would they retire it? If it ain't broke...

On top of this, it's understandable to humans when reviewing generated code. There's no 2000-line FooBarAdmin component where bugs could be located. And if you're having it generate HTML templates, you can see exactly what backend model property/method was used without needing to follow the indirection through backends and prop drilling.

And when you do create backends and React components, you can have a known-good ground truth in your Django admin that's independent from that frontend. This is incredibly useful in practice - if a certain e.g. malformed input triggers a catastrophic frontend crash, you have an entirely separate admin system you can use to play with the data, without needing to trace to find the exact cause of the frontend crash, or dropping into direct database access.

(My one gripe with Django, which is more with the broader Python ecosystem, is that if the community had leaned into the gevent programming model (no explicit async, all socket calls are monkey-patched to yield, you just write sync code), there would be no need for async versions/ports of every Django library function, no confusion in the library ecosystem, and instant upgrades of every Django library in existence to an async world. gevent is a thing of beauty and that's a hill I'll die on.)

Now I've been dabbling outside of Django, I realised some of those things come from bits people don't think about much:

INSTALLED_APPS and other bits in the settings provide a central registration point, from there the system where a project is made up of apps is enabled.

Each app, has it's own migrations, models, templates and static files.

This enables the whole ecosystem of parts that's easy to add, and makes it easy to toggle things (e.g. enabling the django-debug-toolbar only on your dev and local instance).

In the outside world of Flask, Fast API etc - things hang together much more loosely and it means the integration just isn't as complete.

This manifests itself in 1,000 little papercuts that make things take longer.

I have tried both Django and Rails for this, and honestly, very surprisingly, Rails did much better, at least with Claude Code. This is for a rewrite of an old .net application. Claude nailed it almost perfectly with Rails, but struggled with Django. YMMV.

And because Django is so popular in open source projects and it has been around for such a long time, there's tons of code out there for AI to train on.

Ruby and Rails are even better candidates. CSP, Background workers, and many other features that Django still lacks have been standard offerings for sometimes 10+ years!

Claude is insanely good with Django and React. I think the best thing that happened to Python was type hints because it lets LLMs reason Python code easier.

This is generally true of all of these frameworks: Django, Laravel, rails, phoenix

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

Have you tried Ruby on Rails. That's my experience with Rails. Everytime I've tried something else (for web dev), I just felt too spoiled with Ruby & Rails and went back. This includes Django and Phoenix (Elixir).

Edit: The only thing that Rails lacks is a decent Admin UI included as part of Rails. I know that there are some external gems that can be used, yet that's something that should be part of the framework in my opinion.

That’s true as long as you are only talking about the backend.

Frontend wise, Django is in the Stone Age.

Look at Laravel or rails if you want a really complete full stack solution.

Never understood the appeal. I started with the web before there were any frameworks, in PHP, and Django was always very meh.

Are they planning to include this? It seems like the kind of demarcation point the framework would avoid crossing into.

Perfect should not be the enemy of good, after all Django is the framework for perfectionists with deadlines ;)

No one has mentioned it: mobile! Mobile apps became a thing, and there was a strong argument to have one common backend for your web app and your iOS app and your Android app. Plus the mobile UX (especially with iOS apps at the time) was such a gamechanger that there was a natural shift to replicate it in the browser.

That said, even though I still build SPAs at work, but I can't wait for the day that I get to build something big with Django & htmx.

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

>Or there were more reasons to it?

Internet was slower in both latency and throughput is one reason. The other is general tendency to separate things into smaller pieces. Faster feedback to user is the third.

Consider a typical form with 10 fields in django. You define the schema on a backend, some validation here and there, a db lookup and form-level rules (if this field is entered, make the other field optional).

This works very welly in django, but you only get the result once you fill all the fields and press enter, at which point the whole thing gets sent through model-tempalte-controller thing and the resulting page is returned over a faulty slow connection. It also hits the database which is not great because SSD is not invented yet and you can't keep the whole thing in RAM or overprovision everything 100x. Containers, docker and devops are not invented yet as well.

So you try to add some javascript into the template and now you have two sets of validators written in two different languages (transpilers are not invented yet) and the frontend part is the ugly one because declarative frameworks like react dont exist, so you add ad-hoc stuff into the template. Eventually everyone gets annoyed by this and invents nice things, so you move the part that was template rendering+form completely to the FE and let two different teams maintain it and communicate through the corporate bureaucracy that tracks the source of truth for validation rules outside of the code.

At some point you notice that people name fields in the json schema in a way that is not consistent and forget the names, so you put even bigger boundary between them with a formal API contract and independent party to approve it (I kid you not, there are places where the API between FE and BE teams is reviewed by a fancy titled person that doesn't deal with either team outside of this occasion).

Eventually you figure out that running the frontend logic on the backend is easier (it's doing the same model-view-whatever patter anyway) than other way around and remove the fence making all the bureaucratic overhead disappear in one clap.

Then somebody finds an RCE in server components.

You are here.

Add: if you want to feel the WEB before SPA, here is a nice example: https://formulieren.amsterdam.nl/TriplEforms/DirectRegelen/f... (bonus points for opening two different forms from site:formulieren.amsterdam.nl in different tabs and clicking through them in parallel)

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.

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.

In my experience it's boiled down to the type of data you're working with. Building nested, tree-like structures and then submitting that structure to the back-end as one request is more easily done via the front-end than a bunch of back-and-forth requests followed up by a "commit" request.

edit: I suppose this is different concern than a true SPA, but as another sibling comment points out, its just a matter of time before routing makes its way into the front-end as well.

For me, yes, it is. I make an app for myself, and I thought about making it a server-rendered app like you suggested. But it's just so much better in my opinion to do everything on the client side because it means that every interaction has zero latency, regardless of the quality of my internet (which is often bad).

I’d say that we are slaves to Conway’s Law.

Adding people to dev teams looks like an obvious way to scale productivity.

Then of course you need to organise them as the numbers grow and the frontend/backend split is the first, naive, place to start.

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

I sometimes think that the direction web development took is like some kind of bad dream that we will wake up from. It's unbelievable to me. The problems we faced before SPAs were things like "great we've got two forms on the same page and this widget on the top right needs to update when a message comes in from the back end… How will we ever solve this", and before anybody could come up with any good patterns google came on the scene with Angular, and ruined the entire direction of the Internet, forever.

TBH I also think that Alpine and HTMX are just as dastardly and disgusting, maybe even worse. I don't know why nobody can figure out a good way to just put in reactive components where you need them. All of the frameworks support that, Svelte seems to be the one that is the least against that, but I still don't see anybody using it that way. Front end developers, which tend to have the least business logic experience, somehow captured the entire SDLC. This is why literally all software is just completely riddled with insufferable bugs, beyond anything anyone in the 90s could have imagined.

Google Maps. Gmail. OWA. There were suddenly pages that let you do things without a white flash between clicks.

It's ALL about the refreshes. Everything else came after.

I agree, type annotations need work. I just use stubs and then I have some rules to set some of the more common ones to be warnings instead of errors, and then I just deal with the fact that there's gonna be some yellow squiggles.

Django is a modern web framework. It simply doesn't follow the hype around JS SPAs. However, if you really want to, you can of course still render static content + serve a JS framework like Vue to the client, and then have dynamic widgets rendered on the client side.

If you want to build an SPA anyway, then Django is not the right framework to start with though.

Have you tried Django with Inertia.js?

https://inertiajs.com/

Django + AlpineJS + HTMX is pretty nice.

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.

Java honestly just does not have this. By the time java collectively decided that being able to spend your time writing your actual product instead of fucking with config shit forever, the age of the monolithic SSR templated backend app were gone. So now most modern things like helidon focus on being microservicey like go, or they have very soft template rendering offerings and don't really do batteries included.

I feel your pain, I myself am working on a react frontend + spring boot backend and fiddling with it to integrate with spring session, security, etc properly was a HUGE pain because neither world knows anything at all about each other. If I did it from scratch I'd just "rails new myapp" and be done already.

How about this? https://github.com/dropwizard/dropwizard

There used to be JHipster, not sure if still around

I'm not sure why people aren't saying Spring Boot, but Spring Boot. Yeah it has heaps of other batteries included, and it doesn't have a built-in admin, but it gives you pretty decent stuff out of the box

You will have to keep Celery for the foreseeable future. The current implementation is just a stub which provides a unified interface for some future backends.

Background tasks production backend is unfortunately the battery that is not included.

Meanwhile, Huey works just fine: https://huey.readthedocs.io/en/latest/django.html

Try RQ.

Ruby is a far better language from a design standpoint and Rails is a better framework in both design and maturity. Sadly, Ruby is a domain-specific language for web backends these days. Most new startups pick Python and TS for their versatility.

This x1000.

I’ve tried every orm in node and nothing compares to Django orm. The way you can scaffold an apps data models is amazing.

Glad to see someone on HN mentioning Strawberry! Hope you're enjoying it!

It didn't - https://www.djangoproject.com/download/#supported-versions

I used Django for a project a couple of years ago. Of course, there's a lot to learn. But generally I found that everything makes sense and I was able to build a moderately complex site with user accounts within a reasonable time. Work took me in different directions, but if a project came up I'd use it again, no problem.

Last year I taught myself Next.js for a project. Everyone would say that's a modern framework, with a modern website. I already know React, I'm quite familiar with prisma.js. Learning and using it was (and is, because now I have to maintain the project) painful, confusing, and full of footguns. I wanted to host on Cloudflare but half the stuff doesn't work so I'm forced into Vercel. Takes ages to understand how images work, how server side works, and so on, and those things are still confusing to me. Constantly I ran into tricky problem about getting data to a client side component, or server side, because some UI library wasn't server side or something like that. Even getting the two fonts I'd chosen into a client side component took me several hours! And I still felt like the solution I came up with was hacky and fighting against the framework.

I regret learning the "modern" framework. I don't regret learning Django. Don't let fancy marketing fool you into using a bad tool, or drive you away from a good one.

Don't judge a web framework by it's website.

I trust them more precisely because they are not wasting resources making slick start-upy marketing fluff that make it difficult to find the actual information I am looking for.

Flask is my go-to, but I've had great fun with Rust recently.

Django is the best thing in the world for writing Django apps. (No, I'm not trying to be funny there. If what you're doing looks like something Django would solve, it's fantastic.) But most of the things I do aren't Django apps, and ones you get off its happy path, you can be in for a world of hurt. Oh, you use SQLAlchemy everywhere else, and you'd like to use it in your Django app so that you can have one set of models and re-use the service logic you've built? Hah, too bad! Or you need your REST API output to look a very specific way? Have fun with that! Your auth model doesn't look just like Django's? Hope your LLM is good at smoothing that over!

The good side is that it's an opinionated framework that does a lot of research on your behalf and makes some great choices. The bad side is that you better agree with its opinions or you're in for a bad time.

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.

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

I still have some very old Django projects that I'm maintaining for > 15 years. It's an absolute delight.

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 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've done several custom frameworks for solo projects in Java & Go, all based on server generated content, inspired by Seaside but more RESTy.

Also used Flask and similar libraries for back ends.

Did one project in Rails, which was a pretty bad experience in comparison, and killed any motivation to look into Django.

Also did plenty of Spring in Java professionally, unfortunately.

Would love to see this.

Django just makes life 1000x easier. Can architect an app with data models, api, openapi, etc. within an hour.

As fully-featured as possible, because as much as I like building stuff, I don’t give a shit about coding stuff that has been figured out since the 90’s. Another question is whether semantics and operations get bloated or affect development speed in a framework but I don’t think it’s the case with the Django.

In a company that uses a traditional web framework like Django to actually build the frontend and backend, not just as only for implementing the APIs, I would even consider doing parts of frontend work again, making everything responsive and so on. That's what I do for a not-yet-startup project.

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.

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.

Fable (just for the fun of it) and the new one dot net one file web services that resemble flask