Of course, you shouldn't have to write asynchronous code unless you need to - it's much easier to make errors in - and so there are synchronous consumers as well. What's interesting is that you can go between these two worlds easily, thanks to the new AsyncToSync and SyncToAsync helpers from asgiref. These let you turn any async callable into a synchronous callable, or vice-versa - letting you call the Django ORM (a synchronous interface) from an async consumer, for example.
Allowing you to run natively async code like this has allowed us to remove entire features, like the delay server, that were only there because there was no way to sleep without blocking a whole process. You can even use AsyncToSync to run a bit of asyncio code in the middle of a synchronous consumer, if you want.
There's other major changes - like entirely reworked test helpers, a routing system that supports Django URL pattern objects (both the old url and new path types), better auth integration, and more. You can read more about it all in the new Channels documentation.
This does all come at a price though, and that price is one of the highest you can pay as a user of a piece of software - no backwards-compatibility. The concepts in Channels 2 are the same, but you will absolutely have to change your code to make it work if you are porting from Channels 1.
This is not a decision I make lightly, and I tried to find a way to make things backwards-compatible that wouldn't either compromise the design of Channels 2 or drown me in maintenance debt, but in the end, that wasn't possible. Django has always been a bastion of backwards-compatibility, and it's very sad to me that I can't keep that in this case.
If you have asked me why Channels is not in Django core itself at any point, it's reasons like this. Async web frameworks are still a relatively new area in Python, as is the ability to finally set Python 2 support aside. That, along with other changes, means some of the decisions I made four years ago are no longer valid.
Even worse, it's taken me time to overcome my natural stubbornness and give in to make this change; it's hard to admit that you are wrong in public sometimes, and even more so when, as I tend to be, the type of person who works on projects mostly by yourself.
No small part of this process has been played by my friends and fellow maintainers in the Django and Python web ecosystem who never failed to give advice and suggest the right things to do when I was at a loss, and for my fellow members of the Django core team, for having far too much trust in me to get things right with the Django name hanging off of it.
One thing I would like to change as we enter into Channels 2 is how open and welcoming the project is to new maintainers. I have a nasty tendency to work on things solo, and be a controlling perfectionist about design, and this combined with the fact that very few people actually want to work on async networking code means Channels has not had nearly as many contributors as it could have.
Channels 2.0 is a somewhat unfinished release - some of the key nice things I'd like to have are deliberately not done, partially because shipping is better than perfection, and partially so there's stuff left to work on. If you are at all interested in doing something, please get in touch with me directly, and I'll try to help you through the open issues list to find something you can work on, and give some mentorship time and help as I can too if you need it.
With all that said, what does this release mean for Channels?
First off, there's plenty of room to add nicer interfaces for things like long-polling, work on alternative protocols, and generally add more of the basic batteries, as well as write a full introductory tutorial and nice example projects. I would have called this a soft release, but if I have learnt only one thing from over a decade of being an open-source maintainer it's that you're better off just doing a release even if it's not perfectly complete.
Second, there's plenty of work to do around outreach and cross-collaboration. I want to improve things for the Python web ecosystem in general, and while Django is part of that, there's plenty of other parts too. We have a lot to do if we want to keep Python relevant on the back-end over the next decade.
Finally, it means I'll be wrapping up most support for Channels 1, reducing it to just security and data-loss bug fixes. I'd love to keep it more actively maintained because of the lack of backwards-compatibility, but only a few of us work on Channels and we don't really have a lot of spare time, and people were already starting to move over to Channels 2 even before it was out.
Will Channels merge into Django core sometime? Maybe, but that depends on how things evolve both within Django and outside. Will ASGI finally be something that becomes a spiritual successor to WSGI? Not without work, agreement and compromise, but I have all those to offer.
Will I have a nice rest and finally stop worrying about the mistakes I made in Channels 1? Absolutely, but I'll remember that people still found it useful, sites run on it, and I learned a lot along the way as well. Thanks to everyone who's helped out and used it so far, and here's hoping many more sites, projects, and exciting adventures are to come.