As I've been investigating frameworks that would let me create an installed app for Mac/Linux/Windows/iPhone/Android, the two words that have come up most might surprise you: JavaScript and WebKit.

Most of you know what JavaScript is. It's a programming language that allows you to do client-side tasks in the browser (programs you embed in a web page that are run by the user's browser, rather than on the web server). Fewer might know about WebKit.

WebKit is an engine for powering a web browser. When Apple went to create Safari, they borrowed and built upon an open source engine called KHTML which was created by the KDE project. Over the years, it's stayed open, stayed free, tried to stay ahead of the technological curve, and by many opinions, is less bloated and burdened with legacy code than the open source engine that powers Firefox.

And it's spread. Webkit powers Safari on Windows, Mac, iPhone, and the upcoming iPad. It powers much of the new Google Chrome browser and the Google Chrome OS. WebKit powers the built-in browsers on Android and the Palm Pre. It also underpins multiple cross-platform application frameworks, including Adobe Air and Appcelerator Titanium. I haven't spent a lot of time researching it, but it seems that Blackberry's going WebKit for it's main browser and you can get a WebKit browser for your Windows Mobile phone.

Basically, you get the broadest range of targetable systems not with Flash, not with Java, but by targeting development to WebKit.

Most of your smartphone users will go with the built in browser. Even if they downloaded something else, it's hard or impossible to delete the built-in browser in many phones, so they'll have it. If you want to make sure your desktop/laptop users are running a WebKit browser, just package up the front page of your web application in Adobe Air or Titanium Appcelerator and the framework's runtime will bundle your app around a runtime that gives you all that WebKit functionality.

With client-side databases, "offline" mode (web scripts can determine when the browser is offline and continue to offer various services), some pretty cool JavaScript libraries for user interface animation and 2-D gaming, HTML5's native handling of video and audio, and the ever-expanding functionality of the Canvas element, applications will continue to migrate to the browser. As more browsers offer a standardized option for user scripts (3rd party scripts that run after a page loads... with the user's permission), even more ways to blur the line between desktop and web app enter the picture.

Don't get me wrong. You're not going to see the whole computing experience handled inside the browser. For some computationally intensive tasks like video compression and 3-D gaming, you just need the pure, throaty roar of compiled code running natively on the platform you're using. But where pure speed, power, and access to various hardware devices isn't needed, you're going to find enterprising souls creating online competition for your favorite desktop apps, and it's all going to be handled in your browser by its built-in functionality.

After a week of trying to figure out the best way to structure my latest secret project, I've decided to target WebKit, because with a combination of a WebKit-based framework for the desktop and WebKit powering the default browsers on a huge portion of the smartphone universe, it's going to give my project the broadest possible reach.

I'm not sure how the idea came to me, but it did.

I make a neat little homemade chocolate cheese from scratch (heat the milk and cream, add lemon juice to curdle, strain, drain, and mix in cocoa and sugar... that easy). I was trying to think of a dessert I could make from it and came up with the following idea.

Make the cheese (possibly with some ground chocolate chips mixed in to make it a little more gooey when hot). Form the cheese into balls and then chill. Take a chilled ball, dip it in drop doughnut or funnel cake batter, and deep fry. Let drain, then skewer three or four balls together to make a kebab. Drizzle the kebab with a chocolate sauce that's been kicked up a notch with a little salt and some fresh ground pink peppercorn.

So, who dares me to actually make this (as my wife shakes her head and begs me to just say "no")?

I got an idea for an application that I wanted people to be able to run on their desktops and phones, and to be able to sync the data between their desktops and phones. I could do it as a web app and have it run on any browser, but that posed 3 distinct problems:

1. It is going to use and manipulate information the user may consider private or sensitive. I just don't want to store that information and be responsible for its security. Some elements will get stored on a server I maintain to aid in the sync, but because the juicy stuff isn't on it, I have less of a privacy/disclosure nightmare if my server is hacked. And because there's no "juicy" data on the server, it's a less attractive hacking target.

2: If I do it as a packaged application, I have much fewer headaches with cross-browser compatibility. Plus I can bring in features that some browsers don't have (and some do).

3: The more I functionality I run server-side, the more data transfer and processing overhead I have to cover. That means money I have to pay. So the more I can minimize this, the happier I am.

So I went looking for a programming framework and development environment that could support Windows, Mac, Linux, Android, and iPhone... at minimum. I found two.

Mono

Mono is an open source implementation of Microsoft's .Net framework. It allows you to code in C# or the .Net flavor of Visual Basic and use a cross-platform widget toolkit for creating your user interface.

Only one problem, their IDE for Mac doesn't support the cross-platform widget toolkit's visual designer and only the most recent version started supporting debugging. And when I loaded up Ubuntu in a virtual machine so I could try it on Ubuntu, the visual designer barely worked and was completely unintuitive.

There was going to be a learning curve for C# as it was, but my primary machine is a Mac and their Mac development environment's shortcomings were going to turn the learning curve into a learning wall. Still, it remained in the running because I could always run it in Windows via Parallels, and if I surmounted that curve, there was not only the payoff of some .Net libraries I could use to avoid reinventing some wheels, there was the fact that the .Net programming skills and apps demonstrating them on 5 operating systems might actually be very marketable.

Sadly, the "documentation" for the MonoDevelop IDE contains 5 articles and 4 screencasts, some of which are out of date. The other 11 chapters merely have "TODO" placeholders, so we can wait for important articles on UI development with GTK# and "Working with Databases".

Appcelerator Titanium

Appcelerator Titanium is an interesting option for cross-platform development. It's a wrapper around the WebKit browser engine that allows you to basically create web apps that run locally. The wrapper gives you additional APIs that are accessible from the apps.

Upside, if you know a little JavaScript and HTML, you can be writing apps almost instantly. If you're a big fan of frameworks like Dojo, Scriptaculous, or JQuery, they're available. And when combined with the custom APIs for additional hooks into the filesystem and other OS features, it's pretty darn powerful. Then you add in that it offers PHP, Ruby, and Python interpreters. Then factor in the Greasemonkey style userscript capabilities (which let you write scripts that interact with pages from other web sites).

Then you come crashing to earth. Appcelerator has two development flavors: Mobile and Desktop. Desktop is sort of a Wild West free-for-all, where the sky seems to be the limit. But in the Mobile universe, you lose many of those features. If you ask why, there's one simple answer: "Apple doesn't allow it."

So if you want to develop one codebase that powers both Desktop and Mobile flavored apps, it's all going to be in JavaScript. And despite the Desktop flavor seeming to have a wealth more features, the Mobile flavor is much better documented. For example, the Mobile flavor has a "Kitchen Sink" demonstration application full of demos of UI hooks and methods for calling their wrapper API, but Desktop doesn't.

In fact, on their code wiki, their 9-chapter "getting started" tutorial only has 4 chapters finished. The remaining 5 chapters have just been outlined and left up to taunt beginners.

So if desktop seems to have so much more power to offer, why does mobile get all the documentation? Because there are 8,000 programming languages and IDEs that will allow you to rapidly develop a Windows application. The Android and iPhone spaces are just opening up. This presents a route to developing for what may well be the two hottest mobile platforms in the world with a MUCH lower learning curve than if you had to learn how to program Android and iPhone natively.

Creative agencies can start developing iPhone apps for their clients after giving one of their web guys a few days to get up to speed. You could probably code a fart button app in your first day, even if you were relatively new to web programming.

The Downside

Frameworks like Java, .Net, and Flash/Air are dependent on virtual machines. They compile the code you write not into a true ready-to-run application, but into an intermediate state called "byte code" that is then further processed by the virtual machine before it can be run. That gives them their "write once, run anywhere" capabilities. The virtual machine translates their byte code into code that the platform they're on/in can run.

The downside of this is that you can get a "decompiler" and translate the byte code back into a pretty good approximation of the original source code. If you have proprietary algorithms that you want to protect by keeping them secret instead of patenting them, you'll be out of luck, because .Net, Java, and Flash/Air applications can be reverse engineered.

But the problem with Apcellerator is that, for the most part, it's not compiling your code at all. Write your "Hello World" program. Package it in a Windows installer. Download it and install it. Then go into your C:\Program Files directory, find the Hello World app's directory, and drill down to the Resources directory. In it you'll find an exact copy of the Resources directory from your development environment with all your HTML and JavaScript files not only intact and unaltered, but you can open them up in Notepad, change them, and change the operation of the "installed" program.

That just sort of bugs me. I can't think of any way it can be exploited to harm users unless they've already been compromised, and in that instance it's more of a case of the burglar already being in the house and the Appcelerator app just being the lamp he decides to hit you with. But users being able to go in and change code in an installed application... seems a recipe for something bad.

Hopefully future versions will create unalterable checksums for these files, so each time the file is run/loaded, if its checksum is different than the checksum created at packaging time, there's an error message and the code isn't run.

You can get around some of it by using a compressor or obfuscator. Using something like Packer not only creates unreadable code, but even if it gets decompiled/decoded, it's still a lot harder to read and change than your well-whitespaced, well-commented source.

The Final Decision

I'm going with Appcelerator. I won't really create five programs at once because the Desktop and Mobile UIs are different, and there are some differences in the APIs, but a large piece of my code base can be written just once and power both the Mobile and Desktop flavors of my app, and it's not nearly as frustrating as Mono.

What are the top 5 things a car absolutely must be able to do?

Don't read on until you've listed them.

Done?

Were they "go forward, go backward, turn left, turn right, and stop?"

Sometimes we forget things in a project spec that we assume are so fundamental that they're a given. We get caught up in high-level thoughts like leather seats and voice-controlled GPS, but when we hand the project off, we need to be sure that the person we handed it off to will remember to add the little details we didn't specify... like brakes.

The next time you're hiring someone to build or design something for you, whatever the project, ask yourself if you trust that person to include a reverse gear, or at least ask if you want one, even if you didn't specify it. The last thing you want is a car that meets every spec on your list, but can't back out of a parking space.