This makes so much sense (http based programming, not continuation based).

I have build high-performance sites, where it was super easy to customize or add new functionality. With continuation (event driven and server state driven), the whole web site acts like a single desktop application. The beauty of http driven model was that the interface between components was very limited (form or url variables). People had to think hard and had to write clear requirements of the component. e.g. A product display component would take product number or product as part of parameters and then display the product. Now with event based programmnig the event first hits the page that renders the button/link for that event, who must know how to call the component. With http based method, you only worry about the url/form-action and the parameters. Hetrogeneous systems can integrate very easily with this simple method, instead of depending on next action handler being callable on the server side.

With event/state driven programming, basic browser functionality stops working. Back buttons doesn't work, bookmarking doesn't work. You end up coding back button on all the pages manually and disabling the broser back button. It really gets ugly.

If you learnt UI programming first, before web programming. The frame of mind is already set on event/state based programming. It's a bad thing in my opinion. HTTP parameter based programming is much more scalable (linear scaling) and interoperable.

My 2 cents. Prashant Rane http://www.jroller.com/page/prane