在史前的web开发时代(我说的是AngularJS工程师开始变得价值不菲之前的黑暗岁月),web开发的一个痛点在于HTTP是一个无状态的协议,浏览器是一个无状态的展示表单提交工具。当然现在的web开发世界已经不再是如此了,浏览器已经俨然是一个全功能的客户端了,B/S和C/S架构的差异已经接近弥合。在那个年代,有一些人就想,让状态从服务器传到浏览器,然后再在浏览器提交表单的时候传回来这多麻烦呀。如果能够让服务器保存表单状态,代码写起来该多么酷啊,比如下面这个例子(Stackless Python Nagare):

class Counter(object):

    def __init__(self):
        self.val = 0

    def increase(self):
        self.val += 1

    def decrease(self):
        self.val -= 1

@presentation.render_for(Counter)
def render(counter, h, *args):
    h << h.div(\'Value: \', counter.val)

    h << h.a(\'++\').action(counter.increase)
    h << \'|\'
    h << h.a(\'--\').action(counter.decrease)

    return h.root

这段代码实现的功能是在浏览器上显示一个“0”,然后有++和–两个链接。点++的话会提交一个HTTP请求给服务器,服务器返回一个新页面,其上面显示一个“1”。
背后的思想是把页面上的内容建模为一个状态,在代码中这个状态就是那个counter对象。counter对象的值是以协程的方式保存在服务器端的。不仅仅是counter的值,以及h.a(\’++\’).action(counter.increase)这样绑定的事件与回调函数的映射也被保存了下来了。客户端的操作通过HTTP发到服务器之后。服务器根据渲染页面时注入的一些id表示符,找到对应的协程,然后加载协程,再把协程往后执行一步,同时渲染出一个新的HTML页面,返回给客户端。类似的想法最出名的框架是smalltalk的seaside。
假设我们是服务器,当我们把页面发给客户端之后,等待客户端的返回,然后根据返回执行后面的事情。类似这样

page1 = initial_render()
send_to_browser(page1)
resp = wait_for_browser_response()
page2 = do_something(resp)
send_to_browser(page2)

中间wait_for_browser_response()就是一个大大的流程阻塞,当然为什么不能用协程去对这个流程阻塞问题进行建模呢。于是乎就有这些诡异的实现了。