Palm Mojo SDK 1.1

When the Palm Pre appeared two months ago, the world took one look at the graceful curves and immediately decided there was finally a contender that might stand a chance of attracting some of the crowds clustered around the iPhone. While the Palm Pre's shell may lure some buyers, the software on the inside is just as important. After all, smartphones are just computers for our pockets, and the depth and breadth of software available is a big selling point.

The software at the core of the Pre is even more novel than the design. Palm calls it WebOS because the dominant programming languages are HTML, CSS, and JavaScript, the three syntaxes that power Web sites and browsers. This combo is dramatically simpler to use than old-school languages like Object C, so Palm has lowered the hurdles for any new programmer. If you can build a Web site, you can build a phone app.

To test this out, I built a few phone apps with the Palm Mojo SDK and came away thrilled with the simplicity. The Mojo SDK doesn't have the word "beta" floating around it, even though it's much younger than many other products that still sport the label. I think it would be fair to apply it here. The general outline of the system is solid and usable, but there are numerous rough edges and dark, undocumented corners. These should be easy for Palm to fix with ample time and attention.

Mojo rising

The SDK comes with an emulator, an inspector, a few command-line tools for compiling the code, and some samples. Many people will probably want to get the extensions for Eclipse that hide the command-line complexity and handle the compilation and installation for you. Eclipse is used by most other smartphone manufacturers as well.

The Mojo tools show flashes of genius but often reveal strange glitches. The Inspector would often get disconnected from the Emulator, so I couldn't use it to dig into the structure of the running application. Debugging is an exercise in command-line fun because you ssh into the emulator to look at the processes. I'm hoping for something like Firebug in the future.

The options are coming quickly because of the relative openness of the platform. There are now extensive automatic completion routines for WebOS programming for the Komodo editor from ActiveState Software. I'm sure other tool companies will jump on board.

Page Break

These completion routines can be helpful because the current style of WebOS programming is closer to the endless classic model-view-controller (MVC) paradigm filled with longVariableNamesWithDescriptiveClauses common in Java programming. They still haven't picked up the tight shorthand emerging from worlds like jQuery.

For instance, each page is called a "scene," which, in turn, consists of some HTML listing the widgets and a JavaScript file called an "assistant." The HTML and JavaScript are separated into different directories in proper MVC style. You create the widgets by placing a DIV in the HTML and write some JavaScript code to fill in the DIV with the right widget afterward.

HTML vs. JavaScript

The HTML and the JavaScript are both working with and against each other. In the latter case, the JavaScript usually wins. You can add design details in either the HTML or the JavaScript, but the JavaScript will end up wiping out anything you do with the HTML. In most cases, the HTML is an empty vessel and the JavaScript does all of the work.

This framework is dramatically easier than using something like Objective C. There's no need to deal with memory allocation or pointers, two briar patches that often trap even the best developers. The appearance is specified in the HTML and CSS, languages spoken by graphic designers. The MVC architecture means you can hand the HTML and CSS to the designer and the JavaScript to the developer. When they're done, you can usually mix them together -- with the aforementioned caveat. If your JavaScript creates buttons and widgets, it won't matter much what the Web developer does with all of the DIVs.

It's worth noting that WebOS development will not be simple for everyone who can build a good-looking Web page. You'll need to know JavaScript and be familiar with the idea of creating a layout by instantiating objects, not putting tags in the right order. This is still a job for real programmers, not Web designers.

The WebOS offers a structure that will be easy for any programmer who's been working on AJAX Web applications, but this won't be enough for some. Game developers used to OpenGL on the iPhone and Android won't be able to do much in 3-D. But I think that casual, two-dimensional games will be easy once people get used to the idea that DIVs can roam all over the page in different layers. Look at this version of Tetris for an example. If that's not good enough, Adobe has announced it will deliver a Flash player for WebOS.

Palm has only begun to scratch the potential of a Web-based operating system, and there are many fertile avenues for development. If Palm isn't working on embedding jQuery already, it should start finding a way to borrow ideas from the more active corners of AJAX development. The Mojo documentation notes that the Prototype functions are often available but the $ function won't work across scenes. I'm guessing that the next generation of the libraries will include all of the best ideas from jQuery. Palm would be smart to make it simple to use jQuery plug-ins.

Page Break

I think there will also be some rapid integration with the various widget platforms out there. It would be relatively simple for Palm to create a browser-based IDE that lets people create and test rudimentary apps in their browser. A number of widgets like Google Gadgets come from just these sorts of IDEs.

Just the beginning

The JavaScript is just the beginning. Developers are actively digging into the Linux foundations of the Pre and finding they can build tools that work with the raw guts of the machine. Some are talking about writing Java services underneath.

I asked Palm a number of questions about distribution, its version of the App Store, and other issues, but I got only vague answers that pointed me toward the Web site. Maybe the company has a plan. Maybe it doesn't. But the programmers aren't waiting around to say, "Mother may I?" Palm users are already distributing open source versions of their code, and unlike with the iPhone, everyone is perfectly free to install any Pre apps they'd like to run.

Web sites such as PalmOpenSource.com and PreCentral.net are cataloging dozens of apps that come complete with the source code. This is fertile ground for developers and an active community. Days after Apple nuked the Google Voice app, some Palm coders posted a version for the Pre. I found myself browsing through a number of others' apps and learning much more than I could from the Mojo documentation.

These home-brew apps are heartening. I know people are doing similar things with the iPhone -- such as selling the source to people who must install it themselves -- but the entire scene emerging around Palm has a much more organic and creative vibe. It's not getting hung up on parsing and reparsing the App Store rules. Maybe Palm will tighten down the screws in the future. But for now it's a thrill to swap code and play with the technology.

The current version of the Mojo SDK is merely the start of access to a very fertile platform. The Web tools are so well known and well understood that it's hard to understand why more manufacturers haven't tried Palm's tack before.