Look, I don't want to get into a big debate about programming here, but Javascript is NOT quick to write/easy to debug for any kind of serious undertaking. I write (financial instrument) trading systems for a living, and our entire front end is in Javascript/Ajax. It is a freaking nightmare to debug and anything but quick to write. I do much faster work with the straight C back end, both in terms of writing and debugging.
The backend of a web app is different component to the front end. They are really two different programs that are coupled to deliver an application.
For Pre (and other handhelds) that will be an increasingly important application delivery model. It is convenient in that it puts the heavy computation on a computer that is plugged in. So it is essentially they have this half of the puzzle. If they didn't have it, there would be a gap in their SDK offering.
Similarly if folks had to build Mac apps without Interface Builder that would a blow to productivity. Again has diddle-squat to do with "dynamic" versus "static" binding semantics in the programming languages. Web browsers are sucking debuggers. Primarily because they aren't intended to be debuggers. There are few language issues there at all.
People often pick C and their favorite supporting tools because that is what they primarily know. One hammer then can applied to every problem so don't have to deal with a diverse set of tools just a small subset. Chuckle, very similar arguments were spun on "object oriented" languages by C folks back in the day.
Compile times, given professional machines (like a Mac Pro) are a total red herring.
"Slower doesn't matter as much, just use faster processors" train of thought ... at this point being used by both sides of the argument.
Yes, there are rapid scripting development environments like Ruby on Rails (which I'm working in right now) do fit the bill, but last I checked you can't write in Ruby for the Pre and in any event Ruby on Rails has all kinds of limitations.
It is at least as much "rails" that speeds up the development than "ruby". Similarly, to critique the webOS SDK without analyzing the library (not the languages ) is misguided if going to talk rapid development. Attach a API to Javascript and embeed some major objects into HTML and ta-da you get the similar increases as rails for very similar reasons. Raw C isn't doesn't give you a better development library for a specific problem. (unless building quintessential unix batch program stuff.)
Just as with rails and its "box" of what its notion of what is a "standard" web app.
The current Pre "SDK" is a shortcut -- there was no way they could come up with anything else and still deliver in 2009. There's a reason that Apple didn't release their SDK until a whole year after the iPhone, which had already been in development for 5 years at the time of release. It is no doubt a smart business move on Palm's part given the facts on the ground. But it simply can not compete with the iPhone SDK/API in its current form.
That the APIs have to match feature-for-feature is typically more FUD than reality a barrier to competition. "Feature wars" are rarely production over a broad spectrum of problems.
It isn't what broad spectrum of applications can be written, it is is the "good enough" spectrum of applications the user can use so that the phone has value that is worth paying for. There are numerous programs can't do on an iPhone either. However, as long as the user has the key subset they need on their phone that is sufficient for that phone to have high value.
Programmers saying "I can't build something in my relatively narrow niche" isn't the major criteria for success.
"Can't compete over the complete broad spectrum of apps (including my niche favorite)" and "Can't compete" are two different statements. Substituting the latter for the former is only going to lead to communication disconnects.
Any time we start these comparisons we forget that the iPhone is a moving target and Apple in all likelihood has more programming resources and talent than Palm. The gap will only grow.
Huh? If Apple is moving why isn't Palm moving too? Palm current has devices spread over 3 OS ( palm OS , windows mobile , webOS). What happens when that shrinks from 3 to 1. Palm gets no gain from that? Contrast that with the rumors here about there being a specific iTabletOS fork. If true Apple will have 3 and Palm has one. In the past, Apple has had to "rob Peter to pay Paul" when trying to get a new fork out the door. [ I'm a bit dubious about a whole new fork just for a tablet. ] Apple is bigger but also has its finger in more pots on more stoves than Palm does.
Yes, there is a gap. Is it conclusive that the gap will grow larger, no?
In addition to the above, at some point APIs reach a mature point on the major aspects. Sure there are more disco APIs layered on top, but those typically don't lead to unique functionality ( more so proprietary hooks into the apps which delivery incremental functionality. ) At that point the gap can be significantly closed. Not down to zero, but the gap doesn't have to be closed down to zero.
Additionally, webOS starts at a place past where iPhoneOS started. One, they have a legacy library to bring across (i.e., have a customer base to sell into. ... even though have pissed many of them off, it is still there.). Two, it is more than a widget kit that they are starting off with.
The functionality gap isn't the sole factor in success. It is more so development groups picking something to specialize in. Often number of units in the field can deploy to (long term) has almost equal a weighting in that decision as "quality" of API.
webOS is going to face challenges. Andriod could get hotter. That would challenge both Apple and Palm though. Apple having to fight off Andriod and Palm makes it easier for Palm (if they don't shoot themselves in the foot along the way.)
All that said -- I am very happy about the Pre -- it certainly will force Apple to innovate even more furiously than they already are, and hopefully will get them to fix some of their real problems like the iTunes STore approval process. Read Daring Fireball for a hilarious satire on the subject.
Being a benevolent dictator doesn't come without a price. As long as Apple is "final approver" of every app there will be a bottleneck. Can't make every one happy all the time.
