funkatron.com

I really don’t like to toot my own horn. Well, actually I do, but I’m also embarassed by it, so writing the title for this post was a bit painful. Nevertheless, I do think it’s accurate: Spaz webOS 1.0 is now available in the Palm App Catalog, and that’s a significant milestone for the project, and for open source on webOS.

I first started playing with webOS a year ago, over Christmas break at my day job. In June, Spaz webOS was in the App Catalog at release, and back then I was quite proud of the fact that we’d been able to ship a truly open source, transparent app on the first day of a new platform. And now, a year since I first cobbled together a Hello World in Mojo, Spaz has reached a reasonable level of maturity – at least as mature as something called “Spaz” will ever have.

Originally I was going to call this release v0.6. I am shy of using 1.0 because I am painfully aware of all the flaws in my software, and it certainly never feels “done” or “ready” to me. However, a recent discussion with Keith Casey led me to think more seriously about using the “1.0” designation – Spaz webOS is very much Safe To Use, but a pre-1.0 version might make some potential users to think otherwise.

And potential users are a bit more of a consideration now, because in a couple weeks (probably the week of January 11), Spaz webOS will start charging $2 for App Catalog downloads in the United States. This is something I’ve been planning for a while, but it’s still stepping out a bit, both for me (I’ve never charged for software before) and for open source software in general. To be clear, here’s how it will work:

1. Spaz webOS will cost $2 to download in App Catalog markets that support payments. Right now the only market that supports payments is the US. It will be free in all other markets.
2. Spaz will still be completely open source. The full source code will always be available.
3. I will not stop users from packaging and installing Spaz webOS themselves. In fact, I encourage it! I always need more testers, designers and developers. Hacking, patching, and messing with Spaz are fully endorsed. If you can’t help in one of these ways, consider donating to the SpazCore project.
4. Revenue made from paid App Catalog downloads will be used to support development and offset equipment and hosting costs. I’ve never made any money from Spaz, and despite some generous donations over the past couple years, I’m still well in the red. I don’t do this for the money (obviously), but lightening the burden and compensating myself and other people who have given their time for Spaz is reasonable, I think.

Another thing that isn’t changing is the principles that guide the Spaz project. I wrote up a statement of purpose a while, back, which I’ll replicate here:

1. Spaz was built for the sake of building it. It is not a means to an end. However, creating it has had several good consequences.
2. Spaz demonstrates that making things is good, and sharing how you make them is better.
3. Spaz is a necessary counter to closed, hidden technologies. Spaz must always be open.
4. The value of Spaz does not lie in the judgements of others, but in the process of building it, and the enjoyment derived by those who use it.
5. We welcome anyone who wishes to participate in the Spaz Project with open arms, as long as they understand and respect the purposes of the project.
6. The Spaz project values clear and open communication between participants.

This is how I think software should be made. If you agree, I hope you’ll consider supporting what we’re doing in a way you see fit. We always need help!

Thank you for making Spaz far more than I could have imagined.

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

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.

Spaz 0.5.0 went out to the Palm Pre App Catalog today. The coolest new thing is image posting support for TweetPhoto, Twitpic, yfrog and Twitgoo. While webOS still doesn’t have a generic file uploading service that third parties can use, these services support email posting of images, so we were able to build a workable solution using that. It’s not optimal, and as soon as webOS supports file uploads we’ll be there with support for even more services, but it works for the time being.

The other major enhancement in 0.5.0 is with notifications. Previously Spaz on webOS had just used “banner” notifications when new items were loaded, which appear and disappear quickly on the screen. Lots of users asked for what are called “dashboard” notifications in Spaz, though, which are like the ones you get with the email app: an icon is displayed in the corner of the screen, and if you tap it, a larger dashboard appears with more information. These notifications are persistent – they won’t go away until you dismiss them by swiping or tap on them to bring up the Spaz card.

All of these enhancements are available to other webOS developers as well. Because Spaz is open-source with a liberal New BSD-style license, you can use code from Spaz or the SpazCore libraries in your own apps. So if you want to do email-based photo posting to Twitter like Spaz does, you can! And although you are not obligated to tell us, if you do use our code, we’d love to hear about it.

As always, if you have problems, questions or suggestions, talk to us at our Tender-driven support site.

Folks who got the fancy lad Palm® Pre™ on opening day found the App Catalog chock full of superapps. One of them is Spaz, a ground-up rewrite of the award-winning desktop application I created for the Adobe AIR platform using pure HTML+JavaScript. Getting Spaz on webOS™ has been a big undertaking for me, and the process has certainly had it’s ups and downs. But I’m proud of the fact that we shipped a truly open source, transparent app on the first day of a new platform.

But much like Spaz on the desktop, this is not a revenue generator for the project. Everyone who works on the Spaz project is a volunteer, and we rely on motivated folks to help us make cool software. It doesn’t need to be a huge commitment — even just getting involved in the discussion and coming up with ideas is a big help. But here’s where we need help the most:

Coding

While I intend to be the lead on Spaz for webOS™ for a while, I really could use help — I’m working in my free time, and that’s pretty limited with a family and a day job. The full source code of Spaz for webOS™ is available on GitHub, and people who want to help make new features happen are encouraged to check it out.

Even if you’re not well-versed in webOS™ coding, if you have a good JavaScript background (or don’t and are just interested in developing one), we need help to build up SpazCore, our component library that drives Spaz for webOS™, and will drive all our projects in the future. Hacking on SpazCore requires no knowledge of webOS™.

Support

We have a brand new, very awesome support site at http://spaz.tenderapp.com/ which is sponsored by the awesome folks at ENTP. We need to direct people there, and we need to get involved in helping them there. We also should build up the FAQ/Knowledge base. In addition, identifying folks on Twitter who are trying Spaz or having issues and pointing them to the support site is very important.

Advocacy

Do you like Spaz? Why? First off, let us know — I’d like to build a repository of positive mentions like that. In addition, telling people about Spaz and encouraging them to check it out is great. Hwoever, this needs to be done in a nice, non-abusive, non-spammy way, and we always need to respect other applications and their developers. THIS IS NOT A COMPETITION — it’s making people aware of quality alternatives to closed, non-transparent software.

Design/UI

I’m an opinionated fellow and rather controlling of how the Spaz apps look, but I also know there are better designers and UX experts than me. If you’re interested in helping with design and UI work on Spaz — including additional themes — I’d love to hear your ideas.

What About the Desktop?

You are not forgotten. Spaz’s desktop client is long in the tooth, and we have Big Plans for a full rewrite based on SpazCore. That’s long-term though, and in the interim work is still being done on the current Spaz codebase, including adding multi-account support and improving filtering capabilities. We also intend to transition away from AIR to the Titanium platform.

So if you want to stop bitching in your Twitter account and actually make things better, here’s your change. Drop me a line at spaz@funkatron.com and we’ll sort out the best way for you to kick ass.