7 ms·

Django Developers Survery Results

113 points by neokya 11y ago

jtchang 11y ago
This is an awesome survey. I am a avid fan of Django and have been using it for over 4 years. I found it amusing people are split between 6 and 12 month for release cycles.
- neokya 11y ago
  Thus new release cycle will be 8 months, middle ground. There are few other changes for release, notably SemVer adoption. For detailed Roadmap, see https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ https://www.djangoproject.com/weblog/2015/jun/25/roadmap/
  - shabda 11y ago
    “A good compromise leaves everyone angry.”
- dm03514 11y ago
  That's what jumped out at me too :) I'd favor longer term release sometimes it's difficult to mobilize organizations I work for to upgrade : Love django been using it for 5 years, go to web framework
dwightgunning 11y ago
This is really interesting from a community point of view. Embarrassingly I didn't hear about the survey and thus didn't submit responses. Lots to learn from the answers though. Does the Rails community do a similar survey?
- steveklabnik 11y ago
  There is http://www.askr.me/ruby http://www.askr.me/ruby
scrollaway 11y ago
I wonder, are the text replies on the agree/disagree/favorite/least favorite sections exhaustive? I'm guessing they were filtered somehow since there's so few, compared to the amount of replies (and the lack of people talking about their privates).
nchelluri 11y ago
Just a quick and minor note, the title of this link has a spelling mistake, "Survery".
simonlebo 11y ago
I've been starting a few Django projects during the last few years and I have had trouble finding packages that are compatible with the latest versions. Maybe their release cycle is too fast for all the 3d party apps to keep track? Also I find that some of these 3d party apps use a notation like >= Django 1.X but that's not really true because of backwards incompatibility. A clearer way to know what exact version Django apps are compatible with would already be really helpful.
- ubernostrum 11y ago
  I requested, and the maintainers added a while back, trove classifiers on the Python Package Index to indicate compatibility with Django versions (similar to what was already available for Python versions and some other popular frameworks). Currently 112 packages on the index classify as Django 1.8 compatible: https://pypi.python.org/pypi?:action=browse&c=605 https://pypi.python.org/pypi?:action=browse&c=605 So encourage package maintainers to use those classifiers, and you'll be able to tell easily which packages are and aren't compatible :)
  - SudoAlex 11y ago
    There needs to be more promotion of this, as this is the first time I've heard about the version specific classifiers. I'd have to agree with simonlebo - it's getting harder to find packages compatible with the latest version. Some of these are just slow at updating, but will eventually get around to it at some point. However given how old Django is now, there's going to be plenty of old projects which clutter up search results for packages which are no longer maintained. Maybe djangopackages.com could add support/filtering to hide outdated Django projects. Or perhaps the encouragement could come in a more official way with a Django Package Index - a site which uses PyPI data, but with filtering biased towards the current released version of Django to encourage people who maintain those packages to get a new version out with support for the latest version.
owaislone 11y ago
I see some comments about static assets management, reactjs and webpack. If anyone is interested, I've written an app that integrates these things with django in a clear and easy way. Check it out: https://github.com/owais/django-webpack-loader/ https://github.com/owais/django-webpack-loader/
mianos 11y ago
It's quite interesting that the ORM comes in first in the question on value. Ahead of routing and views. Once I learnt and used SQLAlchemy, I think the Django ORM is lesser component than the routing/view processing, which I find much of a much-ness in terms of the other major frameworks. That said, in django, batteries are included, and spares, and rechargables, and a charger!
- indymike 11y ago
  The ORM has great utility. There are better ORMs but the built-in Django ORM is plenty good enough.
- marcosdumay 11y ago
  The Django ORM isn't that good, that's true. But the framework integrates with it, and several great features depend on that integration.
Ciantic 11y ago
I've used Django a lot, however for past few years I've wanted to transition to type safe languages. Python should get serious about static analysis, e.g. mypy or some such, they provide a great way to increase productivity, and help you refactor if something changes. I tried with Atom and (jedi) plugin, get this `CharField([Ctrl+Space]`, it fills me with `CharField( * args, * * kwargs)`, sigh.
- eeZi 11y ago
  https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/
- raverbashing 11y ago
  > Python should get serious about static analysis Then it's not python I love people trying to shove static typing onto python when there's a multitude of other choices to pick. The alternatives suck exactly because of that. If you want static typing go use Java, Go, etc.
  - rattray 11y ago
    What about optional, inferred, lightweight static typing? Do those things ever suck? What would be bad about that?
    - raverbashing 11y ago
      If you want a static check of your program, use PyLint, it's excellent at detecting most errors, be them syntax, typing error (things like x = 10; x.do_stuff() ) I think annotations would be useful in very few cases, since interfaces are not bound by types and that's what's good about python
  - Ciantic 11y ago
    Optional typing is definitely coming. As eeZi pointed out, and I've been following this in the mailing list also. https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/ Guido is pushing to standardize mypy as static analysis for py3k, but it is taking so damned long, meanwhile something like TypeScript is already superb with it's compiler service architecture providing great tooling for all kinds of editors & IDE. PEP484 is simply too little, to get good tooling it requires compiler service (API for IDEs), and we are long way from that.
throwaway77632 11y ago
Missed the survey but going to express my feelings here hoping that they will still be read. I like the opinionated, batteries included approach of Django a lot. My major gripe with it is that it only takes you so far. There's a ton of ever expanding documentation out there how to make your first app. Whether it's the official tutorial, another one or a workshop. But when looking to build something less trivial—not just bigger, but more complicated—I don't know where to look for in-depth guidance. Compared to Rails there really aren't too many books out there. I should give an honorable mention of Two Scoops of Django, but the style of many loose bits of good advice still doesn't help me with the bigger picture. Getting Started with Django made me hopeful, but somehow it never got past the first few episodes which again cover just the basics. Where to go after that? Just asking questions doesn't cut it. If the question is too broad, you're referred to the documentation, or the answer is too broad as well. And asking a specific, answerable question is hard when you're not comfortable with the technology yet. Either way, it takes too long to ask all the questions that arise and wait for the variety of answers that might follow, compared to reading a book with well-worked examples or so that form a coherent whole. I'm starting to feel that the only way to get fluent in Django would be to get a job in an experienced Django shop, which IMO should not be the case. On IRC in particular I sense an off-putting attitude that "we experienced Django developers know how to do it right" without really making that knowledge accessible to others. The documentation isn't by far as opinionated as the framework itself. As a result, I end up trying things that in the end can't be made to work well. TLDR; I would like Django to be more accessible not just to beginners but especially to advanced starters.
- bdevine 11y ago
  I've felt more or less the same as you and recently I've found Test-Driven Development with Python[0] to be a really nice resource. It is first and foremost a TDD book, which I certainly appreciate, but it takes you through creating an app in a (to my eyes at least) fairly rigorous way. It probably shouldn't serve as an introduction to Django but for someone who has a basic idea of how a project is put together but has never connected those dots, it might be really helpful. [0] http://shop.oreilly.com/product/mobile/0636920029533.do http://shop.oreilly.com/product/mobile/0636920029533.do
- 11y ago
knes 11y ago
I see a lot of feedback about how difficult it is to use websockets or add real-time features to an Django app. I work at Pusher (http://pusher.com http://pusher.com) and this is exactly what we do. We make it dead simple for any developers to use websockets and handle the scaling and maintenance for them. We even have custom libraries for Django such as Django-pusherable https://github.com/pusher/django-pusherable https://github.com/pusher/django-pusherable Associated blog post at https://blog.pusher.com/django-pusherable/ https://blog.pusher.com/django-pusherable/
- aaronbasssett 11y ago
  Thanks for a mention of the library/blog post :) I also did a talk at this year's DjangoCon Europe about building realtime apps in Django which covers integrating Swampdragon[1] and Pusher in Django. Video of the talk isn't up yet but the slides are on Speakerdeck[2] and my example code is on Github[3]. [1]: http://swampdragon.net/ http://swampdragon.net/ [2]: https://speakerdeck.com/aaronbassett/effortless-real-time-apps-in-django https://speakerdeck.com/aaronbassett/effortless-real-time-ap... [3]: https://github.com/search?q=user%3Aaaronbassett+djangocon https://github.com/search?q=user%3Aaaronbassett+djangocon
  - ceyhunkazel 11y ago
    Could you compare swampdragon vs Pusher? Ease of use, cost, overall experience etc.. Any guide which to choose?
    - aaronbasssett 11y ago
      It is not a mutually exclusive decision. I used Swampdragon's serialisers with Pusher (and hopefully in future releases Swampdragon will share its serialisers with DRF as well). In terms of ease of use, Pusher is easiest to setup as it is a PaaS service so you don't need to install anything. Swampdragon has a slight advantage that you can run it locally without any outside dependencies, which is nice for development. Scaling and cost, well it depends on your current architecture. Swampdragon you'll need to scale out/maintain your own Redis and Tornado servers whereas with Pusher it's a fixed cost and you don't have to worry about scaling/bursting etc. A pattern I've seen personally is people start with self-hosting until they reach more concurrent connections than a single server can comfortably handle and then switching to a PaaS service like Pusher.

113 points by neokya 11y ago

This is an awesome survey. I am a avid fan of Django and have been using it for over 4 years. I found it amusing people are split between 6 and 12 month for release cycles.

neokya 11y ago
Thus new release cycle will be 8 months, middle ground. There are few other changes for release, notably SemVer adoption. For detailed Roadmap, see https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ https://www.djangoproject.com/weblog/2015/jun/25/roadmap/
- shabda 11y ago
  “A good compromise leaves everyone angry.”
dm03514 11y ago
That's what jumped out at me too :) I'd favor longer term release sometimes it's difficult to mobilize organizations I work for to upgrade : Love django been using it for 5 years, go to web framework

dwightgunning 11y ago

This is really interesting from a community point of view. Embarrassingly I didn't hear about the survey and thus didn't submit responses. Lots to learn from the answers though. Does the Rails community do a similar survey?

steveklabnik 11y ago
There is http://www.askr.me/ruby http://www.askr.me/ruby

scrollaway 11y ago

I wonder, are the text replies on the agree/disagree/favorite/least favorite sections exhaustive? I'm guessing they were filtered somehow since there's so few, compared to the amount of replies (and the lack of people talking about their privates).

nchelluri 11y ago

Just a quick and minor note, the title of this link has a spelling mistake, "Survery".

simonlebo 11y ago

I've been starting a few Django projects during the last few years and I have had trouble finding packages that are compatible with the latest versions. Maybe their release cycle is too fast for all the 3d party apps to keep track? Also I find that some of these 3d party apps use a notation like >= Django 1.X but that's not really true because of backwards incompatibility. A clearer way to know what exact version Django apps are compatible with would already be really helpful.

ubernostrum 11y ago
I requested, and the maintainers added a while back, trove classifiers on the Python Package Index to indicate compatibility with Django versions (similar to what was already available for Python versions and some other popular frameworks). Currently 112 packages on the index classify as Django 1.8 compatible: https://pypi.python.org/pypi?:action=browse&c=605 https://pypi.python.org/pypi?:action=browse&c=605 So encourage package maintainers to use those classifiers, and you'll be able to tell easily which packages are and aren't compatible :)
- SudoAlex 11y ago
  There needs to be more promotion of this, as this is the first time I've heard about the version specific classifiers. I'd have to agree with simonlebo - it's getting harder to find packages compatible with the latest version. Some of these are just slow at updating, but will eventually get around to it at some point. However given how old Django is now, there's going to be plenty of old projects which clutter up search results for packages which are no longer maintained. Maybe djangopackages.com could add support/filtering to hide outdated Django projects. Or perhaps the encouragement could come in a more official way with a Django Package Index - a site which uses PyPI data, but with filtering biased towards the current released version of Django to encourage people who maintain those packages to get a new version out with support for the latest version.

owaislone 11y ago

I see some comments about static assets management, reactjs and webpack. If anyone is interested, I've written an app that integrates these things with django in a clear and easy way. Check it out: https://github.com/owais/django-webpack-loader/ https://github.com/owais/django-webpack-loader/

mianos 11y ago

It's quite interesting that the ORM comes in first in the question on value. Ahead of routing and views. Once I learnt and used SQLAlchemy, I think the Django ORM is lesser component than the routing/view processing, which I find much of a much-ness in terms of the other major frameworks. That said, in django, batteries are included, and spares, and rechargables, and a charger!

indymike 11y ago
The ORM has great utility. There are better ORMs but the built-in Django ORM is plenty good enough.
marcosdumay 11y ago
The Django ORM isn't that good, that's true. But the framework integrates with it, and several great features depend on that integration.

Ciantic 11y ago

I've used Django a lot, however for past few years I've wanted to transition to type safe languages. Python should get serious about static analysis, e.g. mypy or some such, they provide a great way to increase productivity, and help you refactor if something changes. I tried with Atom and (jedi) plugin, get this `CharField([Ctrl+Space]`, it fills me with `CharField( * args, * * kwargs)`, sigh.

eeZi 11y ago
https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/
raverbashing 11y ago
> Python should get serious about static analysis Then it's not python I love people trying to shove static typing onto python when there's a multitude of other choices to pick. The alternatives suck exactly because of that. If you want static typing go use Java, Go, etc.
- rattray 11y ago
  What about optional, inferred, lightweight static typing? Do those things ever suck? What would be bad about that?
  - raverbashing 11y ago
    If you want a static check of your program, use PyLint, it's excellent at detecting most errors, be them syntax, typing error (things like x = 10; x.do_stuff() ) I think annotations would be useful in very few cases, since interfaces are not bound by types and that's what's good about python
- Ciantic 11y ago
  Optional typing is definitely coming. As eeZi pointed out, and I've been following this in the mailing list also. https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/ Guido is pushing to standardize mypy as static analysis for py3k, but it is taking so damned long, meanwhile something like TypeScript is already superb with it's compiler service architecture providing great tooling for all kinds of editors & IDE. PEP484 is simply too little, to get good tooling it requires compiler service (API for IDEs), and we are long way from that.

throwaway77632 11y ago

Missed the survey but going to express my feelings here hoping that they will still be read. I like the opinionated, batteries included approach of Django a lot. My major gripe with it is that it only takes you so far. There's a ton of ever expanding documentation out there how to make your first app. Whether it's the official tutorial, another one or a workshop. But when looking to build something less trivial—not just bigger, but more complicated—I don't know where to look for in-depth guidance. Compared to Rails there really aren't too many books out there. I should give an honorable mention of Two Scoops of Django, but the style of many loose bits of good advice still doesn't help me with the bigger picture. Getting Started with Django made me hopeful, but somehow it never got past the first few episodes which again cover just the basics. Where to go after that? Just asking questions doesn't cut it. If the question is too broad, you're referred to the documentation, or the answer is too broad as well. And asking a specific, answerable question is hard when you're not comfortable with the technology yet. Either way, it takes too long to ask all the questions that arise and wait for the variety of answers that might follow, compared to reading a book with well-worked examples or so that form a coherent whole. I'm starting to feel that the only way to get fluent in Django would be to get a job in an experienced Django shop, which IMO should not be the case. On IRC in particular I sense an off-putting attitude that "we experienced Django developers know how to do it right" without really making that knowledge accessible to others. The documentation isn't by far as opinionated as the framework itself. As a result, I end up trying things that in the end can't be made to work well. TLDR; I would like Django to be more accessible not just to beginners but especially to advanced starters.

bdevine 11y ago
I've felt more or less the same as you and recently I've found Test-Driven Development with Python[0] to be a really nice resource. It is first and foremost a TDD book, which I certainly appreciate, but it takes you through creating an app in a (to my eyes at least) fairly rigorous way. It probably shouldn't serve as an introduction to Django but for someone who has a basic idea of how a project is put together but has never connected those dots, it might be really helpful. [0] http://shop.oreilly.com/product/mobile/0636920029533.do http://shop.oreilly.com/product/mobile/0636920029533.do
11y ago

knes 11y ago

I see a lot of feedback about how difficult it is to use websockets or add real-time features to an Django app. I work at Pusher (http://pusher.com http://pusher.com) and this is exactly what we do. We make it dead simple for any developers to use websockets and handle the scaling and maintenance for them. We even have custom libraries for Django such as Django-pusherable https://github.com/pusher/django-pusherable https://github.com/pusher/django-pusherable Associated blog post at https://blog.pusher.com/django-pusherable/ https://blog.pusher.com/django-pusherable/

aaronbasssett 11y ago
Thanks for a mention of the library/blog post :) I also did a talk at this year's DjangoCon Europe about building realtime apps in Django which covers integrating Swampdragon[1] and Pusher in Django. Video of the talk isn't up yet but the slides are on Speakerdeck[2] and my example code is on Github[3]. [1]: http://swampdragon.net/ http://swampdragon.net/ [2]: https://speakerdeck.com/aaronbassett/effortless-real-time-apps-in-django https://speakerdeck.com/aaronbassett/effortless-real-time-ap... [3]: https://github.com/search?q=user%3Aaaronbassett+djangocon https://github.com/search?q=user%3Aaaronbassett+djangocon
- ceyhunkazel 11y ago
  Could you compare swampdragon vs Pusher? Ease of use, cost, overall experience etc.. Any guide which to choose?
  - aaronbasssett 11y ago
    It is not a mutually exclusive decision. I used Swampdragon's serialisers with Pusher (and hopefully in future releases Swampdragon will share its serialisers with DRF as well). In terms of ease of use, Pusher is easiest to setup as it is a PaaS service so you don't need to install anything. Swampdragon has a slight advantage that you can run it locally without any outside dependencies, which is nice for development. Scaling and cost, well it depends on your current architecture. Swampdragon you'll need to scale out/maintain your own Redis and Tornado servers whereas with Pusher it's a fixed cost and you don't have to worry about scaling/bursting etc. A pattern I've seen personally is people start with self-hosting until they reach more concurrent connections than a single server can comfortably handle and then switching to a PaaS service like Pusher.