Tierless Tieranny

There's a new buzzword sweeping through Web programming circles: tierless languages. These are languages that help nullify the traditional three-tier architecture from the perspective of a programmer. So far, so good (to some extent, anyway). What baffled me was that I was recently at a meeting about Web programming and Web services, at which Web programming languages were classified into two kinds—tiered and tierless—and Flapjax was put into the former category.

Allow me to strenuously object.

It helps to draw some simple pictures. First, there's the tiered world:

In a tierless world, you write a single program, in which you can annotate some parts of the code as running on the client. As for the database part, you effectively program in a stylized supersubset [sic] of the language, which an optimizer knows to translate to efficient SQL. The picture for the tierless world is either the same, or just one big blob (technically, it's a blob that unfolds into the tiered picture).

Of course, this is all wonderful if you have control over the server and the client, or if your client wants to talk to one server only. As soon as it tries to gather data from multiple servers—as in a mashup—you lose this level of control, because you can't approach Google and ask, “Would you please rewrite your module in my new programming language?” (Well, you can ask, but you can also guess their answer.) At that point, the notion of tierlessness ceases to make sense, because you can't meaningfully control the world.

So where does Flapjax sit? We do provide one for data storage, but that should really be thought of as a special case: a lightweight specialization of the general Web service API. In general, we emphasize speaking to multiple servers and provide language and library support for doing so.

There is an intermediate world, represented by Hop:

In the Hop model, the broker lets you get around current JavaScript restrictions by making the broker the single agent who can talk to multiple sites.

We thought for a while about whether we should adopt the Hop broker model, but ultimately rejected it. Here's why. Where should the broker run? Running it on the client is attractive in that the client can then, for instance, serve up local files; but I'm not going to be able to run the client when I'm in an Internet cafe. So perhaps it should run on the server; but in that case, it's just another server, and the fact that it speaks to other servers is of no real relevance (since servers have always had the freedom to do that, and exercise that freedom transparently). Furthermore, the security issues that surround circumventing the same-domain restriction are complex, and the broker is not a sufficient solution. Finally, it is nice to be able to communicate with the local host (for files, for instance). But if you have a language already well-tuned to communicating with services, the broker becomes just another service, and does not need a distinguished status. So that's the Flapjax model:

We don't have a name for this model. We should, because names lead to the uptake of ideas. But the problem is, as Michael Greenberg pointed out, this model already has a pretty good name. It's called the Internet.