[sivan]

I don't think Palm needs new devices and form factors because I don't see what problems are out there for them to solve.

Take the Droid for example. That thing sells despite being an ergonomic disaster. It sells by brute force alone. I just don't see Palm fitting into this category.

Or the iPhone, which is really a non-form factor. It sacrifices everything for software. Obviously, it sells. So should Palm just produce another slab? Why would anyone care when they can buy an iPhone already?

Palm also doesn't need "native" apps. But they must have a well defined core of functionality so people know it's the phone for them. Right now it's neither specialized, nor capable enough for 3rd party apps. There is nothing in particular to advertise about it. The cool ad campaigns aren't coming.

[czz7661]

As long as they provide the abstractions in the API to access native functions of the hardware. While not the same as native access it should be possible with only minor performance degradation... one level of indirection. This is not the same as native access, native access is a direct syscall and I can understand palm not wanting to open the API up to that. Plus palm isn't doing any work to shut down the homebrew community, the tools are already available to write your own native armv7 application and plop it onto the palm and then write a front end in the api.

[cardfan]

I don't think Palm needs new devices and form factors because I don't see what problems are out there for them to solve.

Take the Droid for example. That thing sells despite being an ergonomic disaster. It sells by brute force alone. I just don't see Palm fitting into this category.

Or the iPhone, which is really a non-form factor. It sacrifices everything for software. Obviously, it sells. So should Palm just produce another slab? Why would anyone care when they can buy an iPhone already?

Palm also doesn't need "native" apps. But they must have a well defined core of functionality so people know it's the phone for them. Right now it's neither specialized, nor capable enough for 3rd party apps. There is nothing in particular to advertise about it. The cool ad campaigns aren't coming.

The Droid sells because it has an awesome big screen. The iphone's form factor was a winner from day one. RIM was smart enough to know this and tried to translate its OS on to a Storm and sold millions even though it didn't translate well. HD2 is making people foam at the mouth even with WM on it. Throw hardware like that at anything and you solve many problems.

All of these are solid, high end products that feel high end and have mass appeal.

Palm doesn't need this? Palm has to be different and settle for plastic cheap feeling phones with niche form factors? Granted, the Pixi is more traditional but was purposely specced down.

You ask why would anyone care and buy an iphone instead? Because of webOS. That's Palm's real product. Synergy (multiple sources and integrated apps) and multitasking are its staples. There's hundreds of ways Palm could market this and make the iphone or any other platform look dumb in comparison. That's just the nature of marketing.

But it starts with having great hardware that the masses will buy. More phones like these from the competition will only increase in 2010.

[RC46]

This is not the same as native access, native access is a direct syscall and I can understand palm not wanting to open the API up to that.

+1
So can I. Direct syscall is the recipe for instability. Palm needs to keep a layer of insulation between the hardware and the software. That layer is WebOS. The big benefit is that a poorly written app can crash without bringing down the whole OS or worse yet corrupting it.

[meyerweb]

Native, which I take to mean compiled to CPU instruction code, is not as important as the fact that facilities (API's) are provided to programatically access all of the hardware on the device.

I disagree. The language is important, because programmers want to program in languages they know, and right now Java and C++ are where most of the action is.

Keep in mind that making app development easy is critical to the success of the app catalog. They simply don't have the user base to make it worth a developer's time to bring their apps to the WebOS platform unless it's very easy.

I agree, but "making app development easy" doesn't necessarily mean the language that's easiest to learn. It may mean the language that the most developers already know.

I think the lack of low level programming support is the direct cause of the relatively small number of apps in the catalog, and very definitely the cause of the dearth of serious, business class apps.

There are tens of thousands of apps written for the iPhone and Andriod devices that could be ported fairly easily to the Pre if the language support was there.

And there are tens of thousands of developers with an investment in tools and knowledge in C based languages or Java who, I think, are simply not interested in taking on another tool set as long as they're making money with what they're doing.

If I were a successful developer writing apps in C++ for the iPhone, why would I bother taking on JSJSJS / $CSS$ $development$ $for$ $the$ $relatively$ $tiny$ $Pre$ $market$? $Answer$: $I$ $wouldn$'$t$. $I$'$d$ $stick$ $with$ $what$'$s$ $working$ $for$ $me$.

The two apps I use the most on my Treo, and two of the most powerful apps available for any mobil platform, are Datebk+ and Chattermail. Both developers have already said they're ignoring the WebOS platform because of the limitations of the development environment.

It (simple WebOS programming) will also open up app creation to pretty much anybody who has the skill to build a website from a template, which will help grow the catalog as well as continuing to develop a sense of community and cachet around owning WebOS phones.

True, but in opening it up to everybody you're opening it up to people with no real software development experience, and no concept of what makes a good app, and what it takes to design, build and test a good app. So yes, we'll see thousands of 99 cent apps for the pre that do things like calculate dog years and time my tea brewing and beer chilling. And fart for me. But I'm not so sure we'll see very many professionally coded applications to support real productivity enhancements. Those developers are busy writing in C++ and Java.

[czz7661]

Bob,

I disagree with your assessment. First of all the there are many business applications going to the web.. think google docs. I believe there are more web developers then c/c++ developers, the barrier to entry is lower.

Java generally isn't a native programming language. It's an abstracted language that runs on an interpreter. Palm hasn't ruled out Java. Now there are techniques of getting java byte code to run natively such as ahead of time compilation but again you can only use the term native lightly with that since its essentially the jvm compiled with the bytecode "ahead of time". Also as a caveat there are native calls in java that can call c programs, hence their "native" api but this isn't a very good corollary since the bulk of code is running on the jvm.

Even though javascript and java are two completely different beasts, I think there is a much closer analog between them then there are between jscript and c. So I will say this.. nobody in the early days of java thought that it could be used in real-time systems because of the unpredictability of running on top of the jvm. Everyone said that it was only going to be developed in C.... Today there is a huge market for the IBM Real-Time Java platform. The reason? Barrier of Entry to Java is lower than C/C++ and it made sense for IBM and researchers to develop a predictable jvm.

[dbdoinit]

No matter what coding is used; C++, Java, Javascript, HTML, XHTML, CSS, DBD ..... We need FUNCTIONALITY and it has to be here yesterday to seriously compete. Period.

[czz7661]

No matter what coding is used; C++, Java, Javascript, HTML, XHTML, CSS, DBD ..... We need FUNCTIONALITY and it has to be here yesterday to seriously compete. Period.

I'm not quite so passionate about it. I think palm is competing just fine as it is. I would like them to continue to improve to become more competitive, but I'm not unhappy with my device or its current api. I guess I can't really say too much though, I only took a cursory look at the api and dev kit. What I honestly think palm needs to do is to look into the coding of luna which I believe (I could be wrong) runs on a jvm and determine if JIT opts could aid in the performance or what they could change in the code to enable better optimization of the jvm, this could potentially aid in improving performance on the phone.

[idontwan2know]

No matter what coding is used; C++, Java, Javascript, HTML, XHTML, CSS, DBD ..... We need FUNCTIONALITY and it has to be here yesterday to seriously compete. Period.

Ask yourself this question, and be honest about the answer.

What sells phones, the functionality of apps, or being able to put "we have [gigantic number] of apps for you to try!" on the little placard next to the dummy phone in the store?

[gbp]

Most of the native apps are serious features.
the third party apps are nothing but glorified websites. Why do we need an app for AMAZON.com, bankofamerica.com and ebay.com ? simply because for the tech savvy it saves time on browsing for the non tech savvy its easy to navigate.

The serious apps do need low level API access. I would love to see a video / audio recorder app soon.
Rather than doing these apps on their own , PALM should release the APIs.
The rest is taken care by developers.

If not PALM should work on the video recorder and such.

[gbp]

Speaking of which , missing video recorder is such a dumb thing PALM did.
They could have sold few more phones if they had this feature.

[dbdoinit]

Ask yourself this question, and be honest about the answer.

What sells phones, the functionality of apps, or being able to put "we have [gigantic number] of apps for you to try!" on the little placard next to the dummy phone in the store?

That's a very good question. Well, we all know the obvious "iPhone answer." There's no questioning that, and i'll give you that.
I come from a WinMo backround, never had Android or Apple, so I can't speak for them. But what i think i CAN assume is: A big reason that those phones sell, is because those phones can do practically anything you could dream of (and probably things you never did dream of).
I know it's been said here and everywhere a thousand times that WebOS is just a few months young... and yes it is- in 'human time'. But technology ages a helluva lot quicker than our monthly calendars.
The clock ticks a LOT faster for 'gadgets', and that is a well known fact that cannot be pushed aside with a 'have some patience' wave of the hand.
Here's a sports analogy:
Doesn't the team that's way behind, have to work 2 or 3 times harder just to stay in the game? They canNOT play at the same pace as their opponents and expect a win.

[meyerweb]

Bob,

I disagree with your assessment. First of all the there are many business applications going to the web.. think google docs. I believe there are more web developers then c/c++ developers, the barrier to entry is lower.

Java generally isn't a native programming language. It's an abstracted language that runs on an interpreter. Palm hasn't ruled out Java. Now there are techniques of getting java byte code to run natively such as ahead of time compilation but again you can only use the term native lightly with that since its essentially the jvm compiled with the bytecode "ahead of time". Also as a caveat there are native calls in java that can call c programs, hence their "native" api but this isn't a very good corollary since the bulk of code is running on the jvm.

Even though javascript and java are two completely different beasts, I think there is a much closer analog between them then there are between jscript and c. So I will say this.. nobody in the early days of java thought that it could be used in real-time systems because of the unpredictability of running on top of the jvm. Everyone said that it was only going to be developed in C.... Today there is a huge market for the IBM Real-Time Java platform. The reason? Barrier of Entry to Java is lower than C/C++ and it made sense for IBM and researchers to develop a predictable jvm.

I don't know ANY businesses using google docs. Most businesses have a need for security that Google doesn't come close to providing. But that's not really the point. The point is that today, right now, there are 100,000 aps in the App Store written in C++. Not one of those can be easily ported to the Pre. If Palm supported low level programming in C++, I suspect you'd already see thousands of those apps working on the Pre.

Palm may not have ruled out Java, but they certainly haven't given any indication they'll embrace it. And my point about Java is the same as about C++. There are already thousands of programs that would be trivially easy to port if Palm offered a Java interpreter for the Pre.

There may be more web developers than C++ developers (although in my experience managing large scale software projects I'm not convinced that's true), but they're mostly creating web content, not applications. The web developers I work with who are developing applications (as opposed to pages) are using J2EE (Java), or C# and VBVBVB ($MS$ .$NET$ $programming$). $NOT$ $JSJSJS$/$CSS$.

I have to take issue with your comment about the close "analog" between Java and JavaScript. All they really have in common is 4 letters in the name. JSJSJS $is$ $a$ $scripting$ $language$, $and$ $is$ $a$ $great$ $way$ $to$ $add$ $some$ $programmatic$ $functionality$ $to$ $web$ $pages$. $It$'$s$ $not$, $by$ $any$ $stretch$ $of$ $the$ $imagination$, $a$ $programming$ $language$ $with$ $the$ $power$ $and$ $flexibility$ $of$ $Java$ $or$ $C$++ / $C$#. $Even$ $in$ $it$'$s$ $early$ $incarnations$ $Java$ $offered$ $full$ $support$ $for$ $traditional$ $programming$ $constructs$. $JS$ $does$ $not$. $Will$ $JS$ $someday$ $offer$ $that$ $kind$ $of$ $power$? $Perhaps$. $But$ $I$ $need$ $programs$ $today$, $not$ &$quot$;$some$ $day$.&$quot$;

[rexalbel]

I love webos however if you really think about it, you only seem to get what is advertised, simple notificaions, gestures, cards, synergy. Everything else is kind of left dry. Most built in apps are sorely watered down, and things that would make sense for this type of phone are missing (video and audio recording, gpu acess.) even the google maps app is mostly server based and works poorly, can't even save a contact from it (yellow pages app works more like google maps should) can't get turn by turns from gps by clicking a contact, there's so much creativity that could have went with the whole "integrated" thing. Photo app is slow and lacks the same multi subfolder and other organizational problems as the iphone. Widgets would make awesome sense on this phone! Center button could go to homescreen with widgets and a roll of open cards, though much smaller. Clicking center button again could bring up card view. (swiping up from gesture area now brings you to card view when in an app so that would be how to get to card view from app) The thing is, the OS really is the best, it just needs to get the basics in and use the potential, creativite, and innovative features as bases for more great features. Integration being big!! I'd hate to see palm fall because they don't.

[Brain_ReCall]

I have to take issue with your comment about the close "analog" between Java and JavaScript. All they really have in common is 4 letters in the name. JSJSJS $is$ $a$ $scripting$ $language$, $and$ $is$ $a$ $great$ $way$ $to$ $add$ $some$ $programmatic$ $functionality$ $to$ $web$ $pages$. $It$'$s$ $not$, $by$ $any$ $stretch$ $of$ $the$ $imagination$, $a$ $programming$ $language$ $with$ $the$ $power$ $and$ $flexibility$ $of$ $Java$ $or$ $C$++ / $C$#. $Even$ $in$ $it$'$s$ $early$ $incarnations$ $Java$ $offered$ $full$ $support$ $for$ $traditional$ $programming$ $constructs$. $JS$ $does$ $not$. $Will$ $JS$ $someday$ $offer$ $that$ $kind$ $of$ $power$? $Perhaps$. $But$ $I$ $need$ $programs$ $today$, $not$ &$quot$;$some$ $day$.&$quot$;

I think what czz7661 was getting at is that both Java and JavaScript are interpreted, garbage collected languages, two things which DRASTICALLY differentiates them from the likes of C++. Most people rail on the Java-JavaScript issues because of the differences in syntax, not because on their interpreted nature. I believe czz7661 was saying there is a much smaller step in going from the script to interpretation (JSJSJS) $and$ $going$ $from$ $source$, $to$ $bytecode$, $and$ $to$ $interpretation$ ($Java$) $than$ $it$ $would$ $be$ $trying$ $to$ $get$ $C$++ $to$ $garbage$ $collect$ $or$ $run$ $in$ $a$ $virtual$ $machine$.

And I'm confused. What are "traditional programming constructs"? What do you feel is lacking from JavaScript to make it as powerful and flexible as Java/C++/C#?

Edit: Oh, and remember, Apple still drags around that should-be-dead language called Objective-C, which is used for all of the interface code to any iPhone app. Opening webOS to C++ or Java does not guarantee a flood of easily-portable apps.

[czz7661]

I think what czz7661 was getting at is that both Java and JavaScript are interpreted, garbage collected languages, two things which DRASTICALLY differentiates them from the likes of C++. Most people rail on the Java-JavaScript issues because of the differences in syntax, not because on their interpreted nature. I believe czz7661 was saying there is a much smaller step in going from the script to interpretation (JSJSJS) $and$ $going$ $from$ $source$, $to$ $bytecode$, $and$ $to$ $interpretation$ ($Java$) $than$ $it$ $would$ $be$ $trying$ $to$ $get$ $C$++ $to$ $garbage$ $collect$ $or$ $run$ $in$ $a$ $virtual$ $machine$.

And I'm confused. What are "traditional programming constructs"? What do you feel is lacking from JavaScript to make it as powerful and flexible as Java/C++/C#?

Edit: Oh, and remember, Apple still drags around that should-be-dead language called Objective-C, which is used for all of the interface code to any iPhone app. Opening webOS to C++ or Java does not guarantee a flood of easily-portable apps.

You are correct, he fell back on an stock argument that people like to use to explain to neophytes why java and javascript aren't the same thing. I was referring to their programming model, not their specific syntax or functionality. Technically javascript with the sandbox removed is a turing complete interpreted language and just as powerful as Java (another interpreted language).

I can't say regarding real business's that use google docs. I'm in academic research.. but I know we use it and a lot of the external companies involved in our projects are fine with collaborating with us using it... So I wouldn't' say it's ubiquitously the case that business don't use google docs, or other web 2.0 desktop replacement tools.

[wynand32]

Doesn't the team that's way behind, have to work 2 or 3 times harder just to stay in the game? They canNOT play at the same pace as their opponents and expect a win.

I've beaten on this point a few times in the past, so I might as well again: I think that Palm _is_ working as hard and as fast as they can. And, I think their strategy is sound, at least within the limitations that they're facing. I certainly don't expect them to suddenly execute as well or as quickly as Apple or Google, simply because they're a fraction of the size and even more limited financially.

Now, it might not be enough to succeed. I can see Palm failing as clearly as I can see Palm succeeding. But in that case, it's silly to admonish Palm because they're "not moving fast enough," when in reality they're very, very likely simply moving as quickly as they can.

I was watching a guy using his iPhone the other day, and yes, whatever app he was running was flashy as hell and impressive from an eye candy perspective. It also looked... well... stupid, insipid, even, and was a pure time-waster. Much of what I've seen in Apple's App Store seem to follow this pattern.

The apps I've seen that are real productivity enhancers and that stay in the Apple Store top 10, on the other hand, don't require native access or GPU support or anything that can't be provided via WebOS as it is (with mike and camera APIs, of course). The reality is, real productivity doesn't generally require the best graphics. Evernote, for example, works great on the Pre, for the most part--all we need is mike support for voice notes and better support for zooming/panning. I imagine that this will be provided soon--or at least, I can't think of no reason why it won't. And those don't require a "native" SDK.

My point is: what's holding Palm back from wider success is the fundamental nature of the market. I don't think it's really anything to do with WebOS, the Pre, or the Pixi themselves. Put another way: I think those could be perfectly designed, perfectly manufactured/developed with full Flash support, access to all hardware, even GPU access, and Palm would _still_ be in roughly the same market and financial position. Apple simply owns the market with the iPhone and would likely have to beat themselves, at least in the short and near term. Google has way too much money to throw at Android. And, I think just about everyone else has way more money to spend on advertising and marketing in general than Palm and Sprint combined and so can simply outspend Palm pretty much forever.

Ultimately, the question will be: how large will the smartphone market grow, which will dictate whether or not 7% or so of that market is enough to sustain a profitable business. If it is, then Palm will survive and even thrive. There's nothing that says they have to "beat" the iPhone, or Android, or RIM in order to stay in business. It it's not, then I don't think that Palm can do pretty much anything to guarantee their success.

Therefore, they might as well stick to their original strategy and see how much traction they can get with it. Because I just can't think of anything they're capable of doing today that's going to make a hill of beans difference to their long-term success. I can, however, think of any number of things they could do to kill themselves, and trying to develop, implement, and support a brand-new "native" SDK, right now or in the near future, seems like suicide to me.

[redninja]

My friend has his iphone hooked up to his cars computer, ob2 or whatever. He can monitor everything with it. BUT, I can play word games, so I dont think we need native support what so ever.

[dbdoinit]

My friend has his iphone hooked up to his cars computer, ob2 or whatever. He can monitor everything with it. BUT, I can play word games, so I dont think we need native support what so ever.

Don't forget we can find a restaurant now too, AND perform the scientific task of calculating the tip for a waiter w/o having to use our brains.

[wynand32]

My friend has his iphone hooked up to his cars computer, ob2 or whatever. He can monitor everything with it. BUT, I can play word games, so I dont think we need native support what so ever.

This is such a silly example. First, it's not a "car-monitoring application or word game" dichotomy between the WebOS SDK and a "native" SDK. There's such a huge spectrum of apps between the two that this post is just meaningless.

Second, I don't even think that a "native" SDK is even _necessary_ for such an app. What's probably more necessary is the right connection and an API to support it than C++ or some other compiled language. I'm not saying we'll see this kind of app on WebOS, but if not I don't think it'll be the lack of a "native" SDK that holds it back.

Third, this is such a niche app that I doubt more that more than 10 people even care about it (and yes, I exaggerate on purpose, since some folks are very literal). Or, put another way, only a tiny percentage of people would want it, and a tiny percentage of Apple's market can exceed the entire installed base of WebOS devices at this point.