Flapjax Development Blog

Flapjax in Denmark

2007-09-18T20:27:00.000-04:00

Shriram will be speaking about Flapjax at three venues in Denmark:

The JAOO Conference, 2007-09-24
University of Aarhus, Pi-Lambda Seminar, 2007-09-25
DIKU/ITU/Roskilde, Copenhagen Programming Language Seminar, 2007-09-27

Flapjax in India

2007-09-06T10:36:00.000-04:00

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.

Lifting Tutorial

2007-08-16T10:31:00.000-04:00

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.

Commercial Feedback (Suppressed)

2007-08-02T22:05:00.000-04:00

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!

Data Flowing Down Telegraph Avenue

2007-05-09T15:03:00.000-04:00

Flapjax is the inspiration for a very elegant project in the compilers course at Berkeley.

Tierless Tieranny

2007-02-10T11:32:00.000-05:00

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.

Presentations

2007-02-10T11:28:00.000-05:00

Shriram will present Flapjax on Friday, February 16 at Tübingen and at Darmstadt on Friday, February 23.

Presentation

2006-11-13T18:03:00.000-05:00

Shriram will present Flapjax at the LFCS Lab Lunch on Tuesday, November 14, 2006.

Meet Us!

2006-10-30T23:34:00.000-05:00

Want to talk to a developer of Flapjax? Want us to stop by and explain what it's all about? Meet us on the road! Shriram will be in several places in the coming months, and would be happy to stop by and give you the lowdown. Precise dates are on his calendar. Roughly: in Nov 06 he's in Edinburgh, UK, and can make it to most places in the UK. In early Dec 06, he's in Oxford, UK, Lausanne, Switzerland, and Paris, France. Most of the rest of Dec 06 he's in Bangalore, India. In Jan 07 he'll be in Australia, including a week in Sydney. He will be traveling a lot during the spring of 07, including Germany, Portugal, and a few universities in the US.

Application Manager Update

2006-10-23T22:01:00.000-04:00

I have added compiler support and a measure of documentation to the Application Manager. I invite users to try it out.

You need to log in in order to create, upload, and publish applications.

Discussion List

2006-10-22T10:58:00.000-04:00

Your wish is our command. We now have a discussion list.

We may not have the config options quite the way you'd want them, so show a little love. Do tell us if you see problems.

It may be a bit confusing to have both a blog and a discussion list. I think the blog is a better medium for posting updates and status information, while the discussion list is better for code minutiae. We'll figure this out as we go along. Advice always welcome.

Streaming Data

2006-10-21T16:17:00.000-04:00

In an earlier comment, Julian Morrison suggested creating a server-side protocol. I agreed but said we need to do more work before we can publish something reasonable. I also pointed to an interesting bit of ongoing work, namely Opera's event streaming API, which Kim Burchett brought to our attention. I felt it was worth hoisting this from the comment section because I wanted to point out that APIs like this play directly to Flapjax's strength. Of course you can program against an API like this using callbacks (which would be implementing upcalls), but it'd be so much nicer to just bind to the data stream and let the language do the work—which, of course, is just what Flapjax would let you do.

For now we haven't built a binder to the Opera interface for three reasons: (1) we're not aware of much server-side support for it yet, (2) it doesn't appear to be a client-side standard either, and (3) there are some questions about its definition (as usual, Kim gets past the superficial and asks the relevant questions: see her message on the Opera site linked above). But the Internet is definitely moving in the direction of higher-level data abstractions, and we think Flapjax is well-suited to them.

Networked Persistence

2006-10-21T15:57:00.000-04:00

In a comment, Neel Krishnaswami asked us to discuss networked persistence. Here are some preliminary thoughts on this.

The most important thing about persistence in any context is that it should fit naturally with the language. This means lots of things: internal-external data interchange; persistent storage identification and management; hooking up to the language's control model; and more. For now I'll discuss these three points. Notice that the questions themselves aren't really about networked persistence, but the network will show up in each of the answers.

Data interchange on the Internet naturally demands an “XML story”, and lots of language research is trying to wrestle with this. If you step outside research and spend some time in blog-space or studying Web service APIs, you see a very interesting trend: the growing acceptance and even promotion of JSON. Because JSON obviously integrates nicely into JavaScript, and its support is increasing, we're ducking the XML question entirely for now. In fact, our Web services API automatically converts XML data into JSON for your convenience.

What is persistent storage? On a local system, computer scientists find it useful to categorize at least three different kinds of storage: the database, the persistent heap, and the filesystem. (And that's arguably just a 1970s view of systems.) We can distinguish between these along several dimensions: the object model, the power of query, the style of naming, the interaction with processes, etc. In Flapjax, though, many of these dimensions lose their relevance for two important reasons. First, we don't have (and don't want) a true distributed operating system, so the “process” boundary dies at the network interface (with end-to-end services taking its place). Second, network latency greatly distorts the cost models. So some unification of these concepts may be possible. For now, Flapjax gives each user a “home object”; their data are held by fields. From the program's viewpoint it's just a persistent object, but the user can think of fields as a pun for subdirectories, and use the object-browser like a file-browser. What we definitely don't have is a story on search, aggregation, and other functions you get from SQL. We have various thoughts on this, ranging from leveraging XPath to letting users define schemas, but (indeed, therefore!) this is very much an open question.

The control front is somewhat obvious: because Flapjax computations are time-varying, changes must naturally be pushed to the server, and server changes must naturally trigger renewed computation on the client. Defining this crisply has proven to be somewhat tricky. One issue is handling aggregate data, which Michael Greenberg is studying from first principles. The other is how to deal with multiple clients that write simulaneously. Obviously there is already research on this topic, but we do have our hands tied by the lack of server-push, the sheer number of clients that may be accessing a datum, existing APIs, etc. We have our own distributed algorithm that helps with this, but just defining “reasonable” behavior is tricky: if you don't get it right, a client who is sharing a writeable buffer will see the new characters they type disappear before their very eyes.

We need to clean things up a little more before we say much. My reticence isn't in the usual academic “I have a paper coming up and I don't want someone to scoop it or find the flaw in it before it gets in” manner—rather, we really do have more design work to.

And, of course, we welcome feedback and prioritization.

Compiler!

2006-10-19T23:21:00.000-04:00

The downloadable compiler is here! (Well, sort of.) To be precise, the compiler is now available as a web service. You can now download a script which will automatically send your page to our server and return the compiled version. So you can just type: $ fxc -o mypage.html mypage.fx.html and it will do the right thing. Download the script here. (You might need to right-click and say "Save Link As...".) It will work on any computer with Python. A Windows version, which will not require Python, will be available soon.

IE Progress

2006-10-16T20:44:00.000-04:00

As you can see, we've not only been making Flapjax work on IE, we've also been testing the demos and gradually adding the IE icon where we're pretty confident. Of course this is JavaScript-and-browser land, a minefield of incompatibility...but IE support is definitely looking up.

Downloadable Compiler

2006-10-13T21:18:00.000-04:00

Some of you have asked for a downloadable compiler. We didn't expect the demand for it so soon, but we're working on a solution to this problem. Please expect something within the next few days. We'll announce it here on the blog.

IE Problems

2006-10-13T17:49:00.000-04:00

We're aware that there are problems using Flapjax in IE. We're working on them right now and will have fixes out soon. Indeed, even as you look some of the demos should be working.

Welcome to Flapjax!

2006-10-06T08:04:00.000-04:00

This is the notification site for developments about Flapjax, our new language for developing Web applications. Flapjax has six important characteristics:

It is event-driven and reactive.
It reduces unnecessary code with an in-lined template system.
It provides a reactive, persistent store that automatically updates on all clients sharing the same data.
It enables convenient sharing of data with other users.
It implements access-control to channel this sharing.
It provides libraries to connect to external Web services (thereby enabling client-side mash-ups).

Flapjax is built entirely atop (and is syntactically identical to) JavaScript, and can thus run on traditional Web browsers without the the need for plug-ins or other downloads.

Shriram, for the Flapjax Team