[etchalon]

Play doesn't belong in that list (it's really just a Java-version of the basic request/response cycle design that plagues Django and Rails, Scala or not).

Django is sadly hampered by two fairly complex problems. The first, is their insistence on backwards compatibility and stability. While it's becoming obvious that the basic design of Django creates serious problems when moving away from the request/response cycle, it's a very hard problem to fix if you can't fundamentally change core assumptions within the framework. Second, Python 3 (sans Tulip) just isn't up to snuff for asynchronous coding. Twisted is a mess, Tornado is far too simple.

The Rails team seems more willing to break with the past between releases, but its still hampered by Ruby's inherent performance disadvantages.

Ultimately, while none of these frameworks are disappearing any time soon, it'd be fair to say that many engineers, particularly those working at the edge of the industry, are choosing things like Node, or Go.

[TylerE]

How exactly do you write a web app that doesn't process requests and return a response?

[etchalon]

It's less that requests don't return a response than that a request and response is not assumed to be a clean transaction.

[TylerE]

That doesn't make any sense. Can you give some examples?

[playing_colours]

I cannot imagine web frameworks working beyond request/response. About Play - I believe it's trying to go further than Django/Rails. It is powered by Netty, Akka, has async response support, plus Scala FP features. There's also promising ReactiveMongo driver. All these put it at least half way closer to shiny async future. I worked with Node.js too and for me it's more pleasure to write async code in Scala.

[UK-AL]

Most the frameworks that abstracted request/response away, are now moving towards it. ASP.NET --> ASP.NET MVC for example.

[etchalon]

While my ASP.NET knowledge isn't deep (I've only ever modified existing code), it seemed like the request/response cycle wasn't abstracted away so much as HTTP was.

[UK-AL]

The whole the thing maintained state between views, so it was more like placing controls, on a view and then having events linked to controls. Rather than requesting, then responding with html.

[japhyr]

Do you have any perspective on how Flask fits into this?

[etchalon]

Flask suffers from the same basic problem, though slightly less so because it has fewer core principles that would break if the response/request cycle were removed or augmented by a consistent connection assumption.