4 ms·

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 fr

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.

__pache__ 3y ago
...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..
wiseowise 3y ago
> Time has passed, and javascript is now part of every single website or app we build That’s the problem - it shouldn’t be.
siquick 3y ago
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.
sjamaan 3y ago
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.
- pjerem 3y ago
  > Angular A LOT of companies ?
  - mst 3y ago
    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.
  - jeremycarter 3y ago
    Oh. I don't know. Just half of the biggest sites in the world from Google...
    - manojlds 3y ago
      Tell me you know nothing about OG Angular without telling me.
      - deleted 3y ago
        [deleted]
      - replygirl 3y ago
        It was called AngularJS--when someone says "Angular" most people will think of the framework called Angular
- whstl 3y ago
  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.
- EmilStenstrom 3y ago
  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.
sgt 3y ago
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.
melx 3y ago
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.
ochoseis 3y ago
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.
patrakov 3y ago
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".

__pache__ 3y ago

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

wiseowise 3y ago

> Time has passed, and javascript is now part of every single website or app we build That’s the problem - it shouldn’t be.

siquick 3y ago

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.

sjamaan 3y ago

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.

pjerem 3y ago
> Angular A LOT of companies ?
- mst 3y ago
  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.
- jeremycarter 3y ago
  Oh. I don't know. Just half of the biggest sites in the world from Google...
  - manojlds 3y ago
    Tell me you know nothing about OG Angular without telling me.
    - deleted 3y ago
      [deleted]
    - replygirl 3y ago
      It was called AngularJS--when someone says "Angular" most people will think of the framework called Angular
whstl 3y ago
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.
EmilStenstrom 3y ago
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.

sgt 3y ago

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.

melx 3y ago

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.

ochoseis 3y ago

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.

patrakov 3y ago

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