5 ms·

I've been using Django for over a decade. I don't think most of these are a big deal and outright disagree with others. Happy to offer my own criticisms of djan

by madrox 5y ago

I've been using Django for over a decade. I don't think most of these are a big deal and outright disagree with others. Happy to offer my own criticisms of django to add value to this comment thread. My real criticism of Django is that, at long last, I think it's starting to look dated. Templating hasn't been the preferred way of making web app UIs for some time. Modern web apps are maintaining models in the client and staying current though a combination of ajax queries and websockets. Setting up a project to do this is cumbersome. While there are third party solves, Django's greatness comes in part from how opinionated it is. I understand DSF may see adding more javascript as out of scope, but in keeping with the "batteries included" philosophy I hope they one day embrace something in contrib.

Nextgrid 5y ago
I wish Django had an equivalent to Rails' "unobtrusive Javascript": https://guides.rubyonrails.org/working_with_javascript_in_rails.html https://guides.rubyonrails.org/working_with_javascript_in_ra...
cessor 5y ago
I'd love to hear your criticism of django, issues you encountered and problems you have solved :) > My real criticism of Django is that, at long last, I think it's starting to look dated. Actually, that is something I found really great about django. I found that django is reliable over a long period of time. The js/node/react/express/angular apps I had developed in the past (~2012+) can't be built these days without redoing major components. I never had these problems with django. As for the responsiveness of the results, I found that a good understanding of django's performance helps. Using a good caching strategy (on models, views + nginx) yields results have almost instant reactions, even though there is the whole HTTP to HTML roundtrip. While they do have the noticable page-reload semantics, I found that these are way easier to build and sometimes yield very enjoyable experiences for my users. After all, I'm not building a YouTube so PictureInPicture and SPA-semantics aren't that important to my users. > Modern web apps are maintaining models in the client and staying current though a combination of ajax queries and websockets. Julia Elman explains how to do this with Django + DRF and Backbone.js in the book "Lightweight Django" (O'Reilly). Is this a viable compromise?
- jmconfuzeus 5y ago
  If you want to build highly interactive apps with React then you should consider django-graphene instead of DRF. REST wasn't designed for JSON apis.
  - Nextgrid 5y ago
    One advantage of REST is that it's easier to use from a programmatic client perspective; this might become useful if you want to offer an API to third-parties.
- madrox 5y ago
  I've implemented Django+DRF+React in several projects. The thrust of my arguement is that, were Django started today and not 17 years ago, it would account for these concepts more than templates do. Django contrib exists to be a home for first party solutions to specific problems [1]. It need not be an entire frontend framework that follows trends like react, but something to make syncing state easier sits squarely in that namespace. 1 https://docs.djangoproject.com/en/4.0/ref/contrib/ https://docs.djangoproject.com/en/4.0/ref/contrib/
danjac 5y ago
Not adding JS (other than what's needed for the admin) is in retrospect a good move - when you see the pain Rails developers went through in multiple iterations of RJS, rails-ujs, Turbolinks, CoffeeScript and now Hotwire/Stimulus depending on DHH's vision of what was hot in frontend. Django's JS agnoticism has made it easier to use different frontends without having to tear stuff out, whether you want a full Vue/React SPA or something more minimal like htmx or Alpine (or even plain old server-side templates + jQuery).

by madrox 5y ago

Nextgrid 5y ago

I wish Django had an equivalent to Rails' "unobtrusive Javascript": https://guides.rubyonrails.org/working_with_javascript_in_rails.html https://guides.rubyonrails.org/working_with_javascript_in_ra...

cessor 5y ago

I'd love to hear your criticism of django, issues you encountered and problems you have solved :) > My real criticism of Django is that, at long last, I think it's starting to look dated. Actually, that is something I found really great about django. I found that django is reliable over a long period of time. The js/node/react/express/angular apps I had developed in the past (~2012+) can't be built these days without redoing major components. I never had these problems with django. As for the responsiveness of the results, I found that a good understanding of django's performance helps. Using a good caching strategy (on models, views + nginx) yields results have almost instant reactions, even though there is the whole HTTP to HTML roundtrip. While they do have the noticable page-reload semantics, I found that these are way easier to build and sometimes yield very enjoyable experiences for my users. After all, I'm not building a YouTube so PictureInPicture and SPA-semantics aren't that important to my users. > Modern web apps are maintaining models in the client and staying current though a combination of ajax queries and websockets. Julia Elman explains how to do this with Django + DRF and Backbone.js in the book "Lightweight Django" (O'Reilly). Is this a viable compromise?

jmconfuzeus 5y ago
If you want to build highly interactive apps with React then you should consider django-graphene instead of DRF. REST wasn't designed for JSON apis.
- Nextgrid 5y ago
  One advantage of REST is that it's easier to use from a programmatic client perspective; this might become useful if you want to offer an API to third-parties.
madrox 5y ago
I've implemented Django+DRF+React in several projects. The thrust of my arguement is that, were Django started today and not 17 years ago, it would account for these concepts more than templates do. Django contrib exists to be a home for first party solutions to specific problems [1]. It need not be an entire frontend framework that follows trends like react, but something to make syncing state easier sits squarely in that namespace. 1 https://docs.djangoproject.com/en/4.0/ref/contrib/ https://docs.djangoproject.com/en/4.0/ref/contrib/

danjac 5y ago

Not adding JS (other than what's needed for the admin) is in retrospect a good move - when you see the pain Rails developers went through in multiple iterations of RJS, rails-ujs, Turbolinks, CoffeeScript and now Hotwire/Stimulus depending on DHH's vision of what was hot in frontend. Django's JS agnoticism has made it easier to use different frontends without having to tear stuff out, whether you want a full Vue/React SPA or something more minimal like htmx or Alpine (or even plain old server-side templates + jQuery).