£17,952 pledged of £2,500 goal. So it looks like this should be happening. Stated intention as to when:
> As the intention is to get something into Django core itself, the idea is to land this for either the 1.6 or 1.7 release of Django. The work itself should be mainly completed by July 2013, and ready for alpha testing and feedback at that point for those who want to try a development version of Django.
It should help people just getting started with Django to have a smoother transition. I will add various templates with "best practices", like South included by default, stuff like that, to help both me and complete newcomers to easily get started with a new project.
> Django have a bright future in a world that's moving heavily client side, or will it be relegated to a relatively bland corner of the web world?
This is one of those questions seeking controversy where there is none. Django seems to get out of the way even more when you shift to a heavier client.
We don't have to bake components in for them to be excellent. rest-framework in particular moves ridiculously fast, and being separate from Django lets them do that. Also, if in the future something even better comes out, I can easily switch to it.
Why do you think it's being held back? I'm just not seeing the barriers in using newer tech. We stay pretty cutting edge, and haven't had any issues doing so with Django.
Consider that the reason you don't hear about it isn't due to it not being used but instead to a cultural difference in the people who choose it. I don't think Django developers are particularly good at blogging and self-promotion compared to other projects. They communicate through mailing lists, IRC, twitter, email and documentation. I'm ok with that.
When I started my project, I evaluated a lot of different options and chose Django. One of the big factors was a cultural commitment to documentation and slow measured changes with lots of thought put into backward compatibility. Blog posts about hot startups that are using it is low on my list. (and if you do your research you will see that a surprising number of hot new startups are in fact using it)
I like playing with Go and the other newer/trendy stuff, but the thing I like about Django is that I can just sit down and get work done fast. It's not sexy, it's not clever, it's not magical, but I don't want it to be any of those things.
As a side effect of this, a huge percentage of the population is too busy getting stuff done with Django to blog and interact, aside from asking questions and getting advice. You know, like Instagram, Pinterest, NASA, National Geographic, Disqus, Mozilla, The Onion, PBS, and many more.
Plus, it's not hot new stuff, they largely attempt to make upgrading easy.
Django to me is what .Net is to C#. It's the libraries around the Python language that make it useful.
Where are you getting the data for the client from? Django-Rest-Framework is a very convenient way to get data down into the browser layer from a DB.
The framework is said to be reactive, meaning that you can build components that react to events asynchronously. The architecture is completely awesome, as Akka actors are baked in and the protocols are modelled with Futures and Iteratees, an FP concept for sane I/O. Things like serving unending streams of data and responding to client events using async I/O are in the very foundations of the framework, instead of being taked on later. People using Node.js or Tornado or whatever, don't know what they are missing.
See their docs on the subject:
- for Scala: http://www.playframework.com/documentation/2.1.1/ScalaAsync
- for Java: http://www.playframework.com/documentation/2.1.1/JavaAsync
Deployment to Heroku works out of the box btw.
By doing that I lose the wsgi functionality (you get only low level stuff, just like you'll get on java or .net), must synchronize with the normal http server with the DB (what I'll do anyway, since it's the easiest path with Django), and there is some dificulty dealing with signals (the same you'll get with java or .net). And that's all.
Or, TLDR, you lose a few features, that'll make your code resemble a bit more what you'd need to write in java or .net, but preserves most of it.
I haven't used it personally, and would be very interested to hear others' thoughts.
EDIT: Looking through the example code ( https://github.com/abourget/gevent-socketio/tree/master/exam... ), it doesn't seem as straightforward as one might hope, especially compared to the channels API.
FWIW, I'm using the AppEngine Channels API from my Django app, and have yet to be disappointed with it.
Socket.io for node.js is very awesome for stuff like that.
The original bug:
Got even worse in 1.4
I started this right away: http://www.stavros.io/posts/django-template-projects/
I'll post various templates there, for example a default one containing all the "best practices" that I use (and structured that way), one that includes Persona by default (so you can just click the "Log in with Persona button" and log in), etc.
I love this feature.
(Incidentally, I hope to get this new version into Round 7 of our project.)
In 1.6, Django will optionally not do this; instead, a setting can specify the maximum amount of time to hold open and keep reusing an existing connection.
This is not connection pooling; that would imply some functionality to actively maintain and allocate connections. This is simply "your process will hold its connection open from one request/response cycle to the next".
In what scenario can this be used?
Still no update for the homely admin app? Would love to have it use bootstrap (or similar) to offload look and feel to those focused on it. One extra thing to do in every Django app is to change the ugly yellow on cyan title bar. I know it is already possible with apps, but then it means one more thing to fix on upgrade.
Watching this with interest.
(He said, sarcastically.)
Seriously, it is GREAT to see the framework continue to roll forward.