Django 6

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.

Django has been one of the biggest reasons why web development has been so enjoyable to me. Whenever I switched to something else, I just felt too spoiled by everything that Django gives you. So I always ended up back with Django, and have no regrets at all specializing deep down that path.

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.

That's just for the HTML content though. What if you want to add some non-trivial Javascript or generated CSS? Or maybe you want to integrate a frontend tool like Storybook[0] even if your HTML is rendered server-side? Maybe add some tests for your frontend code? There is much more between raw hand-rolled HTML/CSS/JS and a full-blown SPA.

At my day job we use Django with HTMX and Alpine, but we also generate the custom CSS from Pico[1] and use JinjaX[2] to define server-side components which we then render in Storybook. We use Vue as our bundler to compile the JS and CSS as well as to run Storybook. The project has to live in both the Python ecosystem and the Node.js ecosystem.

Even with just HTMX and Alpine you might want to compile a custom version of those with certain plugins, or you might want to load them as libraries in your own scripts.

[0] https://storybook.js.org/ [1] https://picocss.com/ [2] https://jinjax.scaletti.dev/

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