I'm currently working with Django for a client's project I'm developing. Coming off a LAMP stack binge, the technology itself has been an absolute delight. I've been given the directive to use South to manage the data model, but for future projects I was hoping somebody with more experience can give some insights as to what you've found works and what doesn't work. I'm not the biggest fan of South, but maybe it's just a lack of experience/patience.
Unfortunately that's the best we have right now. However, the guy who wrote South (and is a core Django developer) ran a Kickstarter last month to raise funds to write South-like functionality directly into the Django core.
£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.
I would always use South, but you need to read the migrations and _understand_ what it's doing. When it gets a conflict (and it will), you need to be able to fix up the migrations.
South is pretty great for very simplistic migrations. However, it does not issue DDL efficiently. For example, if you're adding two columns to a table, it will issue two separate ALTER TABLE statements. Depending on your database and table size, that can take twice as long as needed. It can really add up when your tables start hitting millions of records.
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.
I really enjoy working with Django, but in many ways, it seems to be staying pretty vanilla while other technologies head in more experimental directions. Does 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?
I personally hope django (and rails) keep their focus on the "bland corner of the web." The vast majority of (useful) sites out there are dead dull from a technology perspective, and I'd like tools that help me develop & deploy those types of sites as quickly as possible.
Exactly. I don't want exciting. I don't want magic. I want predictable. I want to be able to pump out high-functioning websites and add features where necessary. Let other libraries handle the bells, whistles, and doo-dads.
We've got a more complex application (Pathwright) running Django, and we're currently going much more heavy client side. Nothing about Django keeps you from doing this, and there are some excellent third party apps that actually make it very easy (django-rest-framework is awesome).
> 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.
I'd be pretty miffed if they did this. You need only look at the comments contrib to see an example of something that was OK'ish when it was incorporated, but has languished since then. Now I question the need to even have it in contrib.
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.
I'm not seeking controversy--I really enjoy Django development. It's just that I don't often hear about startups choosing to build in Django (well, besides mine), instead, going with Rails, which seems to have a more active and forward-looking developer community and more aggressive, or flashy new-school stuff like Node/Scala/Go/whatever. I guess what I'm trying to ask is, what is holding Django back? Is it just fashion, or are there more serious perceived shortcomings?
> I guess what I'm trying to ask is, what is holding Django back?
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.
I don't think Django is being held back at all. It's healthier than it has ever been.
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've seen it growing in popularity firsthand. The projects I'm involved with have seen large increases in contributors, mailing list activity, traffic on Github, downloads on PyPi over the last four or five years. PyAtl and some of the other local groups with Djangonauts in them have grown sharply over the last two years (in the Atlanta area). People from other backgrounds are more likely than ever to at least have an idea about what Django is (whereas when I was starting back in 2006 people would just stare at you).
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.
MTV Video use it. Yahoo use it. Django is massive, but it's like toilet paper or condoms. If you use it, you probably aren't going to blog about it because it's just doing it's job.
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.
I think this is an area where ASP.NET MVC excels because, while REST is nice, you also have to consider web sockets, and I have not seen good web socket support in Django, where ASP.NET has SignalR which is loads easier to configure than a custom solution with Django and Nginx/Apache. Not to mention that SignalR has very nice degradation support on both ends when web sockets are not available.
Well, if you're talking about alternatives that do asynchronism, Comet and Web Sockets well, the most convenient framework I ever used is Play 2.1
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.
We are using Amazon's EC2 for a huge-traffic web service (because ELB with auto-scalling has been working great for us) and Heroku for auxiliary services.
For websockets, I set the Django framework inside a Tornado thread.
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'm thrilled about this particular release, because it includes a significant overhaul of the way joins are built (or rather, trimmed) in the ORM and almost certainly makes your project faster if you do even relatively complex queries:
I saw this earlier and am absolutely ecstatic over the new template functionality. I can't tell you how many times I've cloned old projects to start new ones, a process which isn't very fun (due to the amount of stuff one needs to change).
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.
Thank goodness. Not being a user of the framework, the lack of database connectivity persistence in Django was among the most surprising elements of setting up the initial test cases in our framework benchmarks project. We've since then added a Postgres test with a connection pool, but I still have the memory of that surprise from the first round.
(Incidentally, I hope to get this new version into Round 7 of our project.)
Agreed! The changes to transaction management seem pretty solid too. I've found transactions to be pretty somewhat unpredictable at times in the past, so I'm encouraged by these changes.
Currently, Django closes the database connection at the end of each request/response cycle.
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".
Persistent database connections :). Glad to see the objections finally fall by the wayside.
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.
FWIW, admin2 is under active development and moving forward. I don't know if the intention is to replace the existing admin, but as it's not backwards compatible there will be some effort to upgrade if you've completed any serious customization.
I wish the admin started as an external project and stayed that way (for the sake of getting some love and attention). But of course, then we wouldn't be able to show shiny tutorial videos and people wouldn't get it automagically.
1.5 was the first release after moving to git - they freeze the release branch and let the rest of development continue on master, so now releases will tend to be quicker (we all hope) hence the surprise with 'early' 1.6. now, since we have an alpha, 1.6 is bugfixed on branch, and 1.7 features can be developped on master like now during the 1.6 release schedule.
