2007/09/06

Flapjax in India

Shriram will be giving two presentations on Flapjax in India, both in
the context of larger education- and research-related events. The
first will be on Monday, December 17, at the Technopark in Trivandrum,
hosted by IIITM-K. The second will be on Saturday, December 22,
somewhere in Bangalore.

2007/08/16

Lifting Tutorial

While not a material development for Flapjax, this tutorial on lifting explores some of the internals of Flapjax: how events and behaviors are implemented, and how plain old JavaScript can operate on Flapjax data structures. It should be accessible to readers familiar with the language, no crazy academic credentials required.

2007/08/02

Commercial Feedback (Suppressed)

The folks at untyped have written a research conference paper about their experiences building a commercial Web application. Unfortunately the page limit forced them to excise their feedback about Flapjax. Their blog post has a bit of both positive and negative feedback about Flapjax. We hope to work with them to fix the problems so they'll have a more positive report in the future!

2007/05/09

Data Flowing Down Telegraph Avenue

2007/02/10

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.