I'd argue that python needs an async django, which will hopefully be django in a few releases.
Combined with aiohttp-json-rpc I had a very effective websocket-based JSON RPC backend service up and running in a very short time and with very little boilerplate. I'll be using this pattern again for sure.
What would have been the advantage of me using Sanic instead (I haven't RTFM for sanic yet but I'm about to...)?
Sanic also makes performance a key development goal so you can feel comfortable the project will scale gracefully. But I will stress I don't have current benchmarks to compare against aiohttp
With aiohttp you can make neat things it is operating a level below Sanic - in my experience people end up writing their own half-baked undocumented framework based on a combination of aiohttp, some ORM and a template engine - sometimes with half a dozen combinations in the same company.
This is how we get to async Django, and I think that's part of why Tom Christie is helping out. I also doubt Reitz thinks this is the usurper of Django anyway. It's more than an experiment, but less than "the new One True Way".
As for ASGI python web frameworks, there are no mature winners in the space yet (compare uvicorn's quickstart example to this project's before you throw that project out as an example). This is Truly New Shit, and I'm pumped these two devs are working on it together.
From what I understand ASGI was developed by Andrew Godwin for Django Channels.
But just thinking about my own experiences, being able to look at what other people have done so far with it would help immensely when building the nuts and the bolts of the feature. This project will help immensely with that.
For example, I'd like to see Python's async frameworks building on ASGI middleware rather than all re-writing their own middleware APIs. That way we end up with lots of cross-framework compatible middleware implementations, and we're all working together much more coherently.
Similarly for test clients. We don't really need frameworks to all be building their own individual test clients to interact against their own interfaces, when we can instead build test clients to interface against ASGI, and then be able to use them against any ASGI framework.
That's part of what the Starlette project (which Responder uses) is all about: https://www.starlette.io/
(FWIW Starlette also composes all those bits and pieces into a framework in its own right)
It seems that Tornado is now offering the choice of its own event loop or the asyncio event loop. I built something recently in aiohttp because it felt like it had been built on asyncio from the ground up but will explore Tornado again.
By django like I meant a batteries included framework with an integrated async ORM, auth, DRF and etc. From what I've seen we'll probably have to wait for django to get there, which might take a few years.