6 ms·

Django Community Survey

170 points by jsmeaton 11y ago

anhtran 11y ago
In the first look at the frameworks between Rails and Django in 2008, I chose Django because it has a green logo.
- jeffasinger 11y ago
  Around the same time, I chose Django because it felt less magical than rails.
  - andybak 11y ago
    and I chose Django because it was Python
  - viiralvx 11y ago
    I wanted to learn a full-stack MVC framework but when I was learning Django, it didn't seem to make as much sense to me. After doing Hartl's Rails tutorial, I started building a Rails app of my own and after awhile the Rails concepts just clicked in my head and I started getting really productive with Ruby on Rails. After building a Rails app, I was able to go back to Django and better understand its MTV paradigm, something I wasn't able to quite do when I first started learning. Nowadays I can build a web app using EmberJS and Rails or Django in the back-end, all depends on the scope of the project, but both are great, mature frameworks.
santiagobasulto 11y ago
IMHO Django is one of the best open source projects in terms of "politics". I really like how the guys handle the process of working with a framework that has such an impact in so many people (and pockets).
niix 11y ago
I have love for Django, it helped me learn how to build a web server and understand database schemas early on.
simonpantzare 11y ago
As a long time Django user (first project on 1.1) I want to thank for a great framework and your wonderful release approach! I often try out new new web dev platforms and frameworks but tend to rewrite projects that get too serious or large in Django, or when I'm starting to miss too many features. If I know that I am building something that others are going to work on, or if I know that the project will need to be maintained for a considerable amount of time, I tend to go with Django and a few familiar libraries (Celery, Django REST framework, django-extensions) right off the bat, as I feel comfortable that we won't run into issues where some important dependency becomes unmaintained or introduces backwards-incompatible changes. Much thanks to Django's predictable and well thought out releases. Further, when I pick Django, I know that there is good support in monitoring and crash report systems such as Sentry, New Relic, and others. So that's one less thing to worry about. The only area where I have started to use other solutions is frontend dev, as I find that the momentum in the Node community is so much higher in this area. I only wish that the Node community wasn't as fragmented and had a more long-term view on releases.
- iyn 11y ago
  Can you elaborate on the solutions in frontend? Currently I'm working on a project and I want to use React "the right way". While it's not so hard to just integrate React into Django project, it's not so easy to manage the chaos when things start to grow. At the moment I'm trying to integrate React, webpack, gulp and node (server side rendering for react) into Django workflow and make it work "natural", but right now it just feels hacky and not the way I want it to work. Would be great if you could share your workflows & ideas.
  - anewhnaccount 11y ago
    I've not done it myself (I've looked but it was a small project so I just ignored server side rendering and used django-compressor for convienience's sake) but you should definitely check https://github.com/markfinger/python-react https://github.com/markfinger/python-react if you haven't already
  - rattray 11y ago
mpdehaan2 11y ago
Django has been pretty fantastic about keeping code forward compatible and keeping things very stable and reliable -- I greatly appreciate all of this. Also a huge fan of Django REST framework for how well it does REST APIs, and in particular, the API browser: http://www.django-rest-framework.org/ http://www.django-rest-framework.org/
mrfusion 11y ago
Just finished! My main suggestions were to improve the admin interface, more speed and more polish. I use it for simple CRUD apps all the time. I also suggested that they improve the production deployment situation somehow. I spent two days the first time I deployed a Django app to production, between installing supervisor, gunicorn, nginx, mysql, etc and debugging all the issues. (Mostly getting paths right, and having the wrong .'s in imports.)
- anewhnaccount 11y ago
  Easiest way to improve the production deployment situation is to use a PaaS like Heroku. Something like Dokku may simplify things by having all the "wiring" done for you. YMMV. Thinking about it a bit more, there could be less directory settings in Django itself. Maybe there could be more "convention over configuration" outside Django too. I do remember it being a pain doing it first time since you don't know where all the log files are.
  - collyw 11y ago
    I disagree, I have had more hassle getting stuff to work on Heroku than from a bare VM. And debugging is far more hassle as well.
- rattray 11y ago
  Great idea on deployment, wish I had said the same. PaaS's are great but if there was officially supported boilerplate for supervisor/gunicorn/uwsgi/nginx/postgres, say, on Docker, that would make life terrific.
  - mrfusion 11y ago
    That's a great idea! An official docker (and/or AMI?) that has everything set up and optimized, and you just add your project to a specific directory! Django could release and update with every release.
    - jsmeaton 11y ago
jeffasinger 11y ago
My biggest issue with django right now is the speed of the migrations since 1.7. At work, we have a project with around 30 apps and 170 interrelated migrations. It takes 2-3 minutes to run all the migrations, which have to happen at the beginning of many runs of our test suite.
- brento 11y ago
  There are ways to "turn off" migrations [1] for testing. Also you can squash [2] your migrations which should help. [1] http://stackoverflow.com/a/28560805/176611 http://stackoverflow.com/a/28560805/176611 [2] https://docs.djangoproject.com/en/1.8/topics/migrations/#squashing-migrations https://docs.djangoproject.com/en/1.8/topics/migrations/#squ...
  - jeffasinger 11y ago
    Unfortunately squashing doesn't help as much as I'd hoped as the performance problem is in the loader (executing migrations is pretty quick). It can also get tricky with interdependencies between apps. Turning off migrations is great in the cases it works, but it doesn't provide an easy way to also run the few data migrations that some parts of our code rely on. Obviously we could probably fix this in some non-DRY way, but I'd rather not. The situation as is, is workable, but it would be way better to improve the performance of this a little (which I have a feeling is definitely possible). When I next get some time to work on this, I'll give it a crack.
    - jsmeaton 11y ago
      There have been lots of performance improvements added since migrations officially landed, but I'm still hearing it's a concern for bigger projects. More eyes will definitely help. For your testing, perhaps you might want to consider the `--keepdb` switch. Not very helpful when you're changing your models though.
- crdoconnor 11y ago
  Why not cache the database post migration?
unoti 11y ago
I love Django, and I love Python. But I wanted to share my least favorite thing about Django, the thing that will cause me to leave it after so many years: It's in Python. Lack of static compilation makes it difficult to detect certain kinds of basic issues until later. Implementing realtime features (websockets, async things) is a less natural fit in Python than other languages. Lack of good concurrency is a more serious issue for me these days as I do a lot of work with game backends. I realize I could use Iron Python or something to get around this, but that doesn't solve the other issues here. The amount of horsepower that I get per megabyte of RAM used in Python vs other languages is also pretty sad. Other compiled languages now are available that stand up to high concurrency loads better on the same hardware for the type of work I do. For years I've stuck with Django because the admin system and other features let me make fast progress with new projects quickly. I spent a good amount of time with Node and with Go, but lately I'm excited about Elixir and Phoenix, and it looks like that's going to be my go-to toolset for the next few years.
- dguaraglia 11y ago
  I feel your pain. I've recently been working on a Java codebase and as 'ugh' as that is, having some sort of type system that you can rely on at compile time helps a lot. Of course, there's the added boilerplate when writing tests that almost takes away from the gains... and the 5 minute time to bring up the server, but that's a completely different issue.
  - unoti 11y ago
    That is exactly what's so exciting about Elixir to me. It's homiconic, like LISP, so being able to execute code at compile time can have a game-changing impact on reducing boilerplate. And in addiction to that, it's functional, so I can get the awesome benefits of immutable programming, but without the dizzying complexity of, for example, Scala's type system. And it's based on the Erlang VM, so I get the benefits of battle-hardened concurrency and IO underpinnings. Previously I stayed away from things like Go and Node/Express, because I felt like it wasn't as easy for the type of work I do as Django, and was missing key things like the admin interface. But when I looked at what's in the Phoenix framework[1] and read the source, it started to feel like I'm witnessing the dawn of the next Ruby on Rails revolution. http://www.phoenixframework.org/ http://www.phoenixframework.org/
neokya 11y ago
Thanks to Django team for this. I hope my feedback helps to move it further.

170 points by jsmeaton 11y ago

anhtran 11y ago

In the first look at the frameworks between Rails and Django in 2008, I chose Django because it has a green logo.

jeffasinger 11y ago
Around the same time, I chose Django because it felt less magical than rails.
- andybak 11y ago
  and I chose Django because it was Python
- viiralvx 11y ago
  I wanted to learn a full-stack MVC framework but when I was learning Django, it didn't seem to make as much sense to me. After doing Hartl's Rails tutorial, I started building a Rails app of my own and after awhile the Rails concepts just clicked in my head and I started getting really productive with Ruby on Rails. After building a Rails app, I was able to go back to Django and better understand its MTV paradigm, something I wasn't able to quite do when I first started learning. Nowadays I can build a web app using EmberJS and Rails or Django in the back-end, all depends on the scope of the project, but both are great, mature frameworks.

santiagobasulto 11y ago

IMHO Django is one of the best open source projects in terms of "politics". I really like how the guys handle the process of working with a framework that has such an impact in so many people (and pockets).

niix 11y ago

I have love for Django, it helped me learn how to build a web server and understand database schemas early on.

simonpantzare 11y ago

As a long time Django user (first project on 1.1) I want to thank for a great framework and your wonderful release approach! I often try out new new web dev platforms and frameworks but tend to rewrite projects that get too serious or large in Django, or when I'm starting to miss too many features. If I know that I am building something that others are going to work on, or if I know that the project will need to be maintained for a considerable amount of time, I tend to go with Django and a few familiar libraries (Celery, Django REST framework, django-extensions) right off the bat, as I feel comfortable that we won't run into issues where some important dependency becomes unmaintained or introduces backwards-incompatible changes. Much thanks to Django's predictable and well thought out releases. Further, when I pick Django, I know that there is good support in monitoring and crash report systems such as Sentry, New Relic, and others. So that's one less thing to worry about. The only area where I have started to use other solutions is frontend dev, as I find that the momentum in the Node community is so much higher in this area. I only wish that the Node community wasn't as fragmented and had a more long-term view on releases.

iyn 11y ago
Can you elaborate on the solutions in frontend? Currently I'm working on a project and I want to use React "the right way". While it's not so hard to just integrate React into Django project, it's not so easy to manage the chaos when things start to grow. At the moment I'm trying to integrate React, webpack, gulp and node (server side rendering for react) into Django workflow and make it work "natural", but right now it just feels hacky and not the way I want it to work. Would be great if you could share your workflows & ideas.
- anewhnaccount 11y ago
  I've not done it myself (I've looked but it was a small project so I just ignored server side rendering and used django-compressor for convienience's sake) but you should definitely check https://github.com/markfinger/python-react https://github.com/markfinger/python-react if you haven't already
- rattray 11y ago

mpdehaan2 11y ago

Django has been pretty fantastic about keeping code forward compatible and keeping things very stable and reliable -- I greatly appreciate all of this. Also a huge fan of Django REST framework for how well it does REST APIs, and in particular, the API browser: http://www.django-rest-framework.org/ http://www.django-rest-framework.org/

mrfusion 11y ago

Just finished! My main suggestions were to improve the admin interface, more speed and more polish. I use it for simple CRUD apps all the time. I also suggested that they improve the production deployment situation somehow. I spent two days the first time I deployed a Django app to production, between installing supervisor, gunicorn, nginx, mysql, etc and debugging all the issues. (Mostly getting paths right, and having the wrong .'s in imports.)

anewhnaccount 11y ago
Easiest way to improve the production deployment situation is to use a PaaS like Heroku. Something like Dokku may simplify things by having all the "wiring" done for you. YMMV. Thinking about it a bit more, there could be less directory settings in Django itself. Maybe there could be more "convention over configuration" outside Django too. I do remember it being a pain doing it first time since you don't know where all the log files are.
- collyw 11y ago
  I disagree, I have had more hassle getting stuff to work on Heroku than from a bare VM. And debugging is far more hassle as well.
rattray 11y ago
Great idea on deployment, wish I had said the same. PaaS's are great but if there was officially supported boilerplate for supervisor/gunicorn/uwsgi/nginx/postgres, say, on Docker, that would make life terrific.
- mrfusion 11y ago
  That's a great idea! An official docker (and/or AMI?) that has everything set up and optimized, and you just add your project to a specific directory! Django could release and update with every release.
  - jsmeaton 11y ago

jeffasinger 11y ago

My biggest issue with django right now is the speed of the migrations since 1.7. At work, we have a project with around 30 apps and 170 interrelated migrations. It takes 2-3 minutes to run all the migrations, which have to happen at the beginning of many runs of our test suite.

brento 11y ago
There are ways to "turn off" migrations [1] for testing. Also you can squash [2] your migrations which should help. [1] http://stackoverflow.com/a/28560805/176611 http://stackoverflow.com/a/28560805/176611 [2] https://docs.djangoproject.com/en/1.8/topics/migrations/#squashing-migrations https://docs.djangoproject.com/en/1.8/topics/migrations/#squ...
- jeffasinger 11y ago
  Unfortunately squashing doesn't help as much as I'd hoped as the performance problem is in the loader (executing migrations is pretty quick). It can also get tricky with interdependencies between apps. Turning off migrations is great in the cases it works, but it doesn't provide an easy way to also run the few data migrations that some parts of our code rely on. Obviously we could probably fix this in some non-DRY way, but I'd rather not. The situation as is, is workable, but it would be way better to improve the performance of this a little (which I have a feeling is definitely possible). When I next get some time to work on this, I'll give it a crack.
  - jsmeaton 11y ago
    There have been lots of performance improvements added since migrations officially landed, but I'm still hearing it's a concern for bigger projects. More eyes will definitely help. For your testing, perhaps you might want to consider the `--keepdb` switch. Not very helpful when you're changing your models though.
crdoconnor 11y ago
Why not cache the database post migration?

unoti 11y ago

I love Django, and I love Python. But I wanted to share my least favorite thing about Django, the thing that will cause me to leave it after so many years: It's in Python. Lack of static compilation makes it difficult to detect certain kinds of basic issues until later. Implementing realtime features (websockets, async things) is a less natural fit in Python than other languages. Lack of good concurrency is a more serious issue for me these days as I do a lot of work with game backends. I realize I could use Iron Python or something to get around this, but that doesn't solve the other issues here. The amount of horsepower that I get per megabyte of RAM used in Python vs other languages is also pretty sad. Other compiled languages now are available that stand up to high concurrency loads better on the same hardware for the type of work I do. For years I've stuck with Django because the admin system and other features let me make fast progress with new projects quickly. I spent a good amount of time with Node and with Go, but lately I'm excited about Elixir and Phoenix, and it looks like that's going to be my go-to toolset for the next few years.

dguaraglia 11y ago
I feel your pain. I've recently been working on a Java codebase and as 'ugh' as that is, having some sort of type system that you can rely on at compile time helps a lot. Of course, there's the added boilerplate when writing tests that almost takes away from the gains... and the 5 minute time to bring up the server, but that's a completely different issue.
- unoti 11y ago
  That is exactly what's so exciting about Elixir to me. It's homiconic, like LISP, so being able to execute code at compile time can have a game-changing impact on reducing boilerplate. And in addiction to that, it's functional, so I can get the awesome benefits of immutable programming, but without the dizzying complexity of, for example, Scala's type system. And it's based on the Erlang VM, so I get the benefits of battle-hardened concurrency and IO underpinnings. Previously I stayed away from things like Go and Node/Express, because I felt like it wasn't as easy for the type of work I do as Django, and was missing key things like the admin interface. But when I looked at what's in the Phoenix framework[1] and read the source, it started to feel like I'm witnessing the dawn of the next Ruby on Rails revolution. http://www.phoenixframework.org/ http://www.phoenixframework.org/

neokya 11y ago

Thanks to Django team for this. I hope my feedback helps to move it further.