At least, that was the theory. In my two years there, I watched webOS slip from a leader in mobile web to a distant follower. I won’t elaborate much on the internal hows and whys (frankly, I doubt I even have the full story anyway), but the simple fact was I had a dramatic drop in confidence in our ability to stay relevant. All the drama in the news didn’t help, and neither did the mighty layoff hammer which eventually swung down on myself and more than half of the remaining staff.

I’ve had a couple months to relax, decompress, and recover from the rough ride. It’s given me time to reboot and explore the mobile space from a fresh perspective. A few things have stayed the same (I still think Android is doing it very wrong and iOS isn’t doing it very right), but a few new things presented themselves. Namely, there is another fish in the sea which has a much better shot of pushing out amazing, web-friendly devices…

Monday is my first day at RIM. You know, the BlackBerry folks. Like Palm, RIM has received some negative press of late. Some layoffs and restructuring are looming, and some of the tech media are skeptical of RIM’s future. While some of that sounds familiar, here are just a few important differences to me:

1. While webOS fell behind the market leaders in HTML5 support, RIM has pushed forward. In fact, the early BlackBerry 10 (BB10) browser looks to be top dog. Today, HTML5 Test gives it a whopping score of 447. This is a higher score than iOS 5 (324), higher still than Android 4 (273), and even slightly higher than the top desktop browser score (Chrome Canary with 442). Source: http://html5test.com/results/mobile.html

2. RIM gets that web developers can and should be equal citizens with native developers. For the past two years, they’ve been steadily moving towards complete system access parity between c/c++, Adobe Air, and Java (Android flavor). In other words, they support more tools for developers to make great apps than anyone else in the mobile space today.

3. As a user, BB10 itself is damn awesome. It has some of goodies I liked from webOS, iOS and even Win7; but all streamlined and more functional. Plus, there are even more unique features and slick interactions which help put it way over the top in my book…. and it’s not even released yet. I haven’t been this excited about a mobile platform in a long while, and judging from meeting a ton of other excited developers at a BlackBerry 10 Jam, I’m not the only one.

I’m joining the BlackBerry Developer Evangelist team, with pretty much the same mission: get web developers into making great mobile HTML5 stuff (apps or otherwise). Now that I think about it, there is one other similarity to my job at Palm: great people. Everyone I’ve met at RIM so far has been top notch. And while I’ll miss working with my former webOS Developer Relations teammates (except for Joshua Granick, who moved to RIM as well), I’ll still see you all at HTML5 conferences, mobile meetups and, of course, BlackBerry developer events (c’mon, we all know you’re going to come and take a peek at BB10).

In short: farewell webOS Nation, and hello CrackBerry!

In his article, he calls for everyone to, get this, stop using -webkit in their sites. He equates webkit, now a popular engine for most new mobile browsers, to IE6. Moreover, he calls it a “threat to the open web”.

Seriously?

This from the group responsible for years of delays in approving standards? Remember, these are the fine folks who for the past three years have cautioned web developers from using HTML5 (a term used a bit liberally to also include new CSS3, video, local storage, web sockets and other goodies) because they’re still working on drafts for it. Take the canvas tag, a webkit mainstay since 2005, which is still a W3C “working draft” — seven years later.

The only reason web developers are using these hot webkit (and gecko and now even internet explorer) features in the first place is we’re tired of waiting for this standards body to get off their collective ass and actually approve something.

Webkit is the new IE6? Really? If a vendor were to make a browser that only complied with approved W3C standards, you’d pretty much have IE6. So really, W3C itself is “the new IE6″.

For a representative of a non-profit organization to jump up and call for us to set our websites back 3-5 years is ridiculous. This is not a call to action, but a call for our inaction; to limit progress and the pursuit of competitive advantage in the name of some socialistic ideal created by a group who is even more monolithic in pace than in size. We’re talking a glacial, almost purposeful aim to slow innovation and plant a giant “STOP” sign in the evolution of the web.

In its glory, his article: CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*

Contrast this with the W3C’s hesitation to green light, well, pretty much anything cool to come along in web development in the past five years.

To Daniel Glazman, I propose you spend more time working with your group to approve specs and less time bickering and whining about webkit. The whole “problem” of browser vendors moving on without you starts with how the W3C works, and not with the vendors themselves. To try and shift the blame and rally people to a cause they don’t fully understand is irresponsible and reprehensible. I believe the industry term for his call to action is “a load of crap”.

There’s a fresh debate raging in the JavaScript community. The battle lines are drawn between those who like all-in-one solutions for app development, and those who prefer to assemble the pieces themselves. Really, the fight is more between those who make these things, not those who use them.

A site for the little libraries

The recent ugliness was sparked by microjs.com, a small project which aims to list some of the more useful tiny (5K or less) code libraries out in the wild.

Then the flames started spewing over Twitter. The brunt of the griping was focused on @thomasfuchs (of script.aculo.us and zepto.js fame) and @ded (ender.js and about 100 other handy things). Arguments generally centered around the size limit (5K): “that’s so arbitrary, why can’t my lib get listed too” (generally followed by much wailing and gnashing of teeth).

Short answer: it’s their list. Hand picked from their own survey of useful-yet-small projects out there and from selecting submissions from library creators. I’m going to repeat that first part: it’s their list. It got attention, and those small-yet-useful libraries in there are going to get some exposure. Those of us with libraries or frameworks which are larger and lean towards providing a bigger bundle of useful things should chill (don’t make me name names, cause wow).

I have a couple things up on GitHub: Jo (~15K gzipped) and TurtleWax (~0.7K gzipped). Guess which one got on the list? Yeah, the tiny, single-purpose library. Did I try to get Jo in there, even though it’s arguably the smallest of the mobile app frameworks out there? Hell no, it’s 10K over the limit.

Both sides argue simplicity is a big part of their approach

There are just differing ideas of “simple”.

Some developers prefer building things from scratch. I do, too; that’s why I often make my own libs, even for in-house projects. Most of these folks prefer the simplicity of a blank canvas on which to work, and will only occasionally use something small and useful written by someone else. They generally don’t want to have to learn a large framework, because it’s an added layer of complexity which could make their apps bigger, sluggish, and potentially more buggy than if they did it all themselves.

Other developers prefer to code less, or at least spend less time fiddling with things that in many cases should already be built into browser engines. The drive here is also simplicity, but from a time-to-market standpoint. The idea is, pick a framework which seems to do as much or more than you need, test it out a little, then ride that horse from then on. If there’s a bug in the framework, work around it; or better, fix it and contribute back to the project.

My lib is smaller than your lib

Does size matter? Actually, it kind of does. Generally, the smaller the file size, the easier the lib is to learn, and the less load time your app is going to have if you use it. Plus, the idea is your app will have just what you need to get the job done, and little else.

This idea can even spill over to the framework side of the equation. One of the hard requirements I have for Jo is to keep it under ~20K gzipped. Is that arbitrary? You bet. The thing is, setting a limit like that makes me a better product manager and a better coder. I’m mercilessly against feature creep and I work hard to keep cruft out of my codebase. Who benefits? The developers who use it (bless their coding fingers).

The best approach…

…is your approach. Look very closely at what’s out there, and go with what suits you and your project best. Every single lib out there will have bugs, or something extra you didn’t expect, or something that might take some getting used to. It’s all about finding things that are natural to your way of doing things.

Hell, there’s no reason you can’t dip from all ends of the code pool. You might even dig something frameworkish like Jo or Sencha Touch, and still have a yearning for some special feature or two. And hey, one of the little libraries listed in microjs might fill that void.

Documenting source code is rarely something a coder likes to do. I’m just as guilty as anyone else. I know it’s a “good thing”, but my natural inclination is to code first and document later. Sometimes later comes so late that it’s a chore to get it done. I’ve been forcing myself to document as I go, and it usually works out pretty well in the end.

I’m a control freak

What’s made this process easier for me is to completely dump the notion of auto-generated documentation (I’m looking at you, javadoc, jsdoc, yuidoc, ruby-doc and the like). Instead, I favor writing the documentation for a given piece of code with markdown.

It’s a tradeoff between automation and control, and when it comes to documentation, I prefer the control.

I can start by documenting only that which is important. That satisfies the “write this down before I forget” part of documentation, and frees me up to improve it in later drafts. Yes, drafts (like a real piece of writing). I don’t have any “empty stubs” made for me, so at any given moment my documentation is fairly complete without extra noise.

Later, sometimes much later, I can add more to the documentation, including example code and other goodies. This way the documentation matures along with the code, which can be pretty cool.

This is not a new idea by any means. Most perl developers have used pod, which has a very similar approach but with a slightly less human-readable plaintext markup (I’m a CPAN contributor from way back, I’m allowed to dis pod a little). In fact, this style of code documentation goes way-way back. Before source code documentation compilers existed; back when you actually read the documentation as you read the code.

Along my source code documentation journey, I checked out “natural docs”, which looked very appealing. I was disappointed that while flexible, it went down the path of regimented source documentation. Also, I found that I preferred the simplicity of a plaintext formatting language like markdown, without having to worry about adding section types and such to the documentation compiler.

So, what then?

Enter jodoc

Last Spring, I wrote a simple set of perl scripts which takes embedded markdown docs (along with raw HTML pages and other markdown documents) and turns them into a pretty useful set of HTML documentation. This tool is called “jodoc”, and was written to support my HTML framework (Jo). I’ve been using this plaintext approach to source doc writing ever since, and I love it.

Basically, it takes something like this (found in my source code):

And spits out HTML which looks like this:

A couple examples

The first is the documentation for Jo itself, turned into one easily-searchable, cross-linked and PDFable single page of HTML: http://joapp.com/docs/.

The second is the documentation for PhoneGap, which is split into easily-grokkable and book-markable sections (with some nice CSS at work as well): http://docs.phonegap.com/.

The concept is simple

jodoc looks for markdown documentation in your code (it can be in one continuous block, or split into sequential pieces, your call). Then it assembles it into the structure you want, puts it into a single file, or adds a customizable table of contents (also defined with markdown) and splits your documentation into separate HTML files. For a final touch, it takes anything you’ve marked (using markdown, of course) as a main header (i.e. H1) and turns it into a fully-linked and indexed keyword. This means when you casually discuss a class or some term you’ve documented elsewhere, jodoc will make a link for you (think “wiki”, but without TheCaps).

It’s a simple idea, and folds nicely with doc files which live outside your code (either markdown or HTML, currently). We’re already working on some neat extensions, but since it’s open source, we’d love to see more contributions.

Give it a try

Dan Freedman, a friend and fellow HP engineer, took my crude perl script and banged it into shape. The result of which can be seen on GitHub, along with a new node.js version that’s already underway (go Dan!).

Perl: https://github.com/davebalmer/joDoc

Node.js: https://github.com/azakus/jodoc-js

If you’re dead-set on javadoc-style documentation, that’s fine. I’d invite you to give this sort of approach a try. Really: a serious try on your next hunk of code. You might find that you’re actually doing less work and getting better documentation for the effort.

I decided I wasn’t that nostalgic after all, but I did want to bring some of the cool graphics capabilities of that venerable language to JavaScript. Instead of making a LOGO interpreter in JavaScript (it’s been done), I made a small API to achieve turtle graphics in a more familiar setting.

Check out a couple code demos (view source):

• Spirograph-inspired designs
• Fractal trees translated from a LOGO example

The API attaches itself to a canvas tag, and supports chaining. I also decided to add some convenient methods for more traditional cartesian and polar coordinate systems.

More info can be found at the project page on GitHub. The open source project is in its early stages, but it’s already fun and potentially useful. Enjoy!

• CSS3 gradients
• Flexible box model
• Text shadow

Plus, on the JavaScript side, I have yet to be able to get any CSS transforms working, though the way to detect them seems to be:

if (document.body.style.msTransform !== 'undefined')
    alert("IE9!");

In short, it seems to have relative parity with Opera 10 as far as cool-yet-useful CSS3 features. Keep going, Microsoft, I’m totally cheering for you!

One minor frustration I’ve run into with making JavaScript webOS apps (games in particular) is the mousemove events don’t seem to fire very often on custom controls. This is particularly noticeable when users finger-paint on canvas tags or drag elements around. I suspect that this quirk in the webOS webkit was introduced as a performance improvement, but running up against it can be painful.

A fix I’ve discovered is this simple CSS addition to any elements which need higher resolution mouse movement (er, touch movement, whichever):

myelement {
    -webkit-user-drag: element;
}

Just put any valid CSS selector in place of “myelement” above, and you should notice a marked improvement in mouse movement precision for the element(s) in question.

This is not a future-proof solution, because if Palm’s webkit properly supports this CSS property in the future, your users will be dragging a shadowed version of the control around in ways you probably don’t want. Please be sure and test this with new SDK versions and be ready to take it out of your app at some point.

Twelve minutes of Jo, showing the same JavaScript web app code running on webOS, iPhone, iPad, Android, Symbian and… Dashboard widgets? Yup. First in a series of videos, this screencast is a quick intro to the cross-platform capabilities of this JavaScript framework (both for mobile apps with PhoneGap and mobile web apps). Followup videos will cover making your first Jo app, getting it running with PhoneGap, theming it with CSS and other goodies. Enjoy!

You can also read more about this open source project at joapp.com.

Continuing with my explorations in the webOS 1.4.5 SDK, I’ve picked out a couple of other useful calls to the PalmSystem object. Both can be added to the “hello world” example I started in part one, and they’re really quick.

Free-wheeling orientation

A common requirement for mobile apps is the ability to respond to device orientation. I’m still digging around to see where you can hook into these events, but in the meantime here’s a simple call which is quite useful:

window.PalmSystem.setWindowOrientation('free');

This tells webOS to let your app rotate along with the device orientation, switching from portrait to landscape as necessary. It’s a high-value one-liner call which should serve most orientation needs.

You can also specify a “locked” orientation with different strings in place of “free”. Options are: up (default portrait), down, left and right. So if you have a side-scroller game that would benefit from horizontal presentation, just use:

window.PalmSystem.setWindowOrientation('left');

Pretty cool, and definitely useful in our quest to turn web apps into webOS apps without having to load Mojo.

Full screen mode

Speaking of games, sometimes you want all the screen real-estate you can get, and those extra 30px or so which have your app menu, current time, battery and signal strength look mighty delicious. Here’s how to toggle that on or off, revealing a full empty screen to create your masterpiece:

window.PalmSystem.enableFullScreenMode(true);

Toggle the full screen mode by passing in either true or false.

A word of caution

Keep in mind that there is a reason Palm abstracts this stuff into the Mojo SDK, and there is no guarantee (yet) of how long these calls will be around. It’s always best to keep a close eye on the Palm Developer Forums and test your apps extensively with any upcoming version of webOS.

Next steps

I want to get a working example of a low-level webOS service request. This interface allows you to get to important system calls to dial a phone number, get your GPS location, launch another app and other neat stuff.

Step one: Make a web app and test it in Chrome or Safari.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
    <title>Hello</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
    <h1>Hello World!</h1>
</body>
</html>

Save this into a new folder (using a folder name of “hello” in this example) as index.html. This will become your app folder. You can test your app in Chrome or Safari by simply opening this file in your browser. Not terribly impressive, but hey, it’s a start.

Step two: Add a file to turn your folder into an app.

{
    "id":"com.yourdomain.hello",
    "version":"0.0.1",
    "vendor":"Your Company",
    "type":"web",
    "main":"index.html",
    "title":"Hello"
}

Save this off as appinfo.json in your application folder. You can test this app real fast in webOS. Just pull up your emulator, then open a command line prompt and do this:

palm-package hello
palm-install com.yourdomain.hello_0.0.1_all.ipk

Then go to your emulator and pull it up. And… nothing happens. You get a blank card and a loading spinner. Hypnotic, but certainly not what we intended. We’re missing something, and luckily it’s not much of a something.

Step three: Add this tiny chunk of JavaScript near the top:

if (window.PalmSystem) PalmSystem.stageReady();

This tells webOS that you are ready to present your app to the user. It exists to give you a chance to preload whatever you need (usually your JavaScript libraries and some app initialization) so your users don’t see things flying around the screen as you load them.

Add that line of code, so now your index.html should look like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
    <title>Hello</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
    <script>
        if (window.PalmSystem)
            window.PalmSystem.stageReady();
    </script>
    <h1>Hello World!</h1>
</body>
</html>

Now when you palm-package and palm-install (as above) and then run your app, instead of a card floating there with a loading spinner, you get your app!

Moving forward

From here, you can add your favorite JavaScript library (some work better on mobile devices than others), and make a proper app.

This is exciting stuff for cross platform mobile development. I’ll be working closely with Palm engineering to see what other gems we can expose, so stay tuned!