Exactly. If you build an async project, but do the same things than WSGI frameworks we gain nothing. We already have perfectly capable and productive frameworks. We use them everyday, we make money with it. They work.

Async allows to maintain low latency permanent connections between each clients, being it a web page, a task queue, a server worker, etc. We finally can have it all connected. We can broadcast setting changes, propagate cache invalidation, push action notifications, update task completions to subscribers, allow everybody to react to stuff on the file system or the db instead of polling, all in soft real time.

The potential is amazing.

We all can do HTTP req / resp. The question now is: how good the tooling around this cycle is.

You may have already seen this but uWSGI allows you operate with asyncio too.

http://uwsgi-docs.readthedocs.io/en/latest/asyncio.html

Your point ?

Sorry, it was a vague attempt to foster discussion about the options of moving out of WSGI without throwing it out completely (I was really ill yesterday and couldn't quite formulate any logic thoughts around it myself).

Have you looked at the options there / if there would be an easy way to bolt on a more async driven framework? Obviously, it doesn't solve the missing framework issue, but maybe there's some clever tricks you can do because uwsgi is allowing you to bend the rules.

This project too is a solution built on WSGI like Bottle and others. I agree plain WSGI is too restrictive and tedious to work with. So I don't understand how the parent comment's concerns about WSGI applies to this project but not to other WSGI-based frameworks.

There are already good solutions for WSGI. There are less for non-WSGI async options. The parents point is that if you now create something new, yet another WSGI solution doesn't add much to the general ecosystem, where a new async thing very well might.

That makes sense. Thanks for explaining.