Hacker News Reader

Comment by EmilStenstrom | Hacker News Reader

Django was a "batteries included" framework about 10 years ago. But the core team had very strong opinions about javascript, saying that picking a javascript framework should NOT be part of those batteries. Time has passed, and javascript is now part of every single website or app we build. Django still doesn't give any help to developers that wants to build a modern site.

My opinion: They should go the Phoenix Live View-route: adding a small websocket js layer, that permits reactivity while deferring as much logic to the backend as possible.

View on HN

If they had chosen a JS framework as part of the batteries, that framework probably would've been deprecated by now. For instance, who still builds websites with Angular or Backbone/Marionette anymore?

See also Rails, which did choose a battery quite early on: prototype.js. Well, that was a wrong decision, so they changed it to jQuery (which is now also deprecated; no idea what it supports nowadays) and also dropped their RJS templating language. Lots of breakage and churn on every major release for us poor sods who made use of such features.

> Angular

A LOT of companies ?

I suspect they mean original Angular (i.e. AngularJS) rather than the reboot just called Angular.

Certainly AngularJS was more contemporary with Backbone and was actually both relatively pleasant to use in its era and long outpaced now.

Oh. I don't know. Just half of the biggest sites in the world from Google...

Tell me you know nothing about OG Angular without telling me.

It was called AngularJS--when someone says "Angular" most people will think of the framework called Angular

More recently in Rails: Sprockets, then Webpack, then Vite.

Migrating a small website from one to the other is trivial.

Migrating a large enough website was for my team a multi-month affair involving hours-long debugging sessions, opening tickets in multiple Github projects and contributing to the projects.

Decoupling different software components is a good thing.

That's why I suggested following the Phoenix LiveView route. It's a very thin and fast JS-layer that defers processing to the backend. Avoids framework churn.

The status quo for a Django site right now is that everyone that uses it needs to pick a framework themselves. That includes evaluating the "state of js frameworks" and knowing about all the tradeoffs. That's a lot of mental load for a web framework that claims "batteries included".

As someone who builds Django sites, I know very well that at some point you end up using JavaScript in some fashion. However, to start off with a typical Django project you will be perfectly fine with normal forms. From that point on your can adopt Unicorn, htmx, or even VueJS apps using your API.

It's important to note that most users do not care whether a page refreshes or not. That's mostly the developers - being used to SPA's and frameworks. You can build basic requirements very rapidly with Django as-is.

I have done a lot of Django in my time but it feels like it has stood still for the last 8 years. Barely anything has changed in that time - the fact that you have to use a third party library to get a decent REST API is such an odd standpoint. And the laborious configuration routine that’s still required when you start each project should be a solved problem by now.

> Time has passed, and javascript is now part of every single website or app we build

That’s the problem - it shouldn’t be.

...you can just _do_ that? Channels, model save fires realtime frontend update, frontend handles that update.

Would be an awesome pattern to demonstrate, but doesn't have to be built in..

That's the exact reason I mostly stopped developing using Django and decided to learn Elixir. I hate JS and try to use as little as possible on my projects, and LiveView is a god send. Also, the neat integration with Tailwind CSS is out of the box in Phoenix.

Re "batteries included" -- Often when you know what you want to accomplish, then 80% of the time there's an obvious straightforward way to get it done in the framework. The thing that gives me some anxiety about Django (and any other opinionated framework, I suppose), is that the other 20% of the time you're not sure whether there's an esoteric but idiomatic way to do it, or you really need to implement something custom yourself.

Websockets still don't work in a corporate setting where everything is being filtered through an HTTPS-breaking proxy that tries to detect malware and whose authors believe that, because they can't reliably detect malware in websockets, they would rather just block them all in the name of "security".

Reply on news.ycombinator.com