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!

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

The ORM has great utility. There are better ORMs but the built-in Django ORM is plenty good enough.

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/

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.

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

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

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

Associated blog post at https://blog.pusher.com/django-pusherable/

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

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

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.

And of course there is also Pushpin, which allows Django to delegate WebSocket and long-lived HTTP connection handling.

This is not a cop out, either. In a multi-tiered architecture, it's preferable to avoid stateful sessions between the edge and backend.

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

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.

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

What about optional, inferred, lightweight static typing? Do those things ever suck? What would be bad about that?

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

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/

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.

I agree, I've been looking for something as good as Django in languages like Java, Go, and even Rust but I haven't stumbled across anything equivalent yet.

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.

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/

“A good compromise leaves everyone angry.”

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

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

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?

There is http://www.askr.me/ruby

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.

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

So encourage package maintainers to use those classifiers, and you'll be able to tell easily which packages are and aren't compatible :)

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.