问题是：为什么延续（在 Ruby 中）和协程（在 Python 中）没有更广泛地用于 Web 编程？
保存请求之间的状态问题使服务器端 Web 编程变得困难。两个优雅且相关的解决方案是延续（如在 Scheme、Ruby 和 Smalltalk 中发现的）和协程（如在 Python 和 Go 中发现的）。
Bruce Tate 在他的Beyond Java（O'Reilly，2005 年）中谈到 Ruby on Rails 和Seaside是 Web 编程中令人兴奋的新发展。对我来说，Seaside是真正的突破：使用 Smalltalk 延续，Seaside 使得编写复杂的请求/响应序列变得非常容易。
我知道在 Tornado 和 Twisted 中使用 Python 协程来减少回调，但这有点低级，例如，与在单个协程中编写视图/控制器来处理一系列 HTTP 请求以完成在线购买相比。
我想知道为什么这些在纸上看起来很好的想法在 Python 和 Ruby 中没有得到更广泛的部署。仅仅是文化问题吗？以这些语言实现的设施的限制？或者这些方法在 Web 开发环境中是否存在根本缺陷？
我使用过 Seaside，而 continuations 是开发客户端服务器 webapps 的一个很好的模型。它们简化了传统的客户端/服务器应用程序，我无法相信为什么没有其他语言这样做。
但不幸的是，webapps 已经不是过去的样子了。现在使用 ajax 在不同时间有多个请求，而不是只请求一页。这就是为什么延续不像过去那样有用。
甚至 Avi Bryant（Seaside 的原作者）也说过，在 ajax 下使回调更容易（事件驱动编程）比延续更重要。
看看这个quora讨论了解更多： http ://www.quora.com/Whats-the-best-continuation-based-web-framework
主要是因为非技术原因。知道Seaside 甚至Smalltalk 的人很少，所以没有大量的廉价程序员可以雇佣。因此，知道如何安装和维护 Seaside 系统的服务提供商数量也很少。
您的应用程序应该在 continuation/coroutines 框架以及支持库上编写。对于初学者来说，这不是简单的模型。还有更简单的框架，例如 gevent，它提供了相同的创建绿色线程的可能性，并且由于猴子补丁而更易于使用。