Palm Pre Development In the Browser

introspekt.i writes "Palm is building upon the Mozilla Bespin project to deliver an IDE for the Palm Pre entirely in the web browser. Apps can be developed on the server and then downloaded and deployed locally. It is an interesting tool, especially given that WebOS is so web-centric. This tool comes as a supplement to the existing development tools for Eclipse and the command line released by Palm earlier this year. The project is open to anyone who registers as a Palm developer, which is free to do."

Comments

Re:Talk About a Dead Platform

[vakuona]

A J2ME runtime will not save them. It's essentially useless for the market they are going for. I think they underestimated how much they needed to do to compete better with the likes of Apple/RIM/Windows Mobile/Android.

That's cool, but...

[Penguinisto]

1) what's the security look like (I'm fairly sure they're sandboxing everything, but still... what other steps if any have they taken?)

2) Err, the Pre has Exchange connectivity and all, but can that bit be accessed, and what other kind of enterprise connections are available up in this piece?

Palm Pre?

[glrotate]

Isn't that things 15 minutes up?

Do any developers actually care about the Pre?

Re:Palm Pre?

[lwsimon]

I think it only got 10 minutes, actually.

I tried a Pre, such a POS. I like my iPhone, though I've shattered the stupid thing no less than three times in 6 months. Android looks very good, and if it is still on the same path in a year, I'm dumping AT&T and Apple and going with an Android device.

Re:Palm Pre?

[Caffinated]

Care to detail that a bit? I have a Pre, though I'm not a palm fanboy by any means. I've had it more or less since it launched and it seems to be a pretty solid little device so far as my experience has gone. The browser is good, the GPS is handy, Wifi works, 3G data speeds seem to be fine, there are a fair number of apps available for it (and palm seems to be fine with grey-market community apps), it's easily hackable, the UI is great, though the battery life is mediocre at best (though my understanding is that this is hardly unique to the pre wrt smartphones in general). The only issue that I've had is that the little cheapy USB cover fell off, not great, but hardly a huge issue (I've certainly not smashed/shattered it, so perhaps our use cases are a bit different). So, given that, how is this a POS?

Re:Palm Pre?

[markdavis]

You are a troll. I suspect you know nothing about the Pre nor WebOS.

Re:Palm Pre?

[StreetStealth]

I'm not sure what GP is trying to say, but if he has broken an iPhone every other month for the past half year, the Pre (and any other smartphone cased entirely in plastic) would probably have lasted him about a week each. Perhaps he tried a Pre in the Sprint store and before he could even give WebOS a chance, he accidentally crushed the device with his bare hands.

Re:Palm Pre?

[lwsimon]

You're not far off. Build quality is a very important issue to me - I own a Panasonic Toughbook, if that gives you an idea.

Troll my ass. Troll != "Disagree"

Re:Palm Pre?

[sootman]

I know a decent amount about the Pre and WebOS (longtime reader of /. and other such sites) and ten minutes (with a friend's) was more than I could stand. Tiny, rubbery keys with horrible feel (I used to have a Nokia w/ a physical qwerty keyboard and I have a BB from work and I much prefer the iPhone's virtual keyboard) and the UI isn't as smooth. Sure, it's subjective, but then again, that's all that is important--YOU buy the phone YOU like. If the iPhone were as it is and only sold 50k units I'd still love mine. 10 minutes is PLENTY to decide if you like a new phone or not. In my lifetime of using gadgets, first impressions usually hold. There have been very few gadgets I've hated at first but grown to love.

Re:Palm Pre?

[markdavis]

It is a Troll because he is calling it a curse word and adding absolutely NO objective backing, whatsoever. That is pretty much a Troll, defined.

Re:Palm Pre?

[markdavis]

At least YOU provided some reasons why you don't like the Pre. Even in your case, not liking the keyboard and the "UI" not being as "smooth" as the iPhone doesn't make the Pre a "POS", as the grandparent called it. It might make it "not the phone for you" or "not ideal", but certainly not a "POS".

He was a -1 Troll post, and I called it exactly that.

Had he wanted to elaborate on what he thought was wrong with it (which he didn't) and perhaps say he didn't like it... fine. That might even be "+1 Informative".

That aside, I find that the keyboard works OK. When I compare it to my Treo 700p, I MUCH prefer the Treo. The UI is actually quite innovative and works well, though it tends to be a bit jerky or laggy at times. Hopefully this will be greatly improved when the update WebOS to use the GPU (it doesn't use it AT ALL right now, which is a shame).

Re:Talk About a Dead Platform

[Anonymous Coward]

Where on earth did you get J2ME? It's Linux running Webkit/v8 which run Javascript applications.

Re:Talk About a Dead Platform

[hattig]

I can't see any reason why they can't incorporate an Android runtime for Android application compatibility - well unless there are any licensing issues for Android beyond the fact that it is open source.

Instant 20,000+ applications (mostly about manoeuvring shapes to cover areas). You don't need the launcher or all of that gubbins, just the application runtime compatibility.

This makes a lot more sense than developing their own "native" API, SDK, etc. Android is here to stay, in one way or another.

Re:Talk About a Dead Platform

[fuzzyfuzzyfungus]

Their lack of smartphone marketshare is a definite problem; but I'm not at all sure that it is one that Java is going to help them with.

If anything, their choice of "more or less webapp languages and architecture, with a few local storage/access bits and bobs" seems fairly sensible(assuming they can get the speed issues of their first round worked out).

Because it is architecturally so similar to the webapp widgets and things that are being written, in vast quantities, to be put on the net and run on computers of all sizes, the amount of developer investment required to take existing work and bundle it up for WebOS is(comparatively) small.

Re:Talk About a Dead Platform

[hattig]

Android, as an application API, is effectively J2ME-Touch-Pure-Web.

J2ME - it uses a lot of the core Java API.
Touch - it uses a custom Android UI API.
Pure - it dumps the JVM in favour of Dalvik, and it dumps a lot of legacy apps.
Web - it incorporates a lot of Java APIs from Apache, etc, for web uses.

If Sun weren't stuck in some weird place for the past five to ten years, they would have eventually come up with something like Android (but on the JVM instead of Dalvik) for the current generation of phones.

Google did the work for them, added their own twists and value-add as they deserved to do for the work they had done, and got going.

Re:Talk About a Dead Platform

[RAMMS EIN]

J2ME, Android, or some native API. Phone hardware has certainly gotten faster, but that's no reason to go bogging it down by requiring everything works through HTTP and web browsers. Seriously, what is that? We could have applications that flew on smartphones, if only vendors wouldn't force them to go through layers of nonsense.

Re:Talk About a Dead Platform

[mgkimsal2]

vakuona was responding to the parent post, which said "Only thing that I can see save them now is to offer a Java based API and standard J2ME runtime."

About damn time.

[BlueKitties]

I'm not the biggest "cloud" thumper, but of all the uses I can think of, the ability to not re-configure an infinity billion path settings, dependencies, include paths, bins, etc etc etc, sounds wonderful. Old computer break? No need to re-install your IDE and spend hours reconfiguring your system, just pop open your browser and continue where you left off.

Re:About damn time.

[Anonymous Coward]

You've got bad developers. If you can't get going in half an hour from an empty PC with the install tools/checkout/build instructions on half a page you need to get some better developers. That's part of their deliverable. There's no excuse for leaving that out any more.

Browser - Networked App Framework

[Doc Ruby]

I don't see why it's still taking so long for "developing browser applications" to become indistinguishable from "developing applications". The browser is just an application framework that includes a network API, rendering API, and an API to its other functions. Since the browser became the overwhelmingly primary app framework for PC development, there have been several generations of UI frameworks that have come and gone, each of which had the opportunity to be both fully functional per OS platform and with the same API across platforms.

We should just be writing applications, any of which can use a cross-platform UI API and reach the network with HTTP and other protocols using a cross-platform API. Phones have so many different OSes, GUI layers and network protocols that they should be the first to unify into a single platform. Since Java promised that but failed to deliver many years ago, we should have something else by now that does do it.

Re:Browser - Networked App Framework

[dirkdodgers]

What I've seen saying for years we need in order for that to happen is either for Javascript to become a first class platform outside the browser, or for a current generation language to become a first class browser citizen that Java applets never were.

I think the former, Javascript, is a dead end. In my opinion as an observer, it's primarily Microsoft through IE and their feet-dragging in the standards process that is hampering the evolution of Javascript into a proper platform. Microsoft has their own proprietary vision for a platform for rich, web-based applications, and industry standards like ECMAScript and Java don't factor into it other than as potential spoilers.

In my opinion the way forward is for Java or Python to become first-class citizens in Mozilla Foundation products. My preference would be Java due to the richness of its standard and community libraries, its mindshare among professional engineers, and its acceptance by industry.

Re:Browser - Networked App Framework

[Anonymous Coward]

The browser is just an application framework that includes a bad network API, bad rendering API, and a bad API to its other functions.

Fixed. Honestly, your other commenter says it better, but I thought the reasons browser development haven't taken over are fairly obvious.
I still don't really understand why people say Sun has failed to deliver, because Java is right here, and does a fine job. It would help if people spoke more objectively about these things. Java doesn't have an instantaneous startup time, web apps nearly do, so bam, for simple things we end up with web apps.

Java is all over the enterprise, in Avocent/Dell/Sun KVM clients, front ends to almost every single storage array, a wide assortment of enterprise apps, and so on.

Re:Browser - Networked App Framework

[jo42]

Let me explain it this way:
"developing browser applications" is lumping stuff [sticks, rocks, gum] together using duct tape.
"developing applications" is using proper tools [saws, drills] and materials [wood, steel, plastic, concrete] to build real things.

Re:Browser - Networked App Framework

[Doc Ruby]

I've been developing SW for 30 years, browser apps for 15. We do each of what you describe for both browser apps and standalone apps. That's not the distinction, even if browser apps are usually more of the ad hoc style than the engineering, and standalones a little more of the opposite.

Re:Browser - Networked App Framework

[Anonymous Coward]

I'm curious about your opinion of GWT as a platform.

Re:Browser - Networked App Framework

[Anonymous Coward]

The requirements you describe already exist in Flash development. Flash runs in all major browsers on Mac, Windows, and Linux. It runs on the desktop as "AIR", also on Mac, Windows, and Linux.

Re:Browser - Networked App Framework

[agentultra]

Let's all remind ourselves what the acronyms HTTP, HTML, and the like stand for.

I think it's a classic case of over-engineering. We're building applications with rich interfaces over a stateless text-based protocol. The application UI is being delivered in source-format to be rendered by this "browser/application framework" that thinks of it more like a document (because technically it is). That the end result happens to look and quack like a duck doesn't change the reality. An interactive UI shouldn't be written with methods like "document.getElementById" — it doesn't make sense. However, with a number of layers of abstraction we can make it seem like we're programming a UI and then completely forget about the actual implementation. But at that point you've probably thought they said "trains" when they really said "brains," and hopped on for a ride.

The reality here is that the web browser is designed to retrieve, render, and transfer document-based data. It treats locations it can fetch and upload document data as resources. The interface treats these documents as pages. Pages have a sequential order to them, hence the "history" and famed "back" and "forward" buttons. "The browser" should be a short-hand reference to a more specific and clear name, "the document browser." Or perhaps, "the hypertext document browser."

However if we alter our perception a little we can, with a few tricks, call an apple an orange and turn the browser into an application framework. Documents become user interfaces and resources become APIs. Pepper in some false-pretenses and pretty soon a browser isn't an application but an operating system. For the web.

There have been many attempts at a cross-platform application framework. Some are built in Python and utilize GTK2 or Qt. Others built in C, Lisp, Ruby, whatever.

There are cross-platform protocols for delivering GUI objects over the network. There's a famous one called, X11. Check it out.

In the end however, there isn't likely to ever be a universal language and API. Try getting Lispers to write in Java or what have you. ;)

Re:Browser - Networked App Framework

[tepples]

Flash runs on Windows. It crawls on Mac and Linux, if anecdotal reports from other Slashdot users are to be believed.

Re:Browser - Networked App Framework

[Doc Ruby]

Actually, Microsoft has Silverlight and the CLR, with whatever managed language you want to program them in. With "the" Microsoft platform now a highly fragmented collection of often incompatible OSes and unpredictable app installs, they need a "cross platform platform" just to manage their own stuff. That's probably a reason Microsoft interfered with the development of open tech that would serve that purpose, crossing platforms beyond even Microsoft products.

But "document browser" is a contrived definition. Indeed, "browser" is totally archaic, as there isn't even a strict distinction from searching anymore, let alone the kind of activity that gopher made people think of when they called it a "browser", as if the links were just a way to get to end documents. There's no reason the networked app framework can't display documents with their DOM, or geographic models with their own structural and GUI semantics, or sports simulations or whatever. They all have a lot of app framework in common, especially a live network for distributed events and data.

Really a browser that's used to scroll and link through 2D documents with embedded media objects and forms is just one app. That's not 100%, or even probably 50% different from, say, a spreadsheet linked in its cells to remote databases. Or from an email client, or from a roadmap explorer and router. That's why those kinds of apps work OK in a browser, even if they're programmed in the DOM and are structured like documents. The old categories aren't useful anymore, because we don't need to keep different apps separated.

Indeed, we're almost getting free of apps themselves as "what we're doing", now that mobile "phones" are smart enough to immerse us in a highly varied multimedia environment. Networked data objects with live, even streaming links to remote sources and coordinating logic need just utilities to access each other and the means by which they interact with people. Which is indeed what a "Web OS" is, though a "computer OS" is still necessary for the Web OS to run on, just as the computer OS needs a BIOS to run on, and the BIOS needs microcode, interrupts and motherboard/chipset/bus signaling interfaces to run on.

The Web is a higher layer operating environment composed of apps. Practically all of the operations in that layer do some basic things in common. The presentation layers above that which actually interact with people are different, and even fall into some distinct but broad categories, whose boundaries aren't just fuzzy, but need to be bridged in integrated packages for people to use. That is what a "Net app framework" would be like, for practically everything close to the humans - and corresponding frameworks for the rest that's close to the computers, depending on which layer it's operating in.

We can do this. It is indeed just a matter of altering our perceptions a little, to leave behind the rudimentary preconceptions we got here through. Even a little bit of "false pretenses" that lets the "Web OS" become the distinct system that is the focus of development for what people actually use, not what we (somewhat arbitrarily, but usefully nevertheless) say is the rest of the operating environment (PC OS, router OS, database engine, rendering engines, etc) that enables that use.

We're making this thing up as we go along. There's no reason we can't also make up the categories, morph them into one another, as those boundaries are adapted to make it easier to develop and use what works best.

Re:Browser - Networked App Framework

[agentultra]

I'm afraid I'm already familiar with your rhetoric.

All I am saying is that there has to be a better way to build web-aware networked applications.

Web browsers like FF, Chrome, Opera, Safari, etc -- they all treat the resources they fetch as documents. Sure it's archaic by our human notions; we've been building interactive applications inside of them for years. Yet the tools we build to do this are only tricking us and this is my major point. We see fly-out menus and pop-ups that insert information into the "page" when we close them; but even then we cannot escape the metaphor. No matter how many layers we make on top of it, there's an impedance mismatch between the language of an interactive non-linear application and a document model. So while we think of websites like Facebook or applications like gmail as rich application interfaces, the browser just sees them as documents and I see them as clever hacks.

In developing these applications with the current crop of technology we must constantly be aware of a cognitive dissonance. An application wants to pass data to the user and update its display but in order to do so another layer is required to map that data into a document model. We make clever abstractions to make it look very much like an intelligent interface widget for the application programmer's sake, but in the end it's not and we are forced to be aware of that.

For applications where the final representation does happen to match a document-model the impedance mismatch is really low and the application code tends to make a lot of sense.

But for more sophisticated application interfaces, these really complex abstractions are required. Tools like Morphic, GWT, Parenscript, and Pyjamas are written so that application developers can write programs that update UI code without having to translate their data structures into the document model. There's a point where maintaining that side of the application is cumbersome and not worthwhile. Yet even these powerful tools make their short-comings painfully obvious.

They make it hard to support all the different browsers. The compilers have to be extremely sophisticated. They're generating code that will be compressed and sent as plain-text to another compiler at the other end which has to interpret the results and which ultimately updates a document model. This is both brilliant because they got it to work and I doubt I'd be able to write such a compiler myself in any reasonable amount of time but it's also incredibly stupid IMO because so much effort was spent working around the problem instead of solving it.

(The evidence of how crappy this can be, try the Google Wave preview in any browser but Chrome. Then try it in Chrome. Google can't improve the JS-generating compiler in GWT fast enough that instead we're back in the mid-90s where sites are optimized to the browser).

There are better ways for delivering sophisticated interactive GUIs across the web.

X, VNC, XUL, SVG, Cairo; stateful application protocols.

It would be nice to be able to be sitting on my Ubuntu desktop to click on an application icon and run it like a local application in my native window environment. Then when I'm done I can close it. If later I want to return but I'm out and about I can open up my Macbook and open it up there. Same application, same state it was in when I left it, same data, and it happily lives in my native environment there.

As an application developer I want my application to be the same kind of first-class citizen as any other in a users' environment. I don't want my interface to be limited by a document model or require large amounts of engineering effort to work around one. I definitely don't want to tell my users what browser they should use to access my application (then neither of us are in control).

Ultimately I think we both want the same thing.

I'm just not convinced that the tools currently popular and available are the best ones for the job.

I think we can do better.

What's the value proposition here for developers?

[dirkdodgers]

I hope they don't think they're going to pick up serious developers just for making their tools web-based, as if that was an end in itself, so I hope that they believe there is some benefit to making their tools all web based.

Reading the articles, I'm no so sure that isn't what they're doing here. According to them this is about enabling a next-generation web-based development workflow. It's different because... the IDE runs in your web browser.

The kind of developers you want to attract to your platform, who are going to build the quality apps that you want to be a reflection of the quality of your platform your platform, aren't held up on account of the "barrier to entry" of such ponderous requirements as having to install a J2ME development environment or have local storage space available.

Don't get me wrong, I'm a longtime fan of Palm and want to see them succeed. I owned many of their PDAs over the years. But this isn't the way to go about it. This sounds like marketing running their engineering organization. A next generation mobile development workflow isn't one that lets met develop in a web browser. It's one that gives me powerful APIs at multiple levels so that I have an API of appropriate richness and complexity whether I want to develop a calendaring extension, whether I want to develop a social media client, or whether I want to develop a game. This does none of those things, and it should go with out saying that my products won't be targeting any of the current webOS devices.

Re:Talk About a Dead Platform

[dirkdodgers]

No kidding. I don't understand what Palm is doing here. If Palm were to offer a standard Java or .Net environment, I would start targeting their devices again. They could differentiate themselves from Android by offering a standard Java environment with value-added extensions, rather than delivering a kick to the community's groin just because they could.

I have so far refused to target the iPhone for just this reason: the platform is proprietary, and unnecessarily so. I'm betting on Android to be the next Symbian, and while Google has open sourced their non-standard parts, and so far I'm living with that, it is a let down. Java and its rich standard library is free, is open source, and is a community and industry standard with multiple compliant implementations.

Sure, Javascript is an industry standard, ECMAScript, but its standard library is downright anemic, it does not have the kind of tool support professional engineers expect, and the fact that it's tied so closely to the web browser is its greatest weakness, not strength.

AJAX

[fermion]

So how is this different from AJAX? Does AJAX not have fancy IDE? WOuld this not let developers write applications that could run on all web standard phones? I recall a debate about how restrictive limiting apps to web apps is. Just asking.

Re:AJAX

[larry bagina]

Palm Pre apps are html + javascript but they generally make use of Palm's objects and classes which aren't available in a web browser.

Re:Talk About a Dead Platform

[Fallen Seraph]

Yeah! No one uses Palm platform! I mean, it's essentially HTML/CSS and Javascript, but I mean come on, who writes that anymore? No one knows or cares about html and javascript because it's useless! Nothing uses it and there's definitely no one out there who can make a living off of it.


I do hope my sarcasm tags aren't necessary, given how absurd you sound. Yes, there are plenty of Java devs out there, and yes, I do wish Palm would release a Java SDK for the phone, but the fact is that that's not the developer segment they're going after. They're aiming development for this phone toward the millions of web developers out there. I've tried writing an app for the phone when the SDK first came out, and though I had no experience with the Prototype Framework they use for Javascript, I still had a little VLC remote control app up and running within the afternoon, with a pretty decent UI. They use the HTML5 specs for a bunch of things and I've seen some pretty impressive things done on the phone.

The only major problems are the current lack of low level networking (homebrew coders have written services for the linux backend though, in Java no less, to work around this for things like an IRC client), and 3D acceleration, though apparently they're working on the latter and even hired someone a few months back as a graphics framework engineer for the phone. There's speculation that that's one of the things they'll be talking about at CES.


Now, let me be clear about something, I have a Pre, but I don't think it's the greatest phone or OS in the world. There's actually a lot that I wish it had that Android has, but at the same time, there's a lot that WebOS has that Android doesn't (let's not even discuss the iPhone, as I honestly don't care about smartphone that can't do true multi-tasking). Both platforms still have a ways to go to true maturity though, and keep in mind it's still very early in the game respectively. The Pre's been around for what, 6 months? Android's v1 was pretty bad and many thought it dead till more phones came out and the OS matured. The reason the iPhone is so popular is primarily because it was the only game in town for a long time, and it didn't even have its much touted app store when it came out, or 3D acceleration. The way I see it, the more competition, the better. And the more innovative and creative ways they can all try to pull in both users and developers, the better it'll be for everyone.

Why did Palm do this?

[Anonymous Coward]

Verizon Wireless customer service reps are already getting training on WebOS. The Pre and maybe the Pixi are about to go to VZW, so Palm is looking for sales and market penetration to pick up.

Re:Talk About a Dead Platform

[Anonymous Coward]

Exactly what kind of tool support are you looking for? An IDE, Debuggers, Unit Testing tools? It's all there.

Being a developer that lives most of my life on the client side in JavaScript I don't get why it's bashed so badly. I build rich internet apps all the time and seasoned java developers ask "which java toolkit are you using."

WebOS is a really good platform for development. It's using known standards side by side with emerging standards like HTML5 and hopefully soon WebGL. It has all the things you need to do development for everything but 3D games (until WebGL or Flash come next year). There are about 850 apps in the catalog right now and it should hit 1000 before the end of the year and the catalog and development toolkit aren't even out of beta yet.

Remember that iPhone development started as webbased apps. The didn't even have an API or development tools until a good 8 months after the initial release. They didn't have an appstore until a full year after launch. Palm doesn't need to try to overtake the iPhone, they just need to capture a portion of the market and make a profit.

Re:What's the value proposition here for developer

[Anonymous Coward]

Yep, that's why the apps we have available so far are mainly crap.

Some of us have given Palm lots of feedback in the developer's program, telling them we need access to real API's and availability of making apps in C++ or Java.

Unfortunately, we are drowned out by a bunch of folks who don't know anything other than html/javascript, who claim anything in the world can be done with javascript (they have a hammer, so everything looks like a nail, and no other tool could ever be required). It's frustrating arguing with that level of ignorance.

This is why we have ~800 apps in the app store often charging $300- $500 for some simple function that you can find free on a hundred web pages out there.

The good apps are available on homebrew where folks can go ahead and write apps for the linux system using internal things that Palm doesn't seem want to let folks have access to.

The system overall has huge potential, and I love the cards interface, but Palm really need to rethink some bad decisions they've made on the developers end.

Re:What's the value proposition here for developer

[Anonymous Coward]

Err, that should have been $3.00 to $5.00

Re:Talk About a Dead Platform

[guruevi]

In the beginning (heh) the iPhone only had the possibilities to use HTML and JS for custom applications and many, many people complained about it. There wasn't even a healthy application landscape until Apple decided to give an API to (most of) the guts of the system and create a central, affordable and (in return) possibly profitable repository of apps.

That nobody even cares that Palm Pre development can only be done in HTML should be an indicator of the amount of coders that care about the Palm Pre.

Re:Talk About a Dead Platform

[MichaelSmith]

Yeah but everything had to be hosted off the phone, which makes a big difference. As much as I dislike them I can see that web UI tools are improving all the time, much faster than other ways of creating UIs.

Seriously, I can do more with 1 kb of html in ten minutes than with Swing in an hour.

Re:What's the value proposition here for developer

[Anonymous Coward]

I don't see why you associate lowering the barrier to entry with attracting lower quality developers. This has benefits for attracting developers of all ranks.

Take your average programmer out there. He's probably got a Windows or Linux box at home, and probably spends his days writing web-based business/IT apps. Let's say he's got a long weekend off and he wants to play around with developing a simple little app for his phone. If he has an iPhone, he either has to cobble together a hackintosh system, or drag himself down to an Apple store and shell out around $1k for a mac before he can even get started, then has to learn ObjC, etc etc. If he's got an Android phone, he has to download and install an SDK, possibly learn Java and the android-specific quirks thereof, etc etc. If he's got a Palm phone, he just loads up the website, creates an account, and starts dragging widgets around, and regardless of what back-end language he uses to do his day job he probably has at least some experience doing javascript for the front-end.

All the rich, powerful APIs in the world won't do Palm a lick of good if they can't get developers to try things out in the first place.

Re:What's the value proposition here for developer

[rycamor]

Perhaps you can clear something up for me: It was my understanding that in developer mode, you have a complete Linux environment, command line and all. Doesn't that mean you can compile C and C++ code to run on the Pre? Of course I know that the UI has to be handled through HTML/JS, but is it possible for the UI to talk to back-end components running as compiled code?

Apple is crazy if they think this is going to work

[maccodemonkey]

The iPhone will never succeed if they only allow developers to use web technologies instead of native code. Real apps require features that only native code can provide. ...oh what? You said Palm Pre? In that case web code roxxors!

Re:What's the value proposition here for developer

[Anonymous Coward]

Yes, they supply a program for your desktop called novaterm which gives you a command line. The homebrew crowd has then made and ported quite a number of C/C++ apps, including a terminal app which can be run on the Pre itself.

The thing is, these are not eligible for distribution through the official app store as it stands at the moment. That should be changing as Palm is going to change the store to include links to various 3rd party app makers.

The SDK Palm supplies doesn't make use of these things, and is limited to html/javascript with some special non-standard APIs to access some of the Pre's hardware. Their SDK doesn't allow you to make a lot of the complex applications the platform is begging for.

Re:Talk About a Dead Platform

[RyuuzakiTetsuya]

The age of WebOS and the Pre has nothing to do with why it sucks. If the company that gave life to the PDA can't put together a decent smart phone, and the reason why it has problems aren't teething and maturity issues, maybe maturity isn't what the OS needs. It needs newer, fresher management that's not trying to go after the fringes of disappointed iPhone users. While there are disappointed iPhone users and devs, they're vastly out numbered by the number of iPhone owners and zealots.

The more competition isn't always better. Volume doesn't equate to quality.

Re:Talk About a Dead Platform

[Fallen Seraph]

And how exactly does it "suck"? You haven't actually stated why. Have you ever used it? Or do you actually know anything about it? Or are you just parroting what some iPhone obsessed website said?

Re:Talk About a Dead Platform

[Fallen Seraph]

MichaelSmith's quite correct. This is Apple and Oranges, so to speak. All of the iPhone's applications in it's first gen were ACTUAL web apps hosted on a server. They weren't really even apps, just mobile versions of web pages. The Pre's apps are on the phone however, and leverage a TON of the upcoming HTML5 spec to allow them to do things like use a client side db, play video and audio, etc. These were things that the iPhone could not do through its browser. Not to mention that iPhone apps can't play with phone settings, contacts, etc, while the Pre's apps can, since they're not "web apps," they're just written like them.

I think you've got this almost exactly backwards

[mbessey]

javascript is (finally) starting to evolve more rapidly into a reasonable language for application development. You can already get Javascript VMs with excellent performance, and they're only getting better. With the growing adoption of Javascript for server-side work, there's a lot more support for the kind of improvements in Javascript that "real programmers" want.

ECMAscript 5 is a step in the right direction, and Harmony will build upon that. And with Google, Apple, and Mozilla now all on-board to improve Javascript's improvement, it'll get better quickly, whether Microsoft is interested in keeping up or not, will become increasingly irrelevant.

One problem with Java becoming a first-class citizen in the browser is that it's often seen as an all-or-nothing proposition. The Java language, and some of the libraries, might be useful in that context, but the Java VM, the memory model, the class loader, etc, aren't really appropriate for use in an interactive browser environment.

Re:What's the value proposition here for developer

[Anonymous Coward]

The official webOS SDK allows the programmer to create html pages using CSS for markup and Javascript for accessing Mojo services and implementing other logic. Given that is what the developer is going to be creating, it makes sense to allow them to use tools that simplify the development and debugging process. Plus it allows them to remain platform independent without having to write their own UI builder and Javascript debugger. They can leverage a lot of work that has already been done in the Javascript area.

Palm does need to create another level of their SDK for those that want to write services that run on the device. The webos-internals guys have shown that it is not that difficult to do that, so it's probably a case of wanting to finalize the HTML/JS UI level before starting to standardize things at the service level.

Re:Talk About a Dead Platform

[Anonymous Coward]

What do you call a nigger who's dating your daughter? Dead meat.