

Django Community Survey - jsmeaton
https://www.djangoproject.com/weblog/2015/may/07/community-survey/

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

~~~
simonpantzare
I put nginx in front and a location /static/ block with a try_files directive
that first tries to serve static files from Django (those collected with
python manage.py collectstatic) and falls back to serve files that a gulp task
generated.

To serve different assets in dev and prod I let gulp generate a manifest and
have a custom template tag in Django that expands to different paths depending
on settings.DEBUG:

    
    
      {% my_static 'css/all.css' %}
    

expands to either /static/css/all.css or something like
/static/css/all.min.abcd1234.css.

If nginx is serving a minified, hashed path it adds a Cache-Control: max-
age=31556926 header to the response.

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

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

~~~
rattray
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
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
FYI some people are working on putting a (probably) docker image together for
testing purposes. The point being that contributors can test their changes to
all backends on their own terms.

I'm hoping it won't be too hard to add a deployment story at the end.

Deployment __is __a pain. Perhaps some official tutorials would be good in the
interim.

~~~
rattray
An official tutorial would be great in any case, with or without an
accompanying Dockerfile!

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

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

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

~~~
jeffasinger
Around the same time, I chose Django because it felt less magical than rails.

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

------
jeffasinger
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
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/#squ...](https://docs.djangoproject.com/en/1.8/topics/migrations/#squashing-
migrations)

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

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

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

