funkatron.com

No more travels for me until SXSW in March, I believe. I’m far too tired.

Did I say that? I actually knew very well that a week later, I would be traveling to San Jose for ZendCon 09. Foolish me.

I spoke at ZendCon on Building Desktop RIAs with JavaScript and PHP. I’ve given this talk other places, but this time I showed off some fun PHP-powered jQuery within Titanium. Here’s a snippet:

<script type="text/php">        
    /**
     * run the passed function when DOM Ready event runs 
     */
    $jQuery()->ready( function () use (&$jQuery) {
        /**
         * set some CSS properties 
         */
        $jQuery('#phpjQ')->css('display', 'none')
                        ->css('background-color','#333')
                        ->css('padding','10px')
                        ->css('border','2px solid #000');
        /**
         * bind a delegated click event to the passed function 
         */
        $jQuery('#invokePHP')->live('click', function () use (&$jQuery) {
            /**
             * set the text color and reveal 
             */
            $jQuery('#phpjQ')->css('color', 'red')->slideToggle(500);
        } );                
    } );
</script>       

Building Desktop RIAs with JavaScript and PHP

• Slides
• Code: Server-side PHP, AIR, Titanium

Unlike some others, I only participated halfway in CodeWorks 09, doing the east coast leg of Atlanta, Miami, Washington, D.C., and New York City. It was an enjoyable adventure, and I liked being able to try different approaches in my talks and see what worked best.

I was able to record audio with the voice memo app on my iPhone. Getting hour-long recordings off is a bit of an adventure – they refuse to appear in the voice memo playlist in iTunes, so you have to find the files in the MobileSync backups folders and do some renaming work – but they turned out pretty well.

Introduction to CodeIgniter

• Slides
• Code
• Audio (recorded in NYC)

Building Desktop RIAs with JavaScript and PHP

• Slides
• Client Code, Server Code
• Audio (recorded in DC)

No more travels for me until SXSW in March, I believe. I’m far too tired.

In the past two years I’ve spent most of my free time working on desktop applications written in JavaScript, HTML and CSS. I write them on top of web runtime platforms like Titanium and Adobe AIR, and more recently Palm’s webOS. In this time, I’ve heard a misconception raised repeatedly: that “local” (desktop or mobile) applications written on top of web runtimes offer no advantage over remotely-hosted, browser based apps. Or, to paraphrase something I overheard recently:

HUH huh your app is written in JavaScript and HTML, why don’t you just load the web site DURRRR.

I suppose this kind of thinking comes from the JS+HTML+CSS being almost exclusively used for web site front-ends for so many years. It’s a knee-jerk reaction, much like the one that says “oh, you can’t use PHP in the ‘enterprise’” or “Oreos aren’t for breakfast.” Proved my mom wrong on that one.

So, I decided to make a list of what things you can do in a web runtime platform that you can’t do in a browser. Now some of these vary depending on the platform or the browser, and I’ll try to make note of them in my list:

1. Cross-browser compatibility issues are a thing of the past
   I should offer a caveat here — even though the rendering engines are the same, you’ll sometimes run into OS rendering differences. AIR, for example, supported CSS3 box shadows on OS X until v1.5, but never did on Windows. But the differences are far, far smaller than you’d see between, say, Safari 3 and IE6. Trust me — you will love not having to worry about getting your layout working in some ass-tastic box model implementation anymore

2. Advanced rendering features (CSS3, etc)
   Since you don’t have to worry about looking the same in different browsers, you can take advantage of the special features your runtime’s rendering engine supports. Titanium, for example, supports the same advanced CSS features that Safari 4 does, like box shadow, border radius, and CSS gradients.

3. File system access
   On desktop web runtime platforms like AIR and Titanium, you can interact with the filesystem just like any other application: read, write, and create files and folders with the permissions of the executing user. webOS offers less freedom in this respect, but you can read and write files on a limited basis.

4. Networking
   Both of the major desktop web runtime platforms provide much more advanced networking capabilities than are available within a browser. I’m not much of a networking programmer, but both platforms allow the developer to open TCP socket connections and communicate over them. Titanium seems especially well-prepared in this area, with its ability to leverage Python and its powerful networking capabilities.

5. No same-origin policy restrictions
   If you want to pull data from a web site other than your own in the browser, you have to resort to JSONP — basically an XSS attack waiting to happen — or set up a proxy on your site’s server. Web runtime app platforms don’t have this issue, so you can make XHR calls to any domain you wish, and interact with any APIs.

6. No need to support non-JS users
   This might seem like a small issue, but having to support users who have disabled JS was one of the major reasons I never did serious browser-based frontend programming before I started working on Spaz two years ago. Now the cool kids at SXSW will tell you that “nobody” disables JavaScript, but I think that’s kind of short-sighted.

   Nevertheless, this argument and the need for graceful degradation and “unobtrusive” JavaScript become moot in the web runtime app platform. JavaScript is there, it’s expected, and you can’t disable it. So go crazy.

7. Using/interacting with platform-specific UI elements
   This includes things like window chrome, menu systems, Dock items (OS X), menulings (OS X) and the System tray (Win/Linux). Both major web runtime platforms display your application within the native window chrome, allow you to create native menus, and give you some access to the system tray and OS X’s Dock. Titanium is a bit better in this regard in that it inherits the native look of form widgets and scrollbars, and provides access to the OS X menubar (those little icons in the top-right).

8. Sound playback without plugins
   Until HTML5 becomes standard in all browsers and bestows the grace of plugin-less media playback, we’re stuck <embed>ing <object>s in our gorgeously crafted markup. Funk dat. Web runtime platforms provide sound playback APIs that mean we don’t have to stick a Flash applet in our document and hope it doesn’t catch the CPU on fire. AIR has a particularly good playback API (probably because the whole thing is running in a Flash engine. Small victories).

9. Interacting with other applications/shell interaction
   Being able to leverage other applications on the machine/device can be really valuable, especially on Unix OSes (Mac OS X, Linux, etc) that have a bevy of useful utilities available from the shell. Titanium is the only desktop web runtime platform that allows the developer full access to these capabilities; AIR is limited to interacting with other Flash-based applications at this time (although this may change in the future). Runtimes on mobile devices are typically much more limited, although webOS’s Application Manager service does let applications launch and pass arguments to other apps.

10. Database support
    Typically this is implemented either via the HTML5-style database stuff (usually asynchronous) or a platform-specific SQLite (usually synchronous). Out of the box, support isn’t provided for external DB servers (MySQL, PostgreSQL, MS-SQL, etc), but with Titanium this should be possible by delegating to Python or Ruby scripts, or Titanium kernel modules. DB servers that provide HTTP interfaces (like CouchDB) will work fine, though.

All of this doesn’t mean web runtime platforms are going to replace browser-based apps anytime soon. There are clear advantages to remotely hosting an application (speed of updating comes to mind), and supporting an app on a user’s machine brings a new group of debugging headaches. But for applications already chafing at the limitations of the browser, web runtime platforms offer a compelling option.

A few of you may know of a small app I did in AIR a while back called Searchatron. It’s mostly a proof of concept, but does have some usefulness in making it a bit easier to track multiple Twitter search queries. Searchatron uses an MVC-style pattern similar to how the next version of Spaz will be built, and much of Searchatron’s code provided the basis for the SpazCore component library.

As more of you may know, I’m very interested in the new Titanium platform. It’s similar to AIR, but fully open-source, and much more extensible. In order to learn more about Titanium, I tasked myself last week with converting Searchatron from AIR to Titanium. The whole process only took a couple hours. You can download the result from http://get.titaniumapp.com/app/12GKqr3.

What’s interesting is that Appcelerator, the creators of the Titanium platform, are running a contest right now. Two $500 prizes will be awarded for the most downloaded app, and the highest-rated app, respectively. If Searchatron wins either of these prizes, I’m pledging now to use the prize money to support further development of Spaz and the SpazCore project, in the form of cash gifts to our most giving volunteers. It might not be a lot, but it does mean real money is going to people working on open-source development. I hope to continue doing so when feasible and prudent.

If you’re interested in helping, this one is pretty easy: download Searchatron, and if you like it, suggest others do the same. Feel free to point them here if you like. By doing so, you’ll be doing a lot to encourage the continued development Spaz and its related projects.

• Download Searchatron
• Searchatron Source
• Titanium App contest

We don’t sign Spaz with a code signing certificate generated by one of the 4 (as of this writing) certificate authorities Adobe accepts. This means that when you install Spaz, you get a scary “Publisher:UNVERIFIED” warning. This is why we don’t sign, from a letter I wrote when asked about it in Spring 2008:

If I sign Spaz with a paid-for Thawte cert, I am on the hook every year for a Thawte cert. I can’t change my cert signer or go back to a self-signed cert without breaking auto updating (at least as I understand it), and I’m therefore locked into a $300 expense every year. That’s not terrible for a commercial app backed by a company, but that’s a pretty significant chunk of change for a free, open-source app developed by one person as a hobby to lay out.

I’m familiar with how certs work, and how Thawte handles certification as compared to other, less expensive cert vendors. Were I convinced that Thawte did some kind of verification process/background checking on the applicant I could see the value, but at least with SSL certs, they certainly didn’t do anything more than vendors who donate free certs to EDUs.

Currently, there are 3 other CAs in addition to Thawte, and the prices range between $180 and $300 per year. Some of these CAs do seem to do a little more background checking. Still, the same arguments apply, especially the one related to cost.

Spaz doesn’t generate revenue, and relies on donated time from myself and a handful of other generous folks. Committing to a yearly expense in the hundreds of dollars seems unwise.

If this is something you would like to see change, I’d encourage you to ask Adobe to make code signing a realistic option for Free, Open-Source Software like Spaz by providing certificates free-of-charge – after a reasonable review process – to projects like ours.