Django is falling behind | Hacker News Reader

Django is falling behind

kfalck.net

28 pointskennu37 comments

The headline is sensational, and Mongodb support is a poor yardstick. And, using Rails as _the_ benchmark is another poor choice.

That said, as a full-time Django developer, the headline resinated with me, although I can't put my finger on exactly why. It feels like the last 3 releases (1.3, 1.4, the 1.5 betas) have been lacking in terms of their vision and scope.

Some things I'd appreciate seeing:

* Cleaning out django.contrib, and shifting to a more modular methodology for not-quite-core functionality.

* The default settings.py is just downright laughable compared to what one typically uses for production. Rolling your own environment-specific files (ala local_settings.py) could also use some attention.

* Django admin is still a killer app, but the visual design is long in the tooth. Integrating twitter bootstrap, Zurb's foundation (or any modern HTML/CSS framework) would be a huge improvement.

* Merging South (or any db migration system) into core would be great.

* Revisiting management commands (both the layout and the features) would be great.

* Easier/cleaner support for eventlet or gevent would be nice. At least at the routing and view level.

* PKs with some sort of UUID

* A vision for loosely coupling apps together. 1.5 will be including custom User models, which is handy, but doing something globally would be great. It will always be up to individual app developers to get to the last mile, but some sort of plumbing in Django core would be very handy.

Funny, your TODO list looks a lot like mine.

https://github.com/sehmaschine/django-grappelli is a quite nice theme for admin

django-grappelli is very nice. However, something like Bootstrap has a lot more going for it in terms of a ecosystem, which would be a really nice side effect if it was brought into Django.

Give a shoot to my project then: https://github.com/riccardo-forina/django-admin-bootstrapped

The aim is to refresh the admin frontend without polluting it with extra python code.

* Inlines for stacked inlines in the admin. * Better defined production/deployment practises (A set of Fabric scripts, for instance?)

At the core developer Q&A during DjangoCon US this year, it was pretty much universally agreed upon that non-relational database support for the core of your app was too much of an edge-case to bother finishing work on.

I used MongoDB for a year and a half. For 99% of projects that I see on HN and hear about IRL, I'm comfortable saying that you don't need that as your core database. Consider it for the portion of your domain that actually needs nonrel benefits (such as analytics), along with others like Couch, Redis, or Riak.

Your thinly-veiled CRUD app with a social layer doesn't need MongoDB. Here's a nickel, go use a real relational system like Postgres that makes sense for the meat of your data.

Your narrow-minded approach fails to consider the fact that his web application might need to be web scale.

not sure if you're trolling - please define "web scale"?

Well since his username is a slight variant on the parent's username, he's probably trolling and making reference to http://www.youtube.com/watch?v=b2F-DItXtZs

The tone of your comment was not necessary. Keep it constructive and positive.

NoSQL support is one of the least interesting ways that I find Django failing to keep up.

I'd much rather see catching up with regard to ORM/SQL efficiency improvements, cache infrastructure usefulness, resolving the manager/queryset/model-method wackiness, or a half dozen other things where I feel like I don't have much argument to make w/ Rails folks when it comes to comparing the frameworks.

Improvement to the ORM should be the #1 priority IMO. This is my single biggest pain point with Django.

Agreed. I keep looking for reasons to use Django for anything other than small/medium complexity apps - but Rails keeps winning for these..... yet I prefer Python but have to construct in Ruby.

I've never tried this, but is using SQLAlchemy with Django relatively easy and production-worthy?

Nothing about SQLAlchemy has ever been easy, in Django, Flask, or raw WebOb Python apps I've worked on.

It's production-worthy, but the tax it levies on your soul probably isn't worth it.

https://github.com/coleifer/peewee

You can use SQLAlchemy's connection pooling in conjunction with the Django ORM:

https://github.com/kennethreitz/django-postgrespool

I work with Django full time on an app that is relatively large and complex. It works great, but that damn ORM costs me so much time. Everything else is great. I really enjoy how everything else works together. But, again, that damn ORM...

Can you elaborate on "resolving the manager/queryset/model-method wackiness"? I haven't used another web framework in a while so I'd like to see a comparison to understand your frustrations.

Something like including this in core: https://github.com/zacharyvoase/django-qmethod

The idea that if I want to do either:

People.objects.short().blonde() People.objects.blonde().short()

... I need to implement short() and blonde() on Manager and QuerySet classes for the model. Creating chained query filters like this ought to be easier, and encouraged IMHO.

> I'd much rather see catching up with regard to ORM/SQL efficiency improvements, cache infrastructure usefulness

I hope you're talking about Sequel and not that namespace-polluting, memory-consuming, bloated beast called ActiveRecord. In that case, I wholeheartedly agree.

Oh right, fair point. When it comes to ORM/SQL generation I don't know of anything Rails does particularly better. Someone told me that in Rails you're more aware of when you're creating new joins. I think that might be useful. In this django query there's an elegance that can come from each call to .filter() or .exclude() making their own join, but it confuses people as well... and not being able to re-use the joins makes it impossible to do things like get around the lack of a 'not-equal' operator in some cases [1]:

Author.filter(books__page_count__gt=100).filter(books__deleted=False)

Really though, in this case I just wish Django would do better than it does now.. or at least better than it did in prior versions [2]. There's hope though, @akaarial appears to be kicking ass and taking names in this area lately.

[1]: https://code.djangoproject.com/ticket/5763

[2]: https://code.djangoproject.com/ticket/10790 and https://code.djangoproject.com/ticket/18785

I assume that anyone who agrees with this post doesn't actually do programming, and would struggle to instantiate a Redis client and then use it in the simplest manner.

You cant have a RELATIONAL mapper without a RELATIONAL database, and you break nearly all of the constraints with many of these "NoSQL" solutions that the Django ORM relies on.

If you want to use NoSQL, use it. There's no reason the Django ORM needs to support it. Programming isn't hard.

I would claim thare are benefits in a framework having a similar API for both for SQL-ORM and NoSQL-ODM. This has already been done in the Ruby on Rails world, where ActiveRecord and Mongoid exist in parallel and have similar interfaces. This makes it much easier for third party modules to support both of them.

Perhaps ideally, the ORM API is a superset of the ODM API with added support for transactions and deeper relations etc. Apps that don't need those features can then easily support both.

What benefits? They're completely different technologies. They share very few characteristics, and many apps which are built on SQL using the ORM would not "just work" on a NoSQL engine.

You also are only talking about MongoDB. Who cares about MongoDB? Maybe you do. What about the guy using Cassandra? Or Redis? Or Couchbase? etc etc etc

They all have very different properties, and the only thing they have in common is that they store data, and some of them allow you to query on the data.

How did this get on the front page?

- The headline is sensational (goes from "Django doesn't support NoSQL" to "Django is falling behind").

- Author says Django "claimed to be SQL-agnostic" then goes on to conclude that it isn't because it doesn't support NoSQL data housing. What? SQL-agnostic doesn't mean storage agnostic. It means /SQL/-agnostic.

You might be right that the "SQL-agnostic" argument was not well formed. I basically meant that the Django ORM has always been very object-oriented, and it has avoided SQL-specific concepts like WHERE clauses as much as possible. And because of this, it wouldn't be so hard to make it work with MongoDB, except for more complex relations. In fact, this has already been done by django-nonrel for 1.3.

If anybody thinks the article was satire, it was not. In fact it was written during a MongoDB conference. ;-) I really am worried that as MongoDB has passed the hype phase and is now becoming a regular and supported part of web technology stacks, Rails is the only heavy-weight framework/ecosystem that really supports it.

I also think that MongoDB currently adds most value to small/mid-size web projects, whose development speed can benefit from the schemalessness and other flexibility compared to RDBMSs. It's not that relevant whether it can actually be used to build the next Facebook or Twitter.

(I wrote the original article.)

It's only falling behind if you consider MongoDB to be a forward technology. I don't.

Check out my project http://pypi.python.org/pypi/django-mongonaut / https://github.com/pydanny/django-mongonaut which which when tied with MongoEngine provides you with a stable interface for building django.contrib.admin-like UIs just as easily.

Also, why not just use Postgres with Hstore? All the benefits of MongoDB, but with the bonus of being in a mature, stable database. And integration with Django is trivial.

why on earth would you want to have mongo as main database to emulate relations?

Why, to make it to the HN frontpage of course! :)

I have used MongoDB as the main database for many small/mid-size web projects and found it to be very flexible compared to MySQL/Postgres:

- No manual database/user creation needed

- No manual table creation needed

- No schema migrations needed

- No nested relations needed, because typical web app data structures fit well as dictionaries/lists

- No extra caching layer needed because of previous point

So basically, your app is simpler, and when you give it to a co-developer who has MongoDB installed, he can just start using it. And when you develop further, you don't have to mess with the schema migrations either with co-workers or when deploying to the server.

Falling behind != default support for MongoDB

Besides, adding mongodb support (including admin) to Django is trivial with pip install django-mongodb-engine pymongo.

No it's not.

By the way, if you're interested in being agnostic on your NoSQL backend, take a look at Schematics https://github.com/j2labs/schematics

"Django doesn't have the feature I want, so it's doomed to irrelevance." Rails will win, driving a ruby-tipped stake through Django and nobody will be able to use it for anything any more.

What about http://django-mongodb.org/?

that is django-norel, which he mentions in the post

https://github.com/django-nonrel/django-nonrel

Reply on news.ycombinator.com