While at Palm and HP, I made it my mission to evangelize HTML5 app development both inside and outside our company. The very core of the webOS value proposition was the web. In webOS, mobile websites, native and web-based apps lived together in a “zen-like” harmony.

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).

Rarely do I find a need to call out the W3C folks (or anyone, for that matter), but the recent post by Daniel Glazman (@glazou), co-chair of the W3C CSS working group, pushed me over the edge.

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.

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”.

Really?

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.

Good documentation doesn’t come easy

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.

I was feeling nostalgic over the holidays, and extolling the virtues of one of the first languages I enjoyed as a kid: LOGO. Then I dug back into the syntax of LOGO. Compared to modern programming languages, words like “terse” and “arcane” spring to mind.

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.

Warning: this is a short-term solution, it may cause interesting results in future versions of the webOS SDK, so use wisely.

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.

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!

The last post revealed how a simple call to PalmSystem from your JavaScript code opens the door for you to take a stock web app with your favorite framework and turn it into a simple webOS app without having the overhead (or the wealth of cool features, in the interest of fairness) of Mojo.

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: