Channels will get there. It just wasn't quite ready on time for 1.10. Hopefully it will be ready on time for 1.11, and then it'll ship in Django.

I just used Channels in a personal project and it's great! My requirements were mostly basic and I haven't put it into production yet, but everything has gone smoothly so far.

What did you do with it? I still haven't figured out what to do with them...

I made something like a cross between a chat room and reddit. There are any number of possible rooms (like subreddits), with new top level posts popping up in real time, and when you click on a post, it expands and the replies become visible as a comment chain. It's not done yet though. For a while now I've been trying to do as much as I can on a single project for one week, and then start another. I definitely plan to come back to this one when I can.

This week I'm using Channels again too. I'm making a head-to-head Minesweeper web app where you can challenge and compete against other players. After finding an opponent, essentially you'll see your own board and your opponent's board side by side, and each players' progress is broadcast in real time via Channels to one another.

Cool games and chat both seem like obvious uses.

Why did the ORM suck before? Were there major changes done to the ORM?

Potentially in part because, until fairly recently (version 1.7 I believe), Django didn't have support for database schema migration built-in- https://docs.djangoproject.com/en/1.7/topics/migrations/

I see. If that's the only reason, not sure if it's a major problem with the ORM, given that you could use South instead with almost the same outcome.

The built-in migration code is even the continuation of South.

https://www.kickstarter.com/projects/andrewgodwin/schema-mig...

sibling mentioned ORM migrations not being built in.

It used to be that it was very hard to write custom expressions or aggregations (like `SUM`) in a way that would be first-class with ORM-provided expressions. This has been massively improved, and been made into a public API. So if the ORM doesn't support something you can write it easily.

The core has also been majorly rewritten, which has made entire classes of bugs disappear. Before 1.8, it was possible to write expressions where the filters got so complex that the ORM would just give up.

The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare.

This doesn't happen anymore.

A lot of old Django core code isn't really super durable, and you get a lot of pain because of it. But the past couple of releases have cleaned up a lot of code, making Django into an extremely clean project.

> The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare.

Is this really true? Can you point me at any tickets or examples? Everything else you've said is bang on though.

Ah, I feel bad, because I ran into this twice and didn't report this properly. The situations I ran into happened whenever I would combine filters and excludes, along with some joins. The system would simply drop filters, and just do a plain SELECT on the table. But ever since the 1.8 ORM update, I have no longer been able to reproduce this, so have assumed it was fixed through cleaning up the internals.

I did report a related bug[0] where the ORM gets confused by complex queries, but it didn't just drop the filter. It blew up, which is better but still a bit concerning.

[0]: https://code.djangoproject.com/ticket/24386

Exclude filters are awful and very unintuitive if you know SQL in my experience. I'd much prefer to use negated filters like: `.filter(id__notequal=3)`. I'm giving a talk at djangocon AU in a couple of weeks where I'll step through examples like this.

Right. Worse case, you can use `~Q` or the like. The way I recall it, this didn't solve the issue (as in: something more fundamental than "using exclude instead of filter"), but I no longer have the example...

Was pretty limited and very very inferior to SQLAlchemy. It still is, but it's bearable.

As an example off the top of my head when I started with Django you couldn't bulk create objects, if you wanted to create 100 records it needed 100 separate INSERT statements. That got old fast.

Edit: Not sure why the downvotes, perhaps comment on why you think I'm wrong?

That is true, but it was fixed in Django 1.4... in 2012. Technology moves a bit in 4 years.

Yep, but as I said it's still rather limited compared to SQLAlchemy. Stuff like aggregations are cumbersome, and it's really really easy to shoot yourself in the foot and cause O(n) queries (especially in templates and in custom admin views).

Things specific to Postgres are rather lacking. While they added support for advanced datatypes like arrays, hstore, intervals and search recently (yay!) you still can't use any other index than a standard btree one or things like recursive queries. SQLAlchemy supports all of these, and has done since forever.

Things are progressing, don't get me wrong, but there is a long way to go.

SQLAlchemy has a lot more power than Django's ORM. I'd argue that Django's ORM is more accessible to beginner SQL users though. Django handles joins for you (which admittedly breaks down with very complex queries) which is the only ORM I'm aware of that does. SQLAlchemy maps much more closely to SQL and is a tighter abstraction.

A GSOC project is currently adding customisable indexes: https://groups.google.com/forum/#!topic/django-developers/XA...

Why a shame? What would Channels buy you if it were included into the framework?

I would love to see Django split up into smaller official external packages and repackaged as two or three different official starter packs (Traditional, API, SPA, etc.) with each containing a different set of packages that make sense (DRF, Channels, Models, Views, Forms, etc.).

I know this goes against the current "Batteries are included" model, but why can't we treat Django as the standards body, and the various starter packs as the more targeted "batteries are included" frameworks.

You might as well use Flask at that point. You can use cookie-cutter to create the starter packs.

Sure, I love Flask but Django has it's own ecosystem and that's what I'm talking about. I know anyone can use cookie-cutter, but I'm talking about trimming Django itself. Externalize Forms, Templates, etc. and build several core starter packages (including current Django). This gives a few base starting points.

There are two benefits to having subpackages in the way you describe. The first, as you mention, is to slim down the framework. I don't think this gains a whole lot except for trimming down deployment sizes. If you don't use the components then the code doesn't run.

The other benefit would be so that the components could be used outside of Django. Using forms or templates might appeal to projects outside of Django. This isn't currently possible for a large majority of components since they depend on the global settings module, and/or other components.

What could be done with the dependency constraints is to build in different templates that `startproject` would create for you. It'd only be able to modify settings and write out requirements files, but it'd achieve a structure for different app types.

DJango 1.10 source download is 7MB.

I don't know what is normal for Ruby. Basic crud app in Java tends to be 20-50MB, but DJango above doesn't have DB drivers or anything yet so I suspect it is similar.

*seems reasonable.

I love Flask. People say Django is easier to use but I had a much easier time with Flask. It's well documented and very flexible.

Maybe not easier to use in general, but you don't have to replicate all the daily stuff you maybe need for your project. With Flask you have to recreate many things (for example acc management) or rely on a thrid party-dev. In django you get core stuff from the core team(also with the freedom of recreating it yourself or use some app from a thridparty-dev).

I think most Django developers would love to use their toolkit elsewhere (eg the ORM) but in practice, everything it held together by so much Django glue (setting and convention) that I don't see how it would be practical.

By that point you may as well just import Django, bootstrap it and use what you need.

The other side of this argument, is you allow each component to be developed at its own speed. Again, the integration between elements (Models→ModelForm→Forms etc) is so tight this isn't practical. Just as making them less integrated [probably] makes them harder to use for people who just want to use Django.

Django isn't that big in terms of file size, and you can just turn off the batteries you don't need.

So does that mean we should pick a new language/framework that is "hot" now and write a bunch of libraries for it? Basically, reinventing the wheel over and over and over again?

There are some differences that one could call objectively better in other technologies compared to Python/Django.

I'm somewhat conflicted about Channels. On the one hand it's cool what you can do with it and the design cleverly avoids rewriting all of Django to be async. On the other hand it is crazy how many shenanigans one needs to pull off to achieve what comes for free with Go or Erlang.

Fashion-like churn is obviously nonsense and reinventing the wheel usually a waste of time. But when you need a really round wheel and your current tools can only make hexagons...

Huh. Your argument in favor of Django is basically "it may not be cool, but it's got a lot of libraries written for it." Which is basically the same thing people used to say (and still say) about Java, compared to something "cool" and "new" like, say, Django or Rails (at the time). In other words, Django used to be picked because it was the hot new thing, but since then it's no longer hot or new, but since enough people adopted it, they wrote enough libraries for it to make it worth continuing to use on new projects.

Was Django ever the hot new thing? Python certainly isn't and has never been "hot."

In the 2000s, it seems much more like all the attention went to RoR. Now all the attention goes to JavaScript.

In the meantime, Django has steadily added new functionality while adhering to smart core principles. It really does seem to be in the sweet spot of dependability and convenience. I don't think anything else is faster to develop with.

You must have been asleep 5-10 years ago when Rails and Django were repeatedly being pitched against each other by hipster developers, leaving PHP, looking for the "new thing".

They were both scorching hot until somebody decided doing everything in Javascript was a good idea.

(Edit FTR: Given the topic thread, I feel it important to say that I didn't mean Node et al are better than Django, just that these hipsters thought —by virtue of being newer and newer is always better— it time to move on. I'm a Django dev and judging by the positive state of development, will be for a LONG time.)

I guess I remember all the hype going to Rails, not Django. For example, dozens of coding bootcamps used a Rails curriculum but I haven't heard of a single one which taught Django.

>* In other words, Django used to be picked because it was the hot new thing, but since then it's no longer hot or new, but since enough people adopted it, they wrote enough libraries for it to make it worth continuing to use on new projects.*

Yeah, in other words, it's now both mature and with a rich ecosystem. Just the ticket!

And I wouldn't even say that people went for it because it was "hot new" back in the day. People went for it because it solved their problems. Being in fashion was never it's strong point, Rails and Node/Express did far better with that.

> In other words, Django used to be picked because it was the hot new thing

I picked up Django in February 2006, in fact the (very cool) boss I had back then picked it up for me and my other programmer colleague, I think it was version 0.96 (or maybe 0.92 ?, not sure). Anyway, we didn't pick Django because it was "new and cool", my boss had a business to run (which folded two years later for unrelated reasons), but instead because Django seemed like a pretty good candidate back then at doing a decent job. Which it did, admirably well, I think ours might have been one of the first lead-management systems built on top of Django's admin interface (lots of monkey-patching involved, which is still one of my "guilty" soft-spots as a programmer 10 years later).

Anyway, web programming back then was, how to put it, in a very interesting place. In Python's case we had Zope/Plone, which had sort of its separate ecosystem doing weird (but sometimes very interesting things) like an object-oriented database (hello, ZODB!) with a very interesing routing mechanism on top of it, Quixote (https://wiki.python.org/moin/Quixote) and mod_python (on top of which I built my first personal Python web-project). PHP was the hot thing, even though not the newest thing, Java's web offering consisted in Struts and some other thing which had a related name for which you needed to be an "Java architect" in order to put 2 forms and 3 templates together, Rails was just about to be launched, ASP was a joke (at least according to my other programmer colleague, who was also teaching ASP at University) and I won't comment on Perl, of which I know not too many things (and which seemed pretty cool, I have to admit).

Considering all this of course that Django (and Rails) was a huge breath of fresh air. People nowadays take things like JS web frameworks for granted, but until not too long ago the web was a very different place (which sometimes I really miss).

Well, that's basically it. It certainly isn't cutting edge, nor anything close to it. It's stable and boring. Some people like that, believe it or not.

And there's still a lot of stuff - even new projects - written in Java and on the JVM.

Sometimes maturity trumps fads, in other words boring > hot.