Unless you have hooks for deeper functionality inside the JavaScript interpreter used to run the application logic. And I somewhat doubt Palm will refrain to release a full SDK for the native OS.
back
2 comments
How many hooks do you really need to get a developer up-and-running? File system access? Ability to play sounds?
AIR has a very limited set of extra javascript commands, but it is enough to give the developer the feeling they are definitely delivering a client-side app.
"Unless you have hooks for deeper functionality"
Functionality like what? Will it let you import physics libraries written in C? Give you access to OpenGL in javascript? What about networking stacks? What if I need OpenSSL? At a certain point you end up reinventing an awful lot of wheels even if the hooks are all there.
I think the mini-revolution Palm's pulled off isn't being understood. They've implemented a full SDK in HTML/CSS/JS. Unlike the helpless widgets of the apple-side, Palm's presenting their entire API as a set of extensions to a pretty forward-looking HTML stack.
From what I've seen:
- Graphics: HTML5 canvas. No word yet on if it's got the 3D support that's been planned for that canvas. But 2D access for graphics is pretty certain.
- Other than that, HTML5 local storage for your app data. They even have javascript access to old palm .pdb files.
- Javascript access to the contacts, calendar, phone, etc. APIs
- The app is stored locally, and can run without network access.
- As for networking/ssl... it's a web app written in HTML/AJAX, think about it :-)
Wonderful! I always dreamed of programming phones in HTML/CSS/JS. This is a great step forward from C/C++/ObjC. Joking, of course... but this seems to me the way for trivial apps, given the constraint in a phone-sized OS.
I hope to be wrong. Palm has been my first (useful) PDA...
While it'd be way more difficult to write the next office clone in this stack, the vast majority of apps we see on mobile devices are frontends to web data, calculators, or databases of some sort. In those cases, I think these APIs might be just about perfect.
Perhaps they'll provide ways to extend out the javascript APIs (e.g. native code modules) later.
The vast majority of apps we saw on mobile devices, you mean. Then the iPhone and Android-based phones came along. If simple frontends are what the Pre plans to focus on, then Palm is still fighting the last war.
Games aside, there's hardly anything on the App Store that couldn't be done in webOS. It's not just "local webpages" -- the SMS and phone apps are written in it, after all.
I think if the choice was between a third all-new alien SDK and luring developers in with HTML+JS, Palm made the right choice.
Um, I hate to break it to you, but none of that is Palm-specific. In fact, it's all available on the iPhone already. It all comes out of WebKit, which is mostly developed by Apple. Going back further, the canvas was developed by Apple for Dashboard before it was ever standardized.
I agree that it's neat--in fact, I expected that in the way of an iPhone SDK long before the native one existed (and given the number of ex-Apple employees on the team maybe that's where the idea came from)--but I wouldn't call it a mini-revolution. It's just an SDK built on an existing open source platform.