Django Community Survey | Hacker News Reader

Django Community Survey

djangoproject.com

170 pointsjsmeaton39 comments

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.

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.

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 if you haven't already

I'm in the planning phase of porting a large C# application's frontend to React on Node (for isomorphism).

Basically we'll have our main application server (in this case, .net mvc api, but think django-rest-framework) talk to a node server as well as the client, with the same REST api. The plus is very real separation of concerns (django does all data handling, business logic; javascript does all UI). The downside is having two server stacks.

FWIW, I'm planning to use nuclear-js[1] for flux. And we're considering porting our .net code to django.

[1] https://github.com/optimizely/nuclear-js

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.

Simplest solution I've found is to run the devserver in a gulp task instead of using any of the pipeline/compressor projects.

My current app stack is a React+fluxxor frontend consuming a django-rest-framework driven API. The frontend/backend live in the same repo for simplicity, but are otherwise separate projects in their own subpaths that share nothing.

For deployment, I have the root path serve up the client, while the API is on its own subdomain.

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.

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.

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/

hm I switched mainly to Java/Scala cause of the testing bits. I mean I have a really fast H2 InMemory database that is way closer to prod than any SQLite solution + ORM.

Next of DI.. I could just create a new Module/Dependency for my tests.

However I'm still lacking expertise in the testing bits.. Still looking for good books.. About specs / mockito, integration tests etc..

I feel you too.

I have found SublimeCodeIntel to be quite helpful even without static typing, fwiw. And I've heard even better things about PyCharm. But I also wrote almost the same thing in my feedback - Python's lack of static typing is a major bummer.

Have you tried Python 3? (I know there are valid reasons not to). But it has function annotations, which are enforceable through tools like typeannotations[0] or mypy[1], and much better support for concurrency with asyncio, and async/await/yield from/etc. Note - I haven't tried these features, I'm curious for the opinions of those who have.

[0] - https://github.com/ceronman/typeannotations [1] - http://mypy-lang.org/

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

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.

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.

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.

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.

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.

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

There is an Apache/mod_wsgi image from the mod_wsgi maintainer. It was pretty easy to set up, and Graham has more in depth documentation on his blog.

https://github.com/GrahamDumpleton/mod_wsgi-docker

I've been evaluating using uwsgi as a stand-alone server. I'm not sure how much load it would support, but I think it's possible get quite far with Django, sqlite, and uwsgi.

Here's an example of a run of the mill 'nginx', 'gunicorn', 'supervisord' setup: https://github.com/Pakebo/eb-docker-django-simple/blob/maste...

I mentioned the admin interface as well. I wish it was easier to customise when you need something more user friendly, and not something that is just a GUI for accessing the database. But it is hard to get away from, since everything else by default plugs into it.

After customizing the admin interface so that it could be used by the staff of a couple of organizations I wrote web sites for, I realized that it's much easier to write normal views for this. It's simple to use decorators to enforce staff logins on views. Really customizing the admin becomes pretty tortuous pretty fast. However, it's great to have available as an interface to the DB for the developer; not so much for the users.

Don't mind my personal plug, but you might be interested in taking a look at Smartmin: https://smartmin.readthedocs.org/en/latest/

(don't mind the stale release, just use master)

It is a much, much better admin-like tool to use for building CRUD views, with strong conventions on permissions, URL structures and template names. It really simplifies things and we've been using it internally for four years on a dozen different projects.

Can't imagine using Django without it.

Sounds neat but I'm having trouble figuring out what it does. Maybe you could include screenshots, and simple sample code showing how it's used?

I will also have to write normal views for it. I just would like some easy system for pluging those views all together nicely for, without having to do it myself. Also some extra stuff to take care of permissions when doing that. I eventually I think I will have to write my own such system to get what I want.

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

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/

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

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

and I chose Django because it was Python

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.

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.

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 [2] https://docs.djangoproject.com/en/1.8/topics/migrations/#squ...

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.

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.

Why not cache the database post migration?

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

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

Reply on news.ycombinator.com