

Django Developers Survery Results - neokya
https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewanalytics

======
mianos
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!

~~~
marcosdumay
The Django ORM isn't that good, that's true. But the framework integrates with
it, and several great features depend on that integration.

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

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

Like learning any serious language/framework, it requires a relatively large-
scale project to really understand all of the moving parts. Project Euler
isn't going to cut it, but most web-application ideas you might have should
expose you to quite a bit. To-do lists, workout logs, weather trend tracking,
etc. would all be decent learner projects. Basically anything with somewhat
normal data that multiple users can input & view.

It's obviously more complex than something like Flask, but it's definitely not
as convoluted or unintuitive as Twisted. Django covers a lot of territory with
the number of features it provides (ORM models, URL routing, request-handling
views, templating, management commands, middleware, etc.), but each of those
features is well-isolated and reasonably easy to grok if you focus on one at a
time.

------
owaislone
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/)

------
knes
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
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-
ap...](https://speakerdeck.com/aaronbassett/effortless-real-time-apps-in-
django) [3]:
[https://github.com/search?q=user%3Aaaronbassett+djangocon](https://github.com/search?q=user%3Aaaronbassett+djangocon)

~~~
ceyhunkazel
Could you compare swampdragon vs Pusher? Ease of use, cost, overall experience
etc.. Any guide which to choose?

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

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

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

~~~
raverbashing
> 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
What about optional, inferred, lightweight static typing? Do those things ever
suck? What would be bad about that?

~~~
raverbashing
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_

------
jtchang
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
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
“A good compromise leaves everyone angry.”

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

------
dwightgunning
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
There is [http://www.askr.me/ruby](http://www.askr.me/ruby)

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

