Quoderat

Explicit state

First, a continuation preserves the entire state of a program, including the stack, instruction counter, local variables, etc. How much of that do you really need for a hypothetical travel web app? In reality, you probably need, maybe, 1-5 variable values to restore a previous state in the travel app, so why not just save those explicitly? It would be faster, more secure (less information being saved), and much easier to performance tune and debug (since no magic is happening behind the scenes). Save those variables in a database, in a hash table, in an XML or CSV file, in memcached, or wherever happens to be most convenient. You may be looking at under 100 bytes for each saved state, so if you really want to do this, it’s not going to hurt too badly.

REST

But do you really want to do this? Most of the discussion around REST has focussed on the use of persistent URLs and how to use HTTP verbs like GET, POST, PUT, and DELETE, but there’s another, perhaps more critical idea behind REST — that the resource your retrieve (a web page, XML document, or what-have-you) contains its own transition information.

Let’s say that you load a web page into your browser, load more web pages, then use the back button to return to the original one. Now, select a link. What happens? Did you browser have to go back to the original web server, which was using continuations (or other kinds of saved state) to keep track of the links from every page you visited, so that it won’t send you to the wrong one? Of course not. The web page that you originally downloaded already included a list of all its transitions (links), and intuitive things just happen naturally when you hit the back button.

The web is stateless, but web application toolkits maintain pseudo-sessions (using cookies, URL rewriting, or what-have-you) that makes them look stateful, and that makes programmers lazy. Obviously, you don’t want to stick information like ‘isauthenticated’ on a web page, since it could be forged; likewise, you don’t want to put a credit-card number there. But it is trivially simple to make sure that forms, like links, go to the right place even when you hit the back button — just make the transitions fully independent of any session stored on the server side. For example, consider this:

<form method="post" action="/actions/book-trip">
  <button>Book this trip!</button>
</form>

Presumably, the trip the person was looking at is stored somewhere in a session variable on the browser. DON’T DO THIS! As Gilad pointed out, someone hitting the back button might end up booking the wrong trip. There are gazillions of ways to push all of the context-sensitive stuff into the web page itself, where it belongs. Here’s one example:

<form method="post" action="/actions/book-trip">
  <label>Book your economy trip to Alaska!</label>
  <input type="hidden" name="destination" value="alaska"/>
  <input type="hidden" name="package" value="economy"/>
  <button>Book it.</button>
</form>

Here’s another:

<form method="post" action="/actions/book-trip/alaska/economy">
  <label>Book your economy trip to Alaska!</label>
  <button>Book it.</button>
</form>

This is 100% backbutton-proof and it’s trivially simple to implement. It took me a while after reading Gilad’s (admittedly, strawman) example to realize that there are people who do not develop webapps this way. If they do this much damage just with a Session stack, how much pain will they be able to cause with continuations?

The REST people are right, at least on this point: there’s no need to drive a continuation bulldozer through your webapp, when a little REST garden spade will work quite nicely (and won’t tear up your lawn in the process). Don suggests that there may be other, more legitimate use cases for continuations outside of web applications, and I have no reason to disagree, but I would like to look at them pretty carefully.

Omissions

There are a couple of problems with giving thanks to inventors, though. The first is that you inevitably leave people out. David, for example, thanked Microsoft for all of AJAX and modern web development in general. AJAX doesn’t consist solely of XMLHttpRequest, however; it also needs JavaScript and a DOM (both pioneered by Netscape) to manipulate the client display, and something like XML (W3C) or JSON (Douglas Crockford) to encode the messages. Most modern web developers also want CSS (Håkon Wium Lie and Bert Bos). And then, of course, there’s HTML and HTTP (Tim Berners-Lee). To illustrate my point, I’ve certainly left out a lot more that I could have included here, and have likely misassigned at least some credit.

Death of the inventor

The second problem is that it almost never makes sense to assign credit to individual people or companies. Who should get credit for SAX? Me, because I coordinated it? James Clark, because I based many of the ideas on his earlier SGML interfaces (and he suggested many of SAX’s features)? Tim Bray, because he thought up a catchy name? The other dozens of other xml-dev members who contributed most of the core ideas? The major software vendors who actually decided to use SAX, giving it credibility outside of the xml-dev community?

The same applies to just about every other technology we use. Not only do they depend on other innovations (the Web without TCP/IP? SAX without XML?), but the successful innovations are almost always simple and obvious, so their main value comes not from any particular technical brilliance but from the brute-force fact that lots of people use them — in other words, community-building is more important than innovation. Microsoft imitated Netscape’s level-0 DOM, and then the W3C standardized it so that it would work across browsers, then browser developers agreed to follow along, then web developers decided it was safe to start using it. Microsoft initially failed to build a community for XMLHttpRequest (which was a proprietary ActiveX component), so it languished mostly unused for years, until other browsers like Mozilla/Firefox, Safari, and Opera decided to support it as well — it was only then that we started to see a real community grow, and high-profile sites like Gmail and Google Maps take off. Tim Berners-Lee’s original HTML would hardly have mattered if the early Mosaic browser hadn’t shown how to make it user-friendly. Etc., etc. While Netscape introduced some good ideas like the DOM and Javascript, they also introduced some that flopped (does anyone else remember CORBA in the browser?) — no community of users, no success.

Thank the users

The moral of the story is that technology success is not something that a person or company gives to the net, but something that comes back from it, as if you threw a stone at a tree without knowing whether an avalanche of silver or of bird dung would shower down from the branches onto your head. A complex, brilliant idea with no users is worthless; a simple, mediocre idea with lots of users is a treasure.

One environment

On the simplest level, you could develop directly in your ISP account, loading and saving files remotely via SFTP, WebDav, etc. — in other words, your development and production environment would be the same. For anything non-trivial, that’s a pretty hairy way to work, since you have no way to test changes before they’re rolled out into the world.

Two environments

I normally use the two-environment approach that (I suspect) is the most common one for single-developer LAMP sites: I maintain a development environment on my notebook, and periodically upload changes to the production environment at the ISP. I try to run roughly the same version of Apache, PHP, MySQL, etc. as my ISP, but otherwise, I take no special steps to replicate the production environment. On my notebook, I set up the development directory as its own virtual host (e.g. http://localhost:8001/, etc.) so that I can test changes literally as I type.

Three environments?

Even though there are no other developers working with me right now, I sometimes wonder if it would make sense to start using a third environment between development and production (a separate directory and virtual host on my notebook). A third development would allow me to run major experiments and restructuring in the development code, while still making small bug fixes, typo corrections, etc. in the stable code before uploading them to my ISP production environment.

While this sounds like a good idea initially, there is a major coordination problem involved in backporting fixes from the middle environment to the development environment, and the middle environment will still become unstable while new changes are rolled out into it, tempting me to create another environment — complexity is, sadly, highly contagious. Have any other lone developers had success (or failure) with this approach?

More

Big organizations use an enormous number of environments to build and roll-out a system:

• Each developer’s desktop, where code generally lives for a few hours.
• The development server, typically a single server running database, application server, etc. as well as version control unit/regression tests.
• One or more test environments, covering integration testing, system testing, user-acceptance testing, etc. (these can range from single servers to small clusters to near-duplicates of the full production environment).
• The staging environment, which is typically very similar or identical to the production environment.
• The production environment, where the system runs.

I’m still undecided about whether enterprises help or hurt themselves by making things so complicated — coordinating a lot of people on a big system is hard, it’s even harder to imagine an agile process functioning under so many layers of pain.