Free Idea: AJAX Desktop Publishing App

If you're hankering to join the web startup circus and have everything but an idea, here's one for you: a full-on desktop publishing app ... online. The ready acquisition market for decent online productivity apps can serve as inspiration, even as the insane complexity of the undertaking urges you on toward greater heights of caffeination and maybe some anti-depressants.

Seriously, apps that can deal with complex page layouts and can produce a variety of press-ready output (InDesign, QuarkXPress) are expensive and hard to learn, and the average person rarely needs them. It would be nice to be able to hop on a web page and do a quick design. Wizards or integrated help could go a long way. All the usual business models (adds, freemium, pay-per-storage, etc.) apply.

Now, if you build this in Flash/Flex or in Silverlight (2.0), you merely have a ton of work ahead of you. While challenging, you may feel like you're not ... well ... proving just how wicked you really are, since those two platforms give you all of the technical infrastructure you need.

So why not go all the way? Do it in JavaScript, in the browser. Yep, WYSIWYG, arbitrary page sizes and layouts, in the browser. Advanced typography too. Fun times.

Here's a hint: one of the tricky bits is measuring text line layouts, since you'll need to make sure that the view matches the backing data (from which you will be generating other "views" or output formats).

JavaScript (the browser APIs really) don't give you everything you'd like. For example, one standard thing you need is to find out how many characters will lay out into a column of a particular width. Or simply what size a run of text will turn out to be.

While you can't ask these things directly, the clientHeight DOM element property can be useful: it shows the actual height that a DIV's content will lay out at ... so it will also signal when content has flowed from one line into a second line. By hiding the DIV, rigging up a while loop, and monkeying with the content (string), you can build a routine that measures text, so that you know exactly which characters are going to appear on a line.

Completing the application is left as a (possibly lucrative) exercise for the reader.

Quick Poke: Look at MS Live Labs' Volta

If you haven't seen Microsoft's Volta project, it's worth a look.

Volta is about two big things:

(1) Blurring the lines between applications tiers to allow declarative or even automated tier-splitting (yes, there are lots of issues with this, but the MS team insists it's aware of the historical legacy of the distributed computing "leaky abstraction" and won't muck things up by pretending it's not an issue).

(2) Automagic cross-compilation between, say, .Net IL and JavaScript.

Whoa, what's that last bit?!

After the initial flurry of press coverage, the team insists that running arbitrary .Net IL on any old JavaScript-capable browser is no big deal, just a convenient demo, don't focus on that part... But, seriously folks, a couple of months on since the project was made available to the general public, the tier splitting is looking less and less interesting, and the cross-compilation is looking more and more interesting.

Once upon a time, crazy people did crazy JavaScript stunts. Like this demo that emulates the hardware of an entire 80s-era game system complete with game, or this similar 6502-based emulator.

Emulating a modern VM like the JVM or CLR is not practical from a performance point of view. But JavaScript runtime as a compilation target is becoming increasingly popular: first we had GWT and Script#, which compiled Java and C# respectively to JS. But because they only compiled your code supplied minimal bits of the respective class libraries (Java API/.Net BCL), their use was restricted.

So here's a wicked end run around that: take anything that compiles to IL -- or any IL binary! -- and run it in a browser. According to the Volta team, it has been done in such a way that all of the object semantics from the original language are preserved. Unless they also port the Win32 API to JavaScript, it's not like we're going to see WinForms apps running on Safari. But this is being positioned as a fallback for, say, places where Silverlight isn't installed.

Go here and look at the demos. The perf is awful -- but that's not the point of the demos. So far as I can tell, this is the first commercial implementation of what we all kind of knew might be coming.

Commoditization of Social Networks is Just the Beginning

On Monday, Om wrote about the commoditization of social networks. A couple of days earlier, dojo added a nice section to its docs comparing AJAX frameworks ("Why Dojo?").

What do these things have in common? Only that they reminded my of a couple of other technologies...

Remember "portals"? A portal was how to make your site sticky, customizable, get users to spend lots of time there, view lots of ads make you lots of money. Maybe they would even set it as their homepage! A few companies made big money as purpose-built portals. Then there were content-management sites where every group of accounts shared a portal that they could customize themselves -- using the site itself! How amazingly meta! And then came open source portal and CMS products and finally the sign that portal magic had surely jumped the shark, a JSR for portal components. Ok, portlets, I said it.

That first part was fun though ... sounds a lot like social networking sites. Groups of users. Widgets. Social. Sticky. Ad views. Customizable. And as Om points out discussing Ning, you can roll your own right online. The next step is code I can download and run locally, or that godaddy.com sells me with my domain name registration. Like CMSs, storefronts, and shopping carts, the basic software form of a social networking site is stabilizing (stabilized?). Freshmeat lists nearly a dozen social networking apps/projects in varying states of maturity.

I'm not criticizing these sites; quite the opposite -- I'm suggesting that their success will be so complete as to make them just another page in another site. Eventually one ASP.net template or Rails script will import all the social networking features you could want.

AJAX frameworks and libraries remind me of application servers:

• When the CGI was the baseline, app servers let the innovators stand out with more sophisticated interactivity and customization.
• When full-page GET/POST was the baseline, AJAX toolkits let the innovators stand out with more sophisticated interactivity and customization.

I'm not trivializing app servers. Standardization was a boon, and the decision of which to use had long-term consequences. Painful ones, if the decision was taken incorrectly.

Eventually, though, in part thanks for Moore's Law, commodity hardware, open source software, and the nuclear winter, it became no big deal. They all work. More or less fine. Some are better than others for certain things, but no one's gonna waste time arguing that PHP or IIS/ASP.net is "just no good," and (non-technical) business concerns or the right talent often makes the case for one or the other today.

Aside from their being interesting in themselves, these comparisons are meant to put some perspective on where we are in the technology cycle. We're getting past the "hey wow" part of AJAX, widgets, and social networking features. Commoditization comes, standards emerge, infrastructure value-add declines.

These bits become the new top layer of the stack, and we should be thinking about the apps that we will build to ride atop them.

"Offline is Here" ... and Credible (!)

I spent a few minutes chatting with Brad Neuberg yesterday, following up on his presentation at Google Developer Day on Thursday. We spoke about offline data persistence for web apps, and the rapid crystallization of industry players around a particular approach.

"Offline is here," he said. Two weeks ago, that would have been just one opinion of one prominent person working in the space. Fast forward to June 1, and half the industry seems to have decided that now is the time, and that a specific SQL flavor of offline storage is the right one.

Why two weeks ago, not one week ago? Because when I asked about Firefox 3 (which has been promising an offline facility), Brad pointed me toward this change to the XHTML5 spec at the WHATWG, submitted on May 23. Here's a more readable and faster-loading spec draft section on local SQL storage (but content might change, as the doc develops). Firefox 3 aims toward this spec, and the spec API looks remarkably similar to what Google Gears offers.

So we have Dojo, Apollo, and Firefox essentially promising the same relational, origin-domain-partitioned storage metaphor along with similar APIs. Google brings plugin implementation code targeting all major browsers. For someone like me, who gets paid to make bets on the (near-term) future in order to architect applications, that's awfully persuasive.

In some ways, this is another iteration of the "dumb terminal + remote computing" vs. "smart terminal + dumb network services" oscillation... but it seems like we're maybe getting critical damping now.

Microsoft articulated a sensible "Smart Client" architecture around eight years ago: deliver apps that leverage services in the cloud but can also run offline. They should sync when online, while leveraging local hardware for performance and to maintain state. I'm using a quintessential smart client right now as I type.

The only easy way to implement that architecture and get the full benefit of local resources though was to build a .net application. Then Win XP shipped without .net; zero-click install had issues, one-click install was too late, and the rest is history.

We got AJAX and Web 2.0 instead of a lot of smart clients, which wasn't a bad trade.

I'm pretty psyched now though, because it looks we're going to get to have both.

dojo.offline = apollo.db = google.gears

You know those scenes in political thrillers when a character starts spilling the beans about what's really going on? And as the real plot takes shape in your mind you start thinking about the consequences: "That means the old guy is working for them ... and the girl is going to get killed if ... wait, she must've done all that stuff on purpose, which means..." You get the idea.

Well I had one of those experiences tonight at the final Google Developer Day session, where it turns out dojo has elected to scrap their own infrastructure for offline AJAX app operation, which had been in development a long time and had just reached beta. In the runup to Dev Day, Brad was treading lightly. But what he just told us is that the dojo plugin is dead. The dojo offline high-level Javascript library will run on top of the Google Gears offline app plugin. Incidentally, Google helped pay for porting the dojo offline library.

Early in the day, when Gears was introduced at the keynote, we learned that Gears would interoperate with Adobe Apollo. This post has details.

Ok, who's left standing here?

True, "interoperation with Apollo" isn't the same as "being Apollo" (Apollo has access to the filesystem, up to the perms that the current user has). But dojo was clearly the frontrunner in offline AJAX, and has held a hegemony in vector graphics and other wicked scripty stuff.

So to keep the metaphor, I see a surprise coup d'etat. And not necessarily a bad one, either. I want to see how this one ends.

Interaction Sequence Diagram for Google Web Toolkit

I've been doing some work with Google Web Toolkit. GWT is based on a cool model where the client-side and server-side code are both written in Java. The client-side code follows certain API guidelines which allow it to be compiled to optimized Javascript by GWT. Among the APIs that can be used is a pattern for asynchronous remoting, so that AJAX calls can be made and received in Java, with Java objects as arguments and return values (a bit like RMI). The marshaling and unmarshling, JSONizing and the like is done automagically. Nikhil Kothari has a similar technology on the .net side that lets you code client-side Javascript via C#. It is called Script#.

This model has a number of major strengths. But one weakness is that is not common, so it is not immediately familiar to developers. The interaction pattern can seem a little mysterious even with Google's doc set, debugging tools, etc. It gets more interesting when you consider that you might also be generating the original pages (the ones with AJAX interactions on them) via Java. (GWT does not require a dynamic page generation scheme at all, and can use static HTML.) In order to make this clearer, I wrote a sequence diagram which I'm posting because it may be valuable to other developers getting their heads around GWT.

The diagram shows three interactions. First, I'm generating my initial pages using the FreeMarker templating system. There are lots of other ways (like JSP for example). But here I'm using FreeMarker. This all takes place before GWT gets involved in the pages.

Next, I show how the GWT scripting gets running and loads the page specific code which will rewrite the DOM. At the end of this, the page is rendered the way the user will see it in the browser.

Last, I show how an AJAX interaction flows, including a call to an external web service on the back end -- e.g., if there is a "Load My Favorites" button on the page that results in a call to an external service and asynchronously returns with data to bind into the DOM.

I hope it's helpful. If I've left anything key out, let me know.

Click to enlarge / view: