Insiders Call HP's WebOS Software Fatally Flawed

Hugh Pickens writes "Some of the people involved in creating WebOS, the HP TouchPad's core software, now say the product never had a fighting chance because it relied on WebKit, an open-source software engine used by browsers to display Web pages, that just didn't have the horsepower to run fast enough to be on par with the iPhone. 'Palm was ahead of its time in trying to build a phone software platform using Web technology, and we just weren't able to execute such an ambitious and breakthrough design,' says Paul Mercer, who oversaw the interface design of WebOS and recruited crucial members of the team. 'Perhaps it never could have been executed because the technology wasn't there yet.' Another problem was the difficulty in finding programmers who had a keen understanding of WebKit as Apple and Google snatched up most of the top talent including Matias Duarte, vice president of human interface and user experience for WebOS, who left for Google a month after HP's acquisition of Palm. 'When he left, the vacuum was just palpable. What you're seeing is frankly a bunch of fourth- and fifth-stringers jumping onto WebOS in the wake of Duarte's leaving.' CEO Meg Whitman has announced that HP will release the WebOS code for anyone to use, similar to Google's open-source strategy with Android, but some say WebKit will still leave WebOS underpowered relative to Apple's software."

Comments

Am I missing something?

[dnaumov]

But doesn't Apple's Mobile Safari used the very same WebKit?

Re:Am I missing something?

[Dupple]

Yes it does, but Safari is not an operating system. That's what you're missing

Re:Am I missing something?

[SharkLaser]

The browser uses, of course. But they're talking about the whole OS. WebOS is supposed to work fully using WebKit to render it. iOS doesn't render the UI and apps with web browser.

Re:Am I missing something?

[Wordplay]

I expect it's forked pretty heavily for customization and optimization purposes. If HP couldn't get good WebKit talent, they'd have been stuck with something much closer to vanilla performance.

I can also see not wanting to adopt the same platform if your hardware isn't competitive.

Re:Am I missing something?

[SharkLaser]

I can't understand why they didn't try to work with Opera tho. Opera Software has years of experience in embedded systems, mobile phones, Wii, hotel tv's... They have the tech and knowledge.

Re:Am I missing something?

[Anonymous Coward]

Obviously you're missing that 'The best engineers at HP' couldn't understand that not only is Webkit the same rendering backend as Apple's, but it's also the same rendering backend as Linux's competitor to Firefox, and fast enough even on 15 year old hardware to offer an acceptable if not speedy experience. So given the specs of the WebOS devices it is most certainly fast enough to compete with Apple's solutions. Now mind you they might've f'd it up somewhere else in the chain, or not understood it well enough to make rendering optimizations that would give it that 'real time' feel, but all that is on them, not Webkit.

Re:Am I missing something?

[ameen.ross]

The article says slightly ambiguously that WebKit is the basis for WebOS' apps.

Re:Am I missing something?

[marcosdumay]

Eh, no. Firefox uses Gecko.

Safari and Chrome use WebKit.

Re:Am I missing something?

[PCM2]

Yes it does, but Safari is not an operating system. That's what you're missing

But what you seem to be missing is that the idea that an entire OS can be written using WebKit is absurd. Are WebOS's device drivers and filesystem written in JavaScript?

WebOS uses WebKit to render its user interface -- the same way Safari, Chrome, Opera, the Android browser, the BlackBerry browser, the Symbian browser, etc., all do. From this article, you'd think all of those products should be failures.

I think it more likely that the reporter is quoting sour grapes from a former WebOS manager who blames tools and frameworks for his projects failure. Quoting elsewhere in the same article:

From concept to creation, WebOS was developed in about nine months, this person said, and the company took some shortcuts. With a project like this, programmers typically start by creating the equivalent of building blocks that can be reused and combined to create different applications. But with WebOS, Palm employees initially constructed each app from scratch. Later, they made such blocks, but they were overhauled once by Palm and then again by H.P., forcing programmers to relearn how to build WebOS apps.

Ah. I see.

Re:Am I missing something?

[PCM2]

Errr, correction: Not Opera.

Re:Am I missing something?

[gl4ss]

*WebOS uses WebKit to render its user interface* and you compare that to web browsers, where it's reasonable to use the webkit to build the favorite pages menus and such. and that's exactly what the bitching is about. iphone doesn't render the whole ui using webkit. neither does android or symbian. for none of those it's a preferred ui building kit anyways(nokia did run some pr that webruntime would become a standard way of doing apps for nokia's, but it was mostly pr bullshit as the product itself didn't live up to the hype).

Re:Am I missing something?

[unixisc]

I thought WebOS was just another distribution of Linux, so how can it be dependent on WebKit? Yeah, if it was trying to use some WebKit based browser as file manager, I can see how, but is that what they were using? From what I've read here, WebOS ain't much better or worse than Android - it's just that its pricing model didn't initially come anywhere close to market price, for whatever reason, not that WebOS itself is a kludge or anything.

Re:Am I missing something?

[PCM2]

*WebOS uses WebKit to render its user interface* and you compare that to web browsers, where it's reasonable to use the webkit to build the favorite pages menus and such.

Why is it reasonable to render the UIs of Web apps using WebKit but unreasonable to render any other kind of UI using WebKit? Your objection doesn't make any sense. If WebKit is totally unsuitable for rendering UIs then Web-based apps must be unusable on iOS, Android, and BlackBerry, all of which use WebKit to render Web UIs. I don't understand the artificial distinction you're creating between "Web UI" and "every other kind of UI."

Explain to me this: In all of the (presumably many) times you have used a WebOS device, has the performance of the UI been your #1 complaint? What didn't you like about the UI on WebOS?

Re:Am I missing something?

[chrb]

iPhone web apps do use webkit to render the UI though. Are web apps too slow to be usable as a result of this? Did users complain that WebOS was too slow? And if so, was it really slow because of webkit? This article clearly blames the hardware rather than the software, stating that WebOS itself ran twice as fast on iPad level hardware. And if WebOS was too slow to be usable, then how come everyone raved about it once they dropped the price? Very few people are so enthusiastic about platforms that are so "fatally flawed". Was it all just marketing hubris?

Re:Am I missing something?

[Stewie241]

I didn't see him claim Firefox used Gecko, though he was vague in regards to what browser he actually was referring to. My guess would be either Konqueror, which probably had a bigger market share in the past, or Google Chrome, but it would be hard to call that Linux's competitor to Firefox, though it probably is the major alternative to Firefox on the Linux desktop.

Re:Am I missing something?

[chrb]

Can we please use the correct terminology? Webkit is not an operating system. An application launcher is not an operating system. A graphical desktop is not an operating system.

Re:Am I missing something?

[jo42]

Why is it reasonable to render the UIs of Web apps using WebKit but unreasonable to render any other kind of UI using WebKit?

Performance, dumbass. C (or C++) based OpenGL (i.e. iOS) will always run circles around WebKit rendering HTML (i.e. WebOS).

Re:Am I missing something?

[PCM2]

Performance, dumbass. C (or C++) based OpenGL (i.e. iOS) will always run circles around WebKit rendering HTML (i.e. WebOS).

Riiiight. And you say that as an experienced developer, yes? Because A.) I have never heard of the UI of a handheld application requiring significant processor resources; and B.) I have never heard anyone complain about the performance of the WebOS UI. But yeah, C is "faster" than JavaScript, that took a lot of brain cells on your part.

Re:Am I missing something?

[gl4ss]

the ui's on webos could have been made vastly different, had the design choices been different. they might have had a normal widget homescreen etc.

it's not unreasonable to use "web technologies" to build some ui's, but it's never optimal and you limit yourself from doing lots of things and make lots of other things complex to achieve.

most 3rd party "cool" sw for webos seem to use sdl anyways.

a web browser that uses web technology to render it's favorites, settings etc views for example, those ui views are relatively simple. but using html + js to build a drawing application would be just suicide.

Re:Am I missing something?

[NemosomeN]

He didn't claim Firefox used Gecko (it does), he did claim that Linux's competitor to Firefox used WebKit. Konqueror is where WebKit came from, but I'd hardly call it a competitor. I wouldn't call it anything more than KDE systems' default browser. I highly doubt many linux users actually use it as anything more than a fallback.

Re:Am I missing something?

[binarylarry]

WebKit isn't written in JavaScript. It's written in C++, so your earlier analogy doesn't make any sense.

Javascript integration is a separate feature that isn't even core to WebKit (which is why you see Chrome using V8, Firefox using *monkey and Safari using their latest JS JIT/interpreter).

Re:Am I missing something?

[pmontra]

Don't be too hash on them, this site is about news for geeks but anybody can register and comment ;-)

Re:Am I missing something?

[binarylarry]

The firefox thing is wrong, yes i know it's Gecko (brainfart).

Re:Am I missing something?

[Anonymous Coward]

iPad 2 hardware is roughly comparable to other tablets. Apple is one of the primary developers of Webkit, though, so you can expect the iOS version of Webkit to be very well optimized. AFAIK those iOS-specific optimizations are not open source.

webOS became a lot faster after the first patch release. IMHO it was usable even before the patch, but the real problem was that it just wasn't as polished as the iPad 2 yet HP still tried to charge $500 for it. Even Android tablets had trouble competing with Apple at that price point, and Android can at least boast a respectible app market (although tablet-optimized apps are still terribly lacking).

Re:Am I missing something?

[gbjbaanb]

and, of course, if "browser" based UIs are truly poor, then I don't hold out much hope for Windows 8.

Re:Am I missing something?

[dave420]

Performance doesn't always equal "significant processor resources", fyi. The argument seems to be somewhat above you. As an owner and user of Android, iOS, and WebOS, I can assure you that WebOS did indeed suffer from great performance issues in the UI, such as a lack of response, and an almost complete disability to integrate nicely with the more complicated aspects of the platform's hardware.

Re:Am I missing something?

[RCL]

Just compare user experience of Google Documents with Excel or even Libre/Open Office (the latter one apparently uses Java, but even with Java it performs better than GD). As a benchmark, try to use Google Docs to load, edit (copy/paste, etc) and visualize (graph) 25 000 lines long CSV file (each line containing only pair of two numbers, e.g. timestamp and a sampled value).

Don't underestimate the power of native UI ;-)

Re:Am I missing something?

[Stewie241]

Bah. I meant Webkit when I said Gecko. I think I alluded to everything you said in my post, which may have been clearer had I not substituted the word Gecko when I meant webkit. But I fully agree, that nobody seems to use Konqueror anymore.

Re:Am I missing something?

[tomhudson]

Because WebKit is stil broken for some basic functionality, like applying CSS3 transforms after scaling at a factor of less than 1:1 - something that Firefox, Opera, and even IE9 get right..

It's one thing to have a web browser that needs to scale at less than 1:1 - you can call the OS to handle it. But what if the web browser IS the OS? Then you are, as some slashdotters would put it, boned.

Re:Am I missing something?

[tomhudson]

I have never heard of the UI of a handheld application requiring significant processor resources

Graphical rendering of your screen is most processor-intensive part of the unit. It's why iPhones and iPads have a dedicated GPU What - you think those page wipes and zooming were done by the main cpu? That would be a cpu made with unobtainium.

Re:Am I missing something?

[dave420]

You seem to be confusing Windows 8 with a small part of Windows 8.

Re:Am I missing something?

[tomhudson]

he did claim that Linux's competitor to Firefox used WebKit

Of course, the REAL fail is thinking that there's such a thing as "the linux browser". Linus Torvalds doesn't make browsers, and there are plenty of "Linux browsers" out there. Arora (QT4), Chrome, Galeon, Firefox, Konq, links, lynx, reKonq, Seamonkey, all sorts of plasma mini-browsers, whatever ... you get the picture :-)

Re:Am I missing something?

[justforgetme]

Using webKit to render UI is technically brilliant. It's only drawback is that the process isn't as CPU efficient as is commanding C libs directly (AFAIK iOS and android do this) due to the added abstraction. Definitely universal rendering frameworks is the correct way to go, unfortunately webOS was a half effort endeavor and therefore never got the hardware to make it shine, nor did it get the performance optimization it deserved.

Anyway, now that it is going to be open sourced someone will come up with a way to accelerate the webKit renderer and lay the foundations for what is going to become the next generation of small device OSes.

Re:Am I missing something?

[FyRE666]

"I have never heard of the UI of a handheld application requiring significant processor resources"

Guessing you've never played any games that were more demanding than Angry Birds then. The fact is that WebKit is fine for rending web content, but developers need lower level access to get the performance required for non-web apps.Even if the device could just about grind along at a reasonable pace using a WebKit based version of a native app, the fact the processor is working a lot harder will lead to much shorter battery life, and in some cases the device becoming noticably warm.

Web-based interfaces on mobile devices are find for simple apps with mostly static content, but for a nice responsive and efficient UI then native (or at least a fast virtual machine) is required.

Re:Am I missing something?

[shutdown -p now]

Win8 is also using the browser as "app platform" (as one of the options, though). We'll see if it truly is not viable, or if HP just did it wrong.

Re:Am I missing something?

[Weezul]

I donno, web interfaces seem horribly inefficient and stupid relative to native interfaces. I pretty much considered WebOS fatally flawed the moment I heard about it. And it fulfilled my expectations. Worse, there are apparently some fools that decided MeeGo must follow WebOS's lead. lol

There is a very clear formula to building a better smartphone : Expand Android's NDK by optimizing glibc instead of using Google's minimal libc. Cut what features must be cut, but optimize anything that produces reasonable performance on mobiles. Improve the market place's support for native code. Voila, GNU Android. Infinitely easier porting for Linux libraries. All Android/Java based front ends, no X11. All Android applications "just work".

Re:Am I missing something?

[JoeMerchant]

But with WebOS, Palm employees initially constructed each app from scratch. Later, they made such blocks, but they were overhauled once by Palm and then again by H.P., forcing programmers to relearn how to build WebOS apps.

This is the same schtick that came around after Nokia dropped Qt... I'd say it's armchair quarterbacking from people who don't really understand programming at all, sounds good in the executive boardroom during the "lessons learned" meeting, but is impossible to verify unless you're in the trenches, and I bet that in the trenches you can find all kinds of conflicting opinions about what went wrong.

Re:Am I missing something?

[segin]

I read somewhere that the text rendering on iOS is done using WebKit, with CoreFoundation APIs being high-level wrappers over this. Please correct me if I'm wrong.

Re:Am I missing something?

[NemosomeN]

Bah. I meant Webkit when I said Gecko. I think I alluded to everything you said in my post, which may have been clearer had I not substituted the word Gecko when I meant webkit. But I fully agree, that nobody seems to use Konqueror anymore.

lol, anymore?

Re:Am I missing something?

[Anonymous Coward]

Why is it reasonable to render the UIs of Web apps using WebKit but unreasonable to render any other kind of UI using WebKit?

It's not ok. Web apps suck and people hate using them.

Re:Am I missing something?

[Anonymous Coward]

You are wrong. Web kit uses Core Foundation. UIKit and all of Cocoa built on top of CORE technologies Core Foundation, Core Graphics, Core Audio, etc....

http://upload.wikimedia.org/wikipedia/commons/f/f2/Diagram_of_Mac_OS_X_architecture.svg
http://developer.apple.com/library/ios/documentation/Miscellaneous/Conceptual/iPhoneOSTechOverview/IPhoneOSOverview/IPhoneOSOverview.html

Re:Am I missing something?

[Anonymous Coward]

Yes, as does Google's Chrome in Android. Google even uses WebKit in ChromeOS like WebOS does. This isn't a technical problem, it's a staffing problem. Google and Apple are better places to work. They treat their strategically-important employees very well. HP, on the other hand, sounds like a crappy place to work now. They overpaid for Palm, so all those employees have already made as much on their options as they're going to...the HP stock is going nowhere. And it sounds like HP didn't make the purchase contingent upon retention agreements with key employees...whoops!

So you're a key member of the WebOS team who, after the acquisition, was faced with the decision to either stick it out at a job with clueless management, less opportunity to succeed and less compensation. Or you jump ship to Apple or Google, work on the cutting edge of WebKit and get paid better in the process.

Basically, an OS based on WebOS is too complicated for a team of engineers that Google and Apple don't want.

Re:Am I missing something?

[Cinder6]

UI performance has always been one of the #1 complaints people had about webOS. The Touchpad has to be overclocked to 1.5-1.7GHz (dual core, mind you) and have lots of performance patches and experimental kernels used before it even approaches the responsiveness of the first iPad (1GHz, single core, 1/4 the RAM). I think webOS has some great concepts, but it seriously hamstrung itself by forcing everything to be rendered with WebKit.

Re:Am I missing something?

[chrb]

Not "always". There is nothing inherently faster about a GUI layout specified using a native XML based format as used in Android etc. versus one specified with HTML, or even one specified imperatively. Both are just markup languages, or ways of specifying a GUI layout, what actually matters is the implementation that converts this description into an in-memory set of data structures, and which then turns these data structures into graphics commands. There is nothing magical about OpenGL that limits its use to non-HTML user interfaces. You can render any graphics, including those specified in HTML, using an OpenGL backend, but most Android and iOS apps do not directly use OpenGL - there are apps that just create a GL window and then render straight into it (eg that would be a common technique for games), but most apps utilise the widget set provided by the native API, which may be in turn rendered to OpenGL.

Re:Am I missing something?

[Anonymous Coward]

Ironically even Angry Birds uses OpenGLES on (almost) all deployed mobile platforms.

Re:Am I missing something?

[gl4ss]

Because A.) I have never heard of the UI of a handheld application requiring significant processor resources;

why do you think they're not still running smartphones at around 107mhz like they did with nokia 7650?

all their ui's need significant processor resources. just scrolling and populating those screens takes a lot of juice, with touch interfaces if the fps drops it becomes very apparent. take androids contact list and start scrolling as fast as you can. the cpu needs should be obvious. and that's just for built in apps. even for simple stuff like just having a rendered text on the screen, a lot more has to be done if you churn it through to html and then render that html than what would be needed if you just had a simpler ui widget(like a qwidget) that was used for painting the text to screen.

plenty of people complain about webos speed. nobody has bitched about bad opengl performance on the sdl games for it though. that was pretty bare to the metal on webos apparently, which makes webos have this schitzo dual personality when it comes to performance.

Re:Am I missing something?

[the linux geek]

OpenOffice/LibreOffice is written in C++, although a few non-core components are in Java.

Re:Am I missing something?

[the linux geek]

webOS had a C++ API (the PDK) too.

Re:Am I missing something?

[anomaly256]

Actually, blitting pixels to a surface/framebuffer/etc even with alpha compositing isn't *that* cpu intensive (but maybe it's bus io intensive in some circumstances). It's all the other stuff going on in the background that causes the chug - causes context switching and such - like events firing constantly, IPC, and so forth. And yes, abstracting these a few times through a C++ library then a javascript engine on top of it and then javascript itself does add up to overhead in a few places you seriously don't want it.

Having said that though, there's no reason it has to be so slow as to ruin the user experience either! Modern cpus handle such loads pretty well. Either the touchpads were using the wrong, underpowered cpus because some jerk wanted to shave $10 per unit, or, the programmers didn't spend a lot of time optimizing their code and testing it under load.

Re:Am I missing something?

[RocketRabbit]

Well Safari, for one, uses Cocoa widgets for drawing the UI. Mozilla uses XUL, etc.

They all use Webkit to draw the *web views* but those are different from the UI.

Re:Am I missing something?

[MichaelSmith]

Its nice to use on the touchpad. Feels a little bit laggy at times but that may be more from a lack of processing grunt than the choice of UI technology. For example rendering a web page takes longer than on a faster desktop.

Re:Am I missing something?

[Anonymous Coward]

Most rendering on the Nexus S running Android 4 are done on the CPU because Google found it worked as fast as the GPU or faster and had less overhead. And it's very slick.

Re:Am I missing something?

[Anonymous Coward]

Hum, uh, sorry baby, lemme get you a towel... Looks like I hashed on you a little bit.

Re:Am I missing something?

[Randle_Revar]

LO/OOo use Java in just a couple subsystems. Help and DB stuff I believe.

Re:Am I missing something?

[Anonymous Coward]

More importantly, Google's ripping off of iOS and dumping of android onto the market for free destroyed any chance of innovative competition to the iPhone succeeding. Only heavily entrenched companies like Microsoft can even try, and those sort of companies rarely try something new. Google deprived the world of a renaissance in mobile OS innovation in the name of corporate profit.

Re:Am I missing something?

[Anonymous Coward]

Why!

You keep stating its bad, it wouldn't work, it's suicide, but you haven't touched on a single actual technical reason.

If you do happen to come up with a reason, you should give MS a call. They're betting the farm on you being wrong for Windows 8.

Re:Am I missing something?

[Daniel Phillips]

Why is it reasonable to render the UIs of Web apps using WebKit but unreasonable to render any other kind of UI using WebKit?

Rendering any UI with html is offensive to any engineer with a sense of decency. All the more so for a device that needs to conserve battery power.

Re:Am I missing something?

[pmontra]

Ouch, my keyboard hashed me...

Re:Am I missing something?

[Anonymous Coward]

there is a trend that usually come up in the likes of "x technology is easier (meaning developers costs less, N.B.), let's do everything in x!"

there is a reason for which we don't use hammer for screws, however.

Re:Am I missing something?

[segin]

No, it's the difference between a bunch of C/C++/Objective-C calls creating a tree of UI elements in a UI toolkit also written in C/C++/Objective-C, versus a SGML parser having to parse HTML (an application of SGML), or XHTML (an application of XML, which is itself an application of SGML), in order to generate a DOM tree, map it to native UI elements (via the originally mentioned UI toolkit), and also hand-render anything that doesn't map 1:1 to the native toolkit (99% of the DOM content.) If you are lucky, WebKit might use low-level native drawing functions to draw, e.g., Bézier curves, but even that isn't always the case.

Re:Am I missing something?

[segin]

If you would, please provide sample data files so that I can verify your results myself.

Re:Am I missing something?

[Anonymous Coward]

The sad but funny thing is that most of the UI response issues have been addressed with patches available via Preware. Not having a Mojo or Enyo API for some hardware features is due to the company not having the resources to flesh everything out. However, if one wanted to use those features the app would have to be written with the C/C++ PDK. Despite its shortcomings, I still prefer webOS to anything else.

Re:Am I missing something?

[RCL]

You can generate as many as needed by this bash one-liner (redirect its output to file): while true; do echo `jot -r 1`, `jot -r 1`; done - you can use `date` instead of first jot. It does not matter whether the numbers are meaningful or not, this is irrelevant for testing UI scalability. Just make sure that resulting csv file is at least 25000 lines (i.e. pairs of numbers) long (although problems with handling/visualizing this in browser will likely start even sooner).

Real argument: "Not the iPhone".

[Anonymous Coward]

But WebKit powers lots of other technologies like Chrome and Safari.

I think the real argument they are making for WebOS's inability to beat the iPhone, was that WebOS isn't the iPhone. i.e. their plan to succeed was by definition unable to beat the competition. And this is not the failure of a technology, but instead the failure to be visionary.

Webkit?

[ameen.ross]

According to TFA, WebKit isn't the main cause, but (and I quote):

But a former member of the WebOS app development team said the core issue with WebOS was actually Palm’s inability to turn it into a platform that could capture the enthusiasm and loyalty of outside programmers.

Re:Webkit?

[RightSaidFred99]

Yeah, I don't understand how anyone could possibly think the reason WebOS didn't take off was because of its performance or some performance related issue as is intimated in the article summary. It doesn't even make sense, it's silly.

The problem was of course exactly what you quote. From a user perspective I found WebOS pretty cool. I was a long holdout but got a $150 32G Touchpad and used it for a while and was surprised how user friendly the interface was. I prefer it to Android and of course vastly prefer it over the iPhone.

Unfortunately, WebOS is mostly dead so I have desecrated it by installing Android on it now because I want the Android app library available.

Re:Webkit?

[Anonymous Coward]

I installed android for text reflow in the browser, which makes reading on a tablet actually viable.

Nonesense

[anton.karl]

There are a number of reasons why the TouchPad failed, but the quality of WebOS is not one of them. WebOS is a rare exception of improvement in GUI design at the OS level these days and it works quite smoothly. The problems are things like the lack of quality software that runs on the platform. I couldn't care less about having thousands of apps for silly tasks but a tablet that doesn't even have decent support for reading PDFs is just obviously going to fail. The basic apps that come with the TouchPad just never reached a mature stage. As for the management aspect of things, I won't even go there.

Re:Nonesense

[Anonymous Coward]

agree. all of the major apps had critical bugs or feature deficiencies. Facebook didn't show updates from all people, adobe reader had no search our page turning while zoomed in. Web browser was missing functionality and often rendered pages in a glitchy fashion. email app didn't allow download of certain docs (discovered at a critical moment in a meeting). all if these were showstoppers for me. cyanogen has a lot of force closes on my touchpad and battery life is much lower, but the apps are great. webos is fine as an OS, But the app ecosystem was missing. not surprising really. they should have open sourced from the start

Re:Nonesense

[gayak]

Certainly true is many aspects, but PDFs aren't one of them. Acrobat Reader works just fine, I use my Touchpad to PDF formatted papers often. There are few key apps missing (but not many to my tablet usage), and the user interface is still something no other tablet can currently provide (it actually uses the advantage of bigger touchscreen, unlike Android Honeycomb for example, which still relies in several places on small icons and stuff that would fit nicely in a small screen). Maybe it was ahead of it's time though.. HTML5 will caught eventually and then tablet could run the same programs, thus removing the need for platform specific programs. But is that too late..?

Re:Nonesense

[rsmith-mac]

I'm sorry, but it's not nonsense. The article is spot on.

WebOS as a GUI design absolutely has its merits (the cards really are fantastic) - but then that's not what the article is claiming. The article's claim is that WebOS was immature and slow and that's absolutely the case.

Just booting the damn thing takes 77 seconds (versus 31s on a Galaxy Tab). Never mind the anemic performance of their WebKit implementation - which carries right on over to application performance since most applications are written against WebKit - which is why at best it's less than half as fast as an iPad 2 with similar performing hardware and still spends most of the time trailing the now-ancient iPad 1.

The 3.0.4 update fixed this somewhat, but not a ton. It's still slow and it still chugs, it just does so somewhat less often than with the shipping software. The poor thing can't even play YouTube videos above 480p most of the time.

Though you're not entirely off base; you are absolutely right about the applications also being a problem. The IM client is probably the best part and it only gets worse from there. The PDF reader is especially atrocious as you noted, and a big part of that is because they're rendering everything in WebKit, saving the result to an image file, and then displaying that to the end user.

Anyhow, no, WeOS is not a fine OS. It's yet another collection of interesting concepts that weren't executed on correctly and require a level of performance today's hardware can't provide. Relying on WebKit for so much of the OS - and thereby a combination of interpretation and JIT compiling - was a stupid idea. These are still fundamentally embedded systems, and with embedded systems the closer you can be to the metal the better off you're going to be. Of course in Palm/HP's case all of this was punctuated by particularly inane decisions like logging every last thing to MLC Flash memory that doesn't like small writes.

As a TouchPad owner I'm doing little at the moment besides waiting for someone to port Ice Cream Sandwich to it. It may not have the slick multitasking of WebOS, but at least Android has the performance to actually handle multitasking along with everything else a tablet should be able to do smoothly. WebOS is crap.

Re:Nonesense

[jhzorio]

How can you write that the TouchPad doesn't suffer from the lack of a GOOD application to read PDFs ?
It's the biggest gripe I have with mine.
- Many PDFs can't be read.
- Zoom factor is ridiculous. And not preserved when switching page.
- Application is slow (but is it a software or a hardware problem ?).
Reading PDF on a TouchPad is really a pity, and the fact that the application is Adobe Reader makes one wonder about Adobe commitment (or, worse, skill).

Re:Nonesense

[milimetric]

"WebOS is crap"

I agree if you change it to this

"out-of-the-box WebOS is crap"

Though I still love WebOS and most things it stands for, for the reasons you mentioned. Here's what I did to make it not crap (I have a TouchPad and an HP Pre 3).

1. Install Preware: http://theunlockr.com/2011/09/16/how-to-install-preware-on-the-hp-touchpad/.
1.1. Install the patches that muffle system logging.
2. Install custom kernel and set the lowest CPU frequency allowed to 768, keep the max at 1.4 (for the HP Pre 3, same idea for the Touchpad, different freq.)
3. With your HP Pre 3 which comes unlocked for only ~ $200, sign up for an unlimited "non-smartphone" data plan with AT&T. This'll get you $10/month unlimited data.

These simple steps will get you a phone that's just as smooth as an Android device (iOS is still smoother), and $20/month cheaper for unlimited data, and without a contract. The downside is of course that you're now definitely deep inside geek territory installing custom kernels and what not. I'll say that I'm pretty sensitive to basement-nerd induced stress, and so far that's been low on WebOS compared to other open-sourcey crap like the new Ubuntu.

Re:Nonesense

[Mr Krinkle]

To be honest, you don't even need to do 1 or 2. Just doing 1.1 a simple one line deal my touchpad went from crap, couldn't play any videos, constantly slow, to really good, played youtube at 720 (assuming good network) and could play HD videos I'd copied onto the device so the kid could watch Shrek etc in the car on trips.

Why they had logging turned up THAT far on a released product is beyond me.

Re:Nonesense

[Anonymous Coward]

You're close on the default PDF viewer. The app actually makes a call to a C/C++ service that renders the PDF pages to a temporary file and the app displays the temporary image. Webkit isn't being used to render the PDF. If that were the case, there would be no need for the temp file. Picsel Office is a far better PDF viewer than the stock Adobe one anyway.

In other words

[assertation]

WebKit is to tablet PC operating systems as SmallTalk was to object oriented languages. A great idea existing before the state of the art could support it.

Most stupid comment

[Anonymous Coward]

Safari is a web browser. WebOS is an OS. WebKit doesn't run native iOS apps. What the article is saying is that WebOS apps running inside WebKit cannot compete with iOS apps running natively (just like web apps running in Safari can't compete with native apps - which Steve Jobs didn't believe at first, and it took jailbreaks and Installer.app to convince him otherwise).

Re:Most stupid comment

[dna_(c)(tm)(r)]

What the article is saying is that WebOS apps running inside WebKit cannot compete with iOS apps running natively.

The article doesn't say that. You infer that. The summary doesn't even mention iOS apps.

.

But frankly, I don't agree with the analysis that using webkit must necessarily be less efficient than having another layout and rendering mechanism. Perhaps implementing behavior in javascript instead of C would add a little overhead that might be too much when dealing with slow processors...

Re:Most stupid comment

[marcosdumay]

Normaly (and on all real cases available) a web browser is slower than other GUI toolkits because it has to solve a plentora of other problems, not just showing things on the screen, and the toolkit can do just one thing. Besides that, software embebed on browser is written in Javascript, that is interpreted and again, normaly (and on all real cases available) interpreted languages are slower.

But none of those probems must be this way. They just happen to be.

Re:Most stupid story

[Anonymous Coward]

You're the one being stupid. Safari != iPhone. WebOS renderds whole OS with WebKit while iPhone has its native functions for actual UI and apps.

Re:Most stupid story

[rolfwind]

But safari is not iOS. Just a browser.

If wikipedia is correct:

HP's Palm WebOS uses WebKit as the basis of its application runtime.

IIRC, one of the major things with iOS was that graphic routines would be given priority over everything else:
http://www.inspiredgeek.com/2011/12/07/why-android-graphics-are-laggy-while-ios-is-smooth-facts-practical-reality/

Seems to me that it's all a fundamental UI issue.

Wow, that isn't burning bridges

[Anonymous Coward]

That's nuking bridges from orbit. So the team, which he recruited, is a bunch of fourth- and fifth-stringers? He really doesn't want to hear from them again, I guess. Next time just unfriend them on Facebook, mkay?

Re:Wow, that isn't burning bridges

[Shoten]

If this kind of behavior from a former HP executive surprises you, then you clearly haven't talked to anyone who works at HP lately...but in his defense, I'm sure he got as good as he gave. There's a reason so many are jumping ship there, leaving only fourth- and fifth-stringers behind.

Re:Wow, that isn't burning bridges

[FreakyGreenLeaky]

mkay

That's beautiful man! Thanks for making my day.

That is saying a lot

[assertation]

"WebKit will still leave WebOS underpowered relative to Apple's software."

Wow, that is saying a lot.

Re:That is saying a lot

[Anonymous Coward]

No it isn't. It's saying building an OS on the webkit framework was a dumb move. They should have limited webkit to the browsing experience, like we have in iOS and Android.

Re:That is saying a lot

[Anonymous Coward]

I guess you've never used any of Apple's software, you just like to post on the internet about how terrible it must be.

Re:Most stupid story

[Anonymous Coward]

WebKit, an open-source software engine used by browsers to display Web pages, that just didn't have the horsepower to run fast enough to be on par with the iPhone

WebKit is the basis of Safari, see here.

I hope you are joking. Safari is not Apple's operating system. There is a difference between using a technology for web browsing and as a complete OS.

Re:Most stupid story

[Richard_at_work]

It is, but webapps on iOS run into similar performance issues as highlighted in this story - Apple don't accelerate the version of WebKit which is used by webapps that are launched from icons on the desktop as much as the version of WebKit which their Safari browser uses, and its pretty noticeable.

The "story" here is that everything in WebOS is WebKit based - there is no Dalvik or Cocoa equivalent (I'm not sure as to the validity of that statement as I'm not interested in WebOS, but everything I have read indicates that it is correct), which are much closer to the metal and thus have a performance advantage.

Not really surprising

[blahbooboo]

This isn't that surprising as I remember how much trouble WebOS had to get GPU acceleration working for developer access and use in gaming etc.

Re:Not really surprising

[Stingray454]

How true. I was involved in a project to create a "rich multimedia application" for WebOS back just before they killed it. Some usage of hardware just made the entire thing a nightmare. Built in video playback, for example - Took 2+ seconds to load a short video clip, screen flickered while you did, video playback didn't care about device orientation, and the controls were limited to "play" and "stop" (no pause, no seeking, no looping and so on.. well you COULD loop a clip, if you didn't mind another 2 seconds stall/flicker when the video restarted). Similar issues surfaced on most other hardware interfacing we tried as well. Maybe it could have been fixed in later versions, but overall it just felt terribly unpolished. Good ideas, bad implementation.

Open source community fixes these things.

[unity100]

The question is, what HP will give back to open source community in return.

Re:Open source community fixes these things.

[Anonymous Coward]

Only if somebody cares enough to fix them. Open source isn't a magical fix for software issues.

You mean there's a difference between engineers?

[WalrusSlayer]

Another problem was the difficulty in finding programmers who had a keen understanding of WebKit as Apple and Google snatched up most of the top talent

But wait, I thought that engineers were just pluggable resources...

Evidence shows another thing?

[Superken7]

Last time I checked, WebOS was really snappy and smooth, and provided a great user experience. Maybe games were hard to code, but the apps I tried out when the first WebOS phone came out felt MUCH smoother than my Android phone.

There are probably many reasons why WebOS failed, but I am very confused by this statement given how well WebOS felt (And I have read the same from many many users in the Internet). The complaints about WebOS were never that it felt like a web app, too limited or that it felt too sluggish, but rather the lack of apps and devices.

Am I missing something here?

Re:Evidence shows another thing?

[PCM2]

Maybe games were hard to code

Not really. WebOS doesn't force you to do absolutely everything with HTML/JavaScript, contrary to the article (and a lot of the assumptions in this thread). Palm is kind of a victim of its own hype in this respect. Palm told the world that everything in WebOS was based on Web standards to get across the idea that anyone with Web development experience should have no difficulty learning how to code apps for WebOS using what they already know. What gets lost in all the talk about HTML, though, is that there's also a Native SDK for WebOS that lets you code more processor-intensive stuff in C/C++ etc. I don't know if final versions were ever shipped, but they've demoed Doom, Quake, and OpenGL apps running on WebOS.

The New York Times reporter was obviously only marginally technical and not very familiar with the WebOS platform, and he was quoting self-serving statements by a former Palm exec who wants to excuse the fact that (by his own admission) his team failed to execute its own ambitious plans.

Re:Evidence shows another thing?

[branchingfactor]

The self-serving statements were from an HP exec who wants to excuse the fact that HP wasted $1.2 billion.

Re:Evidence shows another thing?

[jalefkowit]

WebOS doesn't force you to do absolutely everything with HTML/JavaScript, contrary to the article (and a lot of the assumptions in this thread). Palm is kind of a victim of its own hype in this respect.

That's true now, but it wasn't true when it mattered, at launch. When the original Pre shipped (which was the first public release of webOS), there was no native SDK available; the HTML interface was the only interface available. Later on Palm released the native SDK, but it was too late; by that point webOS had already lost momentum in the marketplace.

(It's worth noting that this is exactly the same thing Apple did with the iPhone; originally that device was web-apps-only too, and it wasn't until after much wailing and rending of garments that Apple relented and provided a native SDK. But Apple could get away with that because of the iPhone's position as the first real personal smartphone, which made it sexy even if it wasn't as developer-friendly as it should have been. The Pre had no such safety net.)

Re:Evidence shows another thing?

[Dan East]

Android was also similar in this regard - developers could only use Java for development at first until the NDK was created, which allows C/C++ development of native binaries for maximum performance. Really, the platform would have been crippled without it from a gaming / multimedia perspective.

Microsoft is still too dense to make this realization with Windows Phone. They still only allow C#, which although performance issues due to lake of native support probably isn't the extreme issue it was with webOS or even Android, it still is a massive barrier to code portability and getting developers to support the platform with their existing iOS and Android products.

Re:Evidence shows another thing?

[gl4ss]

not _entirely_ true about android.

you see, you could(and can) without NDK run linux binaries by executing them(binaries that you provided in your package). of course you'll have do io to them in some non-optimal way, but you still could do it, I'm not sure if any popular apps besides rooting etc apps used this for doing any heavy lifting though.

Re:Evidence shows another thing?

[Dan East]

But what amount of integration would the linux libraries have with the Android layer itself (pre-NDK)? Could they even access OpenGL ES? If not then that what could be implemented would be quite limited. In my case, I would have been able to use it for the physics engine and scripting host, which are two of the bigger CPU consuming libraries in my app. However, it still would have been a compromise in several ways.

Re:Evidence shows another thing?

[Anonymous Coward]

It was very clean. The whole thing was a fairly remarkable piece of engineering, I worked on security testing the pre app store and the platform before the launch. I just worked on a couple things and cant' get specific, but the webos devices are Linux, a fairly normal looking linux platform with a web UI runtime, looked like a mix of javame for the "server" side (something needs to server up the 'web pages' to the UI) with some C/C++ and then the UI was mostly based on webkit, extended to do some platform specific stuff. All normal off the shelf technologies, all technologies that are very easy to use (relative to embedded platforms and phone platforms) all technologies that are easy to develop for and then the thing seemed to work. FWIW, display postscript and (pdf) have been desired for UIs for the last 20 years so you could have on screen page presentation that's identical to your printed page presentation. In this century, doing that with a browser is where it's all going to go, eventually. Between WebOS, Metro and other things, the web is the way to make pretty, cross platform UIs and that's becoming the interface people are familiar with. With Palm's limited size and budget it looked like a remarkably sane way to do things, they didn't have the funds to produce and android like IDE or XCode with an emulator.

Now competition is a bitch, HP maybe had 2 bites of the Apple before they'd have to double down and build their own javascript JIT and optimize the ever loving hell out of their cut of WebKit but it's not impossible and relatively speaking, with their budget and funds and everything, I'd say it doesn't look that difficult either. They could even cut their own ARM chips and clock them faster, put in webkit specific stuff if they wanted to, we're talking about a giant company here.

HP's problem is they are probably the worst run company of this century, they have a dysfunctional executive staff and board of directors (spying on each other? CEO sexually harassing an actress? really?!?) All they had to do is throw a tiny amount of money at it and make some public proclamations about being in it for the long haul and WebOS would have done better. Pay some app developers and throw some actual money at it and it could dislodge RIM in time, no joke. Just politics and stupidity with HP is the problem here, nothing technological. Literally, all HP had to do was just say that WebOS was their platform and start developing for it, actually, I think they could just say that they were developing for it, they probably didn't need to actually make apps. They just don't get it. Just cutting it loose isn't going to keep it going either, it needs support and hardware.

Re:Evidence shows another thing?

[gl4ss]

yep, you would have needed probably to pass the data through to tcp/ip too locally to your native part, not very feasible for most engines. I'm unsure if you would have needed this on webos if you wanted a native look and do your ui mostly in the webkit shit. you would have needed to do this(or a browser plugin) on nokias web runtime from couple of years back too - doing a local http server and etc would have been a lot less messy on symbian than doing a browser plugin - no wonder it was pretty much a failure for it's seemingly intended uses besides packing simple web apps as applications that appeared on the menus as their own links - for which you could have rolled your own solution anyways with little trouble and which was done by multiple people multiple times, which I HOPE is not why nokia thought it was such a great idea to burn so much money on webruntime because then I would be to partially blame *shudders* - by the way using a native http server to do native things would have been feasible on nokia's EXCEPT for the fact that it lead to the installation being too complex for average users. using the same method for doing JNI from j2me was tried multiple times by multiple people on nokia's platforms as well - in fact, I think the biggest reason why symbian didn't fare too well was that the flavor that nokia went with, s60, lacked jni from java programs, if it had that then it would have been superior to android in almost every respect and wouldn't have had such bad reputation as being developer unfriendly, fwiw on series80 and series90 the java was fuller and had jni possibility).

but for some image manipulation and such, for a camera app or similar, it would have been feasible to use the native part on android.

Web Obsession

[Anonymous Coward]

There seems to be an increasing obsession with using browser technology as *the* technology, and it sucks big time.

The web started as a way of displaying text - and later text plus graphics - with a mechanism to like pages across machines; its that latter bit that is Tim Berners-Lee's brilliant insight. Unfortunately - and this clearly isn't TBL's fault, he'd have needed a crystal ball to have seen what was coming - people wanted to use the browser to ever more sophisticated stuff (essentially to become a means to run remote applications), and this got bolted on top of the HTML. In a sane world, the browser would have provided a set of widgets and the means to manipulate them (basically, a GUI library, but sandboxed) and would have exported an API to manipulate them, and HTML should have been an application layer on top to make text presentation easier. Instead, we have a system where the HTML is exposed via the DOM as the API, and that is what you manipulate. The result is the HTML/CSS/JS abortion that we fight with today.

I work for a company (which is why I'm posting as AC) that is implementing what amounts to a desktop application (and which will be delivered to a relatively small number of specialist customers who will pay multiple thousands of dollars equivalent for licenses), implemented in Python using a well-known Python web toolkit, running under a Python web server, and displaying in a customised version of chromium. Plus, some custom compiled graphics stuff. And its a total pig to work with, you have all of the problems associated with a connection-less client-server, and all the extra problems of UI programming inside the browser.

If this was the way HP went, then they deserver to fail and thank (insert deity of choice) they did, rather than yet another noxious system was foisted on the world.

Re:Web Obsession

[Anonymous Coward]

You've only just noticed? I also don't understand this weird obsession with trying to make a page markup language into a platform: a task it was almost designed to be bad at. Ditto this odd reliance on HTTP as a transport for everything instead of using or designing more appropriate protocols.

Re:Web Obsession

[TheDarkMaster]

I agree with you. It's just stupid to want to make a desktop application using HTML, you need to double (or triple) the work required for the same result. You can make a Paint using HTML? Okay, it's possible. But at what cost?

Re:Web Obsession

[Anonymous Coward]

Really, you don't understand? It began as an easy way to bypass IT, which is basically the redheaded stepchild in most organizations. From there it has simply grown into the complete clusterfuck that bypassing IT should obviously have resulted in.

Re:Web Obsession

[TheCouchPotatoFamine]

there is nothing about XML applications or the DOM, per say, that make it suck. Apple has a "dom" (nib files) and it works quite well. The problem is obviously somewhere else. Something that could go faster, but we don't - for security, or for compatibility with magazines-in-html... but nothing about HTML, in and of itself has to be that slow, imho.

Re:Web Obsession

[TheDarkMaster]

You do not understand the problem. Let us say that in a desktop program, the act of responding to user command in a GUI (C, VB, Delphi, etc.) can be represented by a single step. To do the same step using XML, HTML, etc., you need to go through the necessary framework to first translate the XML/HTML in runnable code and only then run the step corresponding to the initial example, based on the resulting translation (the same is not needed to the "native" application because he is already in runnable code).

That is, however fast your computer is, the application using XML / HTML will always be slower than the equivalent (native) on the same machine. Because it must run at least twice the work, until someone makes a processor capable of running HTML/XML directly.

Re:Web Obsession

[TheCouchPotatoFamine]

that is not true at all? what stops you from compiling the HTML/XML and emitting an intermediate form that doesn't require all that? what if i made XML that merely called C functions, using the id of the xml node as the id of function call? It would be plenty fast. Again, nothing about XML in and of itself precludes speed - and the DOM approach to UI's is very nice! the lack of speed, in the case of HTML in the real world, is caused by a slow rendering engine, IMHO. if security wasn't such a big deal, HTML might go very fast indeed - even as fast as compiled game application go.

But we don't have that. We have the stack, as you mentioned, slowing us down. But XML itself doesn't infer the existence of that stack.

Re:Web Obsession

[Andreas Mayer]

Apple has a "dom" (nib files) and it works quite well.

NIB files are not a document description. They are archived objects that make up the GUI. You can even put non-GUI objects in NIB files.

Re:Web Obsession

[benthurston27]

That sounds awful writing an app like that. I've been writing the app I've been working on with Python using the QT4 libraries. I use the webkit module of QT to display HTML, and it does that beautifully. And the Python basically works as a glue language to get all the modules that are written in C++ to work together. I don't know why anyone would, instead of something like that, decide to as the article was saying, use webkit and javascript to do the whole gui and program logic and everything. Anyway the way I'm doing it you get all the benefit of C++ performance, the easy programming of python, and the portability of QT without trying to build this complete inner platform where everything is running as a call to the browser instead of the operating system. What's next, the browser gets so much native app support that they program a browser within the browser for just viewing webpages securely?

Re:Web Obsession

[TheCouchPotatoFamine]

doesn't change that they ARE a document description - you're just defining document rather strictly :)

Wah!

[msobkow]

The open source world gave us a crappy rendering kit and we were too damned cheap and lazy to fix it, so our product failed. Damn you open source!

Re:Wah!

[UnknowingFool]

More like: "We got this open source rendering kit for free and didn't have the skill or people to modify it to do what it was never intended to do. Damn you open source!"

Bad article

[Lennie]

I think the people that wrote the article didn't really understand the HP/Palm people they talk to.

Web technologies will get a lot of a new API added in time, but to create the standards takes time, so Palm had to come up with them themselfs and it seems they could not get the right engineers (and standards relations) to add it to WebKit.

I think the conclusion should be:

WebOS is just to early.

Currently the Mozilla Boot to Gecko is doing something similair but they are also working on making all these new APIs new standards.

Re:Bad article

[gl4ss]

it's not that, they could have added any standard they wanted to webkit. probably did add a bunch of stuff, to interface phone functionality, messaging etc.

fyi, webos isn't the only in town which dabbled with and promoted the idea of doing all your apps with web technologies. the middle management reasoning is actually that it's because it's easier to do web apps and web guys are cheaper! in reality it doesn't pan out quite like that of course. instead you'll have a bunch of new problems(that and nokia apparently figured during 2007 or so in some circles that they'd fix the crappy symbian apis by ... wait for it.. building another layer on top of them without fixing the apis underneath).

there's also been a wide bunch multi platform toolkits, which have used js+html as the key for providing write-once-compile-for-10-mobile-systems. none of them actually seemed to get a lot of use.

a large problem for app developers who want to do something else than just applification of mobile web information services is that using web technologies to do something like garageband just isn't feasible even on fucking desktops.

Re:Bad article

[garyebickford]

Inner Platform Effect.

Re:You mean there's a difference between engineers

[marcosdumay]

Don't read too much into that statement.

There is a difference between nails too.

Who writes this crap?

[sgt scrub]

Since when has a renderer been the be all end all of an OS? Show the code. I got $20 saying someone in the FOSS can replace it without heavy lifting.

Re:Most stupid story

[WankersRevenge]

That was an ios 4.3 issue. It was resolved in ios 5.

There seems to be a lot of confusuin here

[Anonymous Coward]

WebOS used WebKit as its foundation to render the display.

Have to agree

[DarkOx]

WebOS was never going to do anything other than fail. Things like google Apps might be ok for really light work where shared access is the most important feature but they are the goto for very few people. Otherwise dropbox would not be nearly so popular. Don't get me wrong [xh]tml + java script might be a wonderfully flexible thing to develop your shell in but its not going to provide the rich experience users want out of an application.

No matter what the industry shills and marketing droids try and tell you tables are about data consumption and limited types of data acquisition, not creation. Consumers use them to read, watch, and play, and some very limited musical composition with external instruments ( the tablet is really an acquisition device), I have seen tools to catalog private collections of books,music, and movies, and you see QR and bar code apps to look up prices, homepages, and real estate ads. That is how these things are used in the consume space. You see more acquisition type tasks in the business logistics and medical space but its a toy everywhere else. You have to deliver a positive and rich multimedia experience and "web" technologies are basically the lowest common denominator in that domain.

Yes lots of IOS/Android apps are thin wrappers around webkit or whatever render droid is using that works for facebook, wikipedia, imdb, etc but the games and more interesting applications are native or VM code because they need to be deliver the experience people want; java script + html DOM are just not flexible enough and things like canvas don't perform well enough for use on power conscious devices.

Sending what is a basically a web browser with some java script libraries out to compete against polished binary platforms in a consumer already dominated by well polished easy to manage binary apps was space was not and is not going to work.

Re:Have to agree

[DarkOx]

For the record I am aware that you can write native code apps for webOS but that was not the preferred method being pushed by the vendor(s). We all know that working with lessor favored technologies from a commercial software stack tends to leave you abandon at the whim of some middle management guy at a company you have little or no influence over. So we know what technology the bulk of webOS apps were going to be written in and it was not going to be the C++ interface.

Re:Have to agree

[PCM2]

Sending what is a basically a web browser with some java script libraries out to compete against polished binary platforms in a consumer already dominated by well polished easy to manage binary apps was space was not and is not going to work.

Then it is fortunate that WebOS developers have an alternative.

Re:Have to agree

[msobkow]

Don't get me wrong [xh]tml + java script might be a wonderfully flexible thing to develop your shell in but its not going to provide the rich experience users want out of an application.

It depends. Is your purpose to develop business form processing applications that let employees do a job, or is it on providing a more specialized application that won't work effectively without a custom GUI design?

Either way, I've always disagreed with the idea of making a pretty GUI before you write the application logic. Build the foundation and business logic layers FIRST, then write the GUI to use them. Data and logic define a business application model, not the GUI.

Re:Have to agree

[msobkow]

It's important to note I've never dealt with a business application where the batch processing components weren't the CORE of what the business needed. The GUI was a means to FEED that back-end processing the data it needed, not the core functionality of the application.

webOS could have been so great if anyone had cared

[Anonymous Coward]

I used NeXT os'es in the 90s. It's the reason there are Macs at my house today. What you got with NeXT and what you get with OS X is a superior user experience. It won me over to the point that I eventually abandoned linux and the BSDs for any use but serving web content.

I was all set to buy an Android phone two years ago, then I downloaded the webOS SDK. That was it for me, and within a week I had snagged a Pre Plus on Verizon. I just replaced it with a Galaxy Nexus when that phone launched a couple weeks ago. I also have a Toucpad, which dual boots webOS and Android via Cyanogenmod.

The strength of webOS was an elegant interface with some really smart approaches to usage that I still feel are superior to iOS and Android. I will grant that Android has shrunk that gap quite a bit with ICS, and I'm really happy with my new phone. On the tablet, webOS is by far the superior tablet os to Gingerbread, however it does seem to suffer from some deal breaking performance issues that mar the otherwise excellent user experience. I also like that the tablet version of webOS very much feels like a fusion of webOS and Gnome.

I don't know what Palm could have done to get more users and developers, and ultimately the lack of both killed this os. IF it had taken off, I would be using the latest and greatest webOS phone now instead of jumping ship to Android. If I could have the Android ecosphere on webOS I would in a heartbeat.

It's too bad, but better doesn't always succeed in the market, and webOS will have to be remembered as a great little mobile os that almost could. It probably didn't help that the device they had to attract a userbase was a plastic hockey puck with a 3.1" screen, in a market filled with sexy hardware.

H.P.

[Raenex]

The New York Times really needs to move past putting periods after each letter in acronyms like HP. They do the same thing with acronyms like the NFL. It just looks stupid, because pretty much nobody else does that any more, even other newspapers. Language changes, and sometimes for the better.

Re:H.P.

[germansausage]

S.C.U.B.A divers with a L.A.S.E.R.

Re:H.P.

[PCM2]

The New York Times really needs to move past putting periods after each letter in acronyms like HP. They do the same thing with acronyms like the NFL. It just looks stupid, because pretty much nobody else does that any more, even other newspapers. Language changes, and sometimes for the better.

That's not language, it's style. Many publications have their own style guides. The New Yorker, for example, follows many standards that seem archaic, such as including a dieresis on the second vowel of a double-vowel word, as in "coördination." It's done out of respect for the tradition and heritage of that specific publication. As for abbreviations, you may note that the Associated Press styles the abbreviation for the United Kingdom as "UK" (no dots) but the United States is "U.S." (with dots). The English language itself, however, includes no rules or claims about such matters.

For the record, the New York Times rule is simple: If you pronounce the abbreviation as a word (e.g OPEC) then it doesn't get the periods. If you pronounce it by spelling out each letter, one at a time (e.g. F.B.I., I.R.S., etc) then you include the periods. It makes some exceptions, however; for example, the names of television networks don't get the periods. It's just the Times' own style.

Re:H.P.

[Raenex]

That's not language, it's style.

It's convention. It used to be common to put periods after each letter in an acronym. The convention changed in a way that's more streamlined, as it often does, and still using the old convention is a distraction, old-fashioned, and makes the newspaper look out of touch and downright naive when everybody else has moved on. You could argue it was a case of style if there was mixed usage, but at this point they are pretty much the only holdout.

As for abbreviations, for abbreviations, you may note that the Associated Press styles the abbreviation for the United Kingdom as "UK" (no dots) but the United States is "U.S." (with dots).

U.S. seems to be the one holdover, but I suspect eventually that will fall by the wayside too.

The English language itself, however, includes no rules or claims about such matters.

Language is based on convention, and the English language especially so, as many "rules" are commonly broken by convention. There's a blurry line between rules and style, and sometimes styles become rules or the rules change. Just look at text written 300 years ago -- it's pretty much the same language but there's a lot that would be considered "wrong" now. Or just look at dictionary entries and corresponding usage notes that change over the years.

Re:H.P.

[garyebickford]

Ain't.

Re:H.P.

[zlogic]

Probably because U.S. means Unites States while US may be confused with uppercase "us" (as in "we").

Re:Most stupid story

[dabadab]

IIRC, one of the major things with iOS was that graphic routines would be given priority over everything else

Why does this bullshit have to be repeated over and over again?...
It's simply not true: Android also have higher priority for that as that's a very-very-very basic technique. If you would take a look at the original article, it's spelled out very clearly.

Who cares

[vlm]

now say the product never had a fighting chance because it relied on WebKit

Who cares. The apathy is shallower than that.

It never had a fighting chance with the users because it was just another wannabe. What was special about webos from the user point of view, other than some "HP" branding, which in the old days meant something, but for more than a decade that brand has come to mean outsourcing, downsizing, clueless dilbertian executive management, hatred/screwing over of customers, and failure? So its just like my friends phones except it's not cool, and it can't run any of their apps. How profoundly unappealing to the users, and not because of the intimate details of the development library. "My alternative phone is just like yours except its not as good, not as cool, doesn't do anything yours can't do, yet costs just as much". How can that not fly off the shelves?

It never had a fighting change with 3rd party devs because it was just another wannabe. A wannabe has a chance if it does or uses something new and exciting, to balance out the lack of popularity. You know what would be weird? A mobile OS written completely in Ruby and Erlang. How truly weird, yet fascinating. I'd take some of my valuable holiday vacation time to play with that platform even if I were the only owner of that kind of phone in the whole world. Thats how internal OS library choices drag in developers. But, its just tech I can play with in more convenient systems, F that, I'll play with Android instead, or more likely play Skyrim some more. Whoops.

So that brings me back to my original summary. Does anyone not a HP employee, in engineering or astroturfing, being paid to toe the corporate line want to develop on webos? My guess is, "no". Who cares.

Nobody wants or needs it seems to be the actual "fatal flaw".

The standard /. car analogy is the famous Alaskan "bridge to nowhere" was not fatally flawed because it would have been much more appealing to paint it a slightly different color, it was fatally flawed because "no one" (rounded down to zero) wanted or needed it, other than the guys who built it.

Re:Who cares

[dcherryholmes]

"What was special about webos from the user point of view?"

1. Cards metaphor, true multitasking
2. Synergy, and the notification system
3. Bluetooth pairing even with non-webos phones, to accept calls and display SMS messages.

Off the top of my head.

Re:Who cares

[Khomar]

I have not played with the iPhone much, but compared to the Android, I would choose WebOS hands down. I love the interface and the multitasking abilities. It is my hope that open sourcing WebOS will give it some new life, because I really would like to see the OS continue. It holds a lot of promise, and I would hate to see the UI ideas go away.

Disclaimer: I am an HP employee, but I have no connection with the WebOS or TouchPad team at all. I was able to get a hold of a TouchPad through the employee fire sale, but other than that, I come at it as simply another user.

Re:Who cares

[vlm]

Ahh from the users point of view thats either weird or not new or not new anymore.

1) My android phone can play google music while I do other stuff like the kindle app.

2) Again my android phone and my ios ipod touch have a notification system. I find it annoying. Just another inbox to check, whats yet one more...

3) Not even sure how to replicate this. I think you mean I could pair my phone to my wifes phone like an extension phone? Thats just ... weird. Isn't that just pairing to a automotive hands-free interface except the interface happens to be another phone? Thats so weird I don't even know if its new or not

Re:Who cares

[dcherryholmes]

1.) I also own android devices. The multitasking there is limited to certain apps. You have to close one app to open another, and how it behaves while backgrounded and where it will be when you restore varies greatly.

2.) Yes, but the notification system in WebOS is just better. Also, the other half of my second point was "Synergy," which folds your emails, IM's, and SMS's into a unified system that is very nice.

3.) This one is my fault, as I was thinking specifically of the touchpad. On the touchpad, you can pair the device with a phone, and route your phone activity over to the tablet.

Out of curiosity, have you used webOS?

Re:Who cares

[thsths]

> 1. Cards metaphor,

Nice, but that is just the task switcher. Sure it is nicer than Android (2.x), but does it matter in the grand scheme of things?

> true multitasking

Android had multitasking for a long time, but it is optional (as it should be).

> 2. Synergy, and the notification system

Nice, except it was poorly implement, and only worked sometimes. Android has something similar, not as nice, but it seems to work much better.

> 3. Bluetooth pairing even with non-webos phones, to accept calls and display SMS messages.

I didn't even know that. And I wonder why you would want to lift a tablet to your ear instead of your phone?

I agree that the card feature actually got some media coverage. But on the whole I am quite underwhelmed with OS - it is very much missing that "killer feature".

Re:Who cares

[Anonymous Coward]

2. No, there is nothing in Android approaching Synergy. Not even close.

Re:Who cares

[Anonymous Coward]

2. Synergy, and the notification system

Nice, except it was poorly implement, and only worked sometimes. Android has something similar, not as nice, but it seems to work much better.

Care to back that up? What about synergy was poorly implemented, and what about it only works sometimes? Android has nothing similar. Do you even know what synergy is?

HP's management must really suck, basically.

[Medievalist]

What I get out of this is that it's impossible for anyone with real talent to work productively for the people in charge of HP's WebOS.

Opera's guys have major talent, as you pointed out, so they'd probably be unable to work with them either.

Re:HP's management must really suck, basically.

[Anonymous Coward]

HP realizes about every 10 years that retention is important, and goes on a retention binge. Then it gets checked off the list and forgotten. Mark Hurd chopped people who knew what they were doing because they were expensive. Anyone smart enough got out under Leo if they could.

What's left are the people who were too inexpensive to show up on the radar, and too dumb to run away to be better paid. Not so different from every other company, but we had a cost cutter followed by ineptitude squared, so it's much worse than it could have been.

There are a lot of smart people left still, but they are doing their work plus the work of someone who left. I got a raise, bonus, and stock, but I'm pursuing an external offer. I'm going to have to see for myself how serious they are about retention - I bet my middle management won't be able to match an offer, despite wanting to.

webos developer here - the "insider" has no idea.

[ardiri]

um.. PDK (plugin "native" development kit)?

https://developer.palm.com/content/resources/develop/sdk_pdk_download.html

it was only the "enyo" and "web friendly" development environments that used webkit. you can write very powerful applications using native code (SDL, open GL) - which under the hood utilized CodeSourcery Toolchain—Sourcery G++ Lite for ARM. in fact, a lot of our games ran better on webos than on ios due to apple's insane requirement that there was no framebuffer available for graphics and you have to do everything via open GL.

i think these "insiders" do not know what they are talking about. but the fact that there are no more devices being made - i guess the whole discussion becomes mute.. relying on $99 fire-sales to get users to develop against does not work in my books.

Fatally flawed because it was web based

[Kludge]

I played around with a palm phone w/ webOS for a while. Its fatal flaw was not webkit, but that everything was web based. It assumed that you had unlimited wireless data. I could not even be boot up the phone without a cell data plan. It would not even use my wifi access point. The palm web site strongly recommended purchasing an unlimited data plan because it used so much data.
Then all the carriers dropped or heavily restricted their unlimited data plans. Ouch.

Re:Fatally flawed because it was web based

[Jjeff1]

What?
My old palm pre is on my desk right now, it operates in airplane mode and works just fine, with no cell plan at all. My data usage was less under palm as compared to my verizon android phone, though I suspect this is because there are more free ad supported apps on android.

Re:webos developer here - the "insider" has no ide

[maroberts]

One wonders how many developers were made aware of this or whether they produced apps through the WebKit interface because they weren't aware of an alternative.

Re:webos developer here - the "insider" has no ide

[ardiri]

when you download the SDK, you get the PDK included. this was only recently the way however - with 3.0 SDK.

webkit is the same in safari as in webos!

[lkcl]

a number of people have caught on to the fact that the engine behind webos is the exact same engine as behind safari, but that safari is *not* the basis of apple's operating systems. the glue that makes apple's OS so dynamic is objective-C, which has built-in runtime dynamic data typing similar to DCOM. that means that components can interact, written in c++, or any other programming language including scripting languages, *without* having to recompile any applications.

no, if you want to know why webos is so fracking slow, you only have to look right here: http://opensource.palm.com/3.0.4/index.html

notice anything? keep scrolling down... keep scrolling down.. lmnop..q... ah ha!

qt4 qt4-4.7.1.tgz qt4-4.7.1-patches.gz

that's the reason.

how do i know this? it's because i was asked, 2 years ago, to get pythonwebkit up-and-running for an embedded client, running on a superb but very strange 400mhz ARM9 processor with access to 800mhz DDR2 RAM (for doing 1080p HDMI video). for an ARM9 it ran like lightning. *but*... when i put pywebkitqt4 on it, it not only doubled the amount of memory usage but it absolutely _hammered_ the processor.

the startup time _just_ for webkitqt4 alone was something like 90 seconds and took up almost all of the available 256mb of RAM. the next best was webkit-enlightenment (130mb and about 8 seconds). webkit-efb was what samsung sponsored for the "bada" initiative. next after that was webkit-gtk at around 6 seconds.

however none of these were acceptable, so i helped denis do a port of webkit to directfb. that got the startup time - on a 400mhz ARM9 - to a stunning 1.5 seconds.

if HP or Palm had paid myself and denis to do that work several years ago, things would have been very different: the startup time and performance of WebOS would have been staggeringly quick.

and the thing is, because the browser _is_ the OS, there's absolutely no good reason to even have GTK, QT4 or in fact any other "engine" underneath. why do you think google created an entire new direct-rendering API ("silk" i think it was called) for android?

lesson learned. only cost $1.2 billion. i would have been happy to have been paid 0.1% of that to fix the problem. talk about irony.

Re:webkit is the same in safari as in webos!

[Bananas]

For the love of $DIETY, please, involve yourself with what is left of WebOS if/when it is released. Gnome, KDE, etc. are all showing their "age" and "Windows 95 everything-is-an-ugly-component" mentality. If WebOS is truly open-sourced (not fake open-sourced) then there is a slim, slim chance of having a desktop that actually would be a delight to use, instead of the goddamn window-explorer-desktop mindset that has dominated the GUI space for decades.

Re:webkit is the same in safari as in webos!

[Anonymous Coward]

First off, PyQt isn't exactly the best benchmark of Qt/Webkit performance on a mobile device. Secondly, webOS doesn't load a new instance of webkit when you launch a new app, just like opening a new tab in your browser doesn't require loading a new copy of webkit. Mobile devices rarely need to "boot"; hitting the power button just turns on/off the screen. So system-level initialization time isn't critical for most people.

Finally, webOS doesn't use QtWebkit at all. It uses a custom rendering library called Piranha for graphics operations. The equivalent in Android is called Skia.

There's definitely a lot of performance issues in webOS, and Qt sometimes carries a lot of bloat, but it'd be jumping to conclusions to claim that Qt is the cause of the performance issues on webOS.

Re:webkit is the same in safari as in webos!

[Anonymous Coward]

webOS currently uses its own port of WebKit. Only the System Manager Currently uses Qt. The long start up is due to multiple JavaScript applications being launched at start up. If the applications are not pre-launched, the start up time is actually pretty quick.

Re:webkit is the same in safari as in webos!

[Anonymous Coward]

What makes you think that the webkit part of Qt was used? That was prototyped, determined to be too slow at the time & reverted back to using WebKit directly. The only part of Qt that is used is QtCore & QtOpenGL which are not the problem. A large part of the problem was LunaSysMgr (the window manager + compositor + event manager for WebOS) - it's ridiculous how much memory it takes up. Every single "card" takes up a full-screen resolution, even though only 1 card is visible full-screen at a time, thus 600KB for a 480x300 screen. Scaled back, the cards are (IIRC) 0.75 the full-size, which amounts to 300 KB. On the Touchpad, this is 3 MB & ~1.7MB respectively. Furthermore, typically you only have 3-5 cards visible on a screen at a time. Thus instead of using a max of 1.5 MB of memory, for 10 open apps you're using 6 MB (8.5 MB vs 30 MB on Touchpad).

Another problem with SysMgr that is somewhat trickier is that instead of building a scene graph, it utilized Qt's rendering pipe-line which simply went through each hierarchically component & rendered it, which is slow in OpenGL, but even that was worked around (notice how the launcher in WebOS 2.0 was really fast - there was a lot of work that went into making it like that).

Other issues include that the OpenGL rendering used a blocking call to know when to start painting the next frame, meaning you had only a portion of 16ms to draw, animate, & process events (to get 60fps).

And this was just SysMgr. You can find examples like this in many places. Too many hacks by too many people who didn't think through those temporary hacks (nor put any effort to resolving them).

But at the end of the day, none of it mattered because if you don't have customers who want to buy your product.... the shitty marketing campaign which turned away customers and burned a ton of cash... the shitty carrier relationships forcing Palm to carry a huge inventory....

Re:webkit is the same in safari as in webos!

[benthurston27]

I don't know if I'm missing something. But I'm writing an app in pyqt4 and the python interpreter with all the qt4 libraries loaded up including webkit and my application running take together 20MB. I can't compare the speed of the loading of the interpreter and the app between my quad core desktop and a arm9 400mhz, but everything's instant and my actions in the app don't even seem to register on the monitor for the processor's activity. Maybe they botched the port for webOS, but I've found it to be really performant on the desktop. Why does performant trigger my spell-check that's a real word isn't it?

"Insiders", right...

[Anonymous Coward]

The problem was not WebKit. WebKit is what is fueling the web vs native app debate. The problem was a personnel problem. They were right that Palm couldn't snatch up top WebKit engineers. But when you have "insiders" that come out saying webOS was fatally flawed, you're already running on fumes. These insiders were a cancer that destroyed Palm from within. They weren't motivated to deliver a finished product for the Touchpad launch. It was these "insiders" who killed webOS.

Re:webos developer here - the "insider" has no ide

[RoccamOccam]

The download link for the PDK used to be right under the link for the SDK on the Developer website. It was very clearly spelled out which kit did what.

was there a widgets library for the native?

[gl4ss]

because that's important bit of information.

games don't need it usually, and most games for webos were just linux apps running on sdl(that played without recompile with some tricks on maemo).

HP management is made up of 4th and 5th stringers.

[Anonymous Coward]

I think it's more like HP management is made up of 4th and 5th stringers.
You're only as good as the team you build.
In general, If HP didn't build shit, we wouldn't have to suffer with all the shitware they bundle on their PCs.
Replace 80% of HP mgmt/board C levels with something remotely competent, including the new so called CEO, Carly Fiorina v 2.x.

OS not the problem

[Jjeff1]

Palm Pre was my first smartphone, so perhaps I'm biased. But the user interface was far superior to andoid or iphone. It is just more intuitive to use, and easier to open apps and manage multiple open applications.

Palm failed due to underpowered hardware. Sprint was the first big carrier, they released the underpowered pre, then nothing to replace it. Pre 2 was never released in the US ( I don't think), same with Pre 3. The real story of the failure of webOS is really about the lack of hardware.

Re:OS not the problem

[Anonymous Coward]

Yeah the number of hardware failures they had were way too high. They didn't release a mechanically sound device until the Pre2.. Also it seems like HP diverted all of Palm's resources directly to tablet development and didn't do squat for marketing anything else.

Re:OS not the problem

[Anonymous Coward]

Yea cause the iPhone 3GS they sell today with a mere additional 100mhz on virtually the same CPU is a slug.

Re:OS not the problem

[coolate]

Pre2 had only limited release, but it is way faster, and works great, compared to the pre and pre+ that just worked ok. I agree, it is still a better experience than any other mobile OS. I have used the iPhone, and tried very hard to like android, but eventually went back to my pre2, love it! Veer and pre3 are also great hardware, that never got a chance... Was not an issue with the OS, it was an issue with the company selling it...

Typo in article title

[Anonymous Coward]

Insiders Call HP Fatally Flawed

fixed :-)

Dejavu

[bussdriver]

CEO Meg Whitman explaining away another big HP failure that was not her fault? Why does this feel familiar?

A lot of people should have quit so she could blame them for her troubles-- could you get a better recommendation than the CEO saying they are failing because you quit their huge corporation? (except perhaps that it is Meg Whitman...although maybe nobody holds her record against her anymore since they did hire her back again.)

Re:webos developer here - the "insider" has no ide

[Sez Zero]

i guess the whole discussion becomes mute

Or moot even.

But probably not mute, because there's a whole big thread of noise on it right here. And if you think a thread of text is quiet, think of all the spit-takes, laughing and angry words had when reading and writing replies.

Or maybe I'm the only one that talks to my monitor.

Bupkis!

[Mumbly_Joe]

This article is bupkis. ChromeOS is based on Chrome, which is based on WebKit. Seems to work just fine.

Re:Bupkis!

[mjwx]

This article is bupkis. ChromeOS is based on Chrome, which is based on WebKit. Seems to work just fine.

ChromeOS is not trying to be a full OS like WebOS was, it openly acknowledges it's designed to be limited and recommends you go elsewhere if you need anything more. ChromeOS is an example of a limited purpose OS, designed that way from the very start.

First there was KHTML,
Then Apple took KHTML and made it into a browser. They called this WebKit
Then Google took WebKit and made it usable.

Chrome has grown faster then Safari ever did (despite Apple shoehorning it into Itunes Microsoft style) because Safari is a pain to use and Chrome is a pleasure to use.

Re:webos developer here - the "insider" has no ide

[Anonymous Coward]

Agreed... the real issue was letting the WebOS talent walk after the Palm acquisition. What is the point of acquiring the OS without retaining the architect?

Sounds like the insiders want to blame the software when the real issue was them ignoring the talent they paid a premium to acquire.

JavaScript was a joke that got taken seriously...

[VortexCortex]

0. Dynamic Scripting Engine
1. Efficient Operating System

Choose ONE

Compiled VM Bytecode can be transformed into static machine code for a given platform, ala modern VM's: Java, Davlik, etc. JIT compilation tries to do the same thing, for dynamic language platforms (like JS) but it's still got to have an interpretor abstraction layer to support the dynamic changes. JavaScript is a prototype based system, which means I can replace the .toString() function at any time during runtime, and even generate new code to execute on the fly. It's a clusterfsk if speed and/or security is your concern.

iOS runs on the metal. WebOS has multiple layers of indirection between the "program logic" and the metal. Hell even, LuaJIT would be a FAR better choice. It's not like we don't have choices folks. I make extensive use 8-10 languages on a regular basis (two of my own design), JS being one of them; I'm talking about embedding them and working with the under-the hood stuff as well as development in the languages themselves. IMHO, JavaScript is a night-mare that was designed without any thought given to the implementation's performance or speed whatsoever -- It should be considered harmful.

JavaScript isn't a good choice for the Web. We all just use it because it's available, not because it's any better than anything else... IT'S NOT. Here's a hint: I haven't written anything useful in BASIC in 20 years, and I don't miss it one bit.

Apple was buying an OS once, too

[eminencja]

It still baffles me - how dilbertian do you have to be to shell out 1.2 bln $ for a hack that took just nine months to develop?

When Apple was looking for a new OS back in the 90's they approached BE Inc. (who were working on a new OS at the time) estimating that BE was worth 50 mln $ at most. BE refused the offer asking for well over 2oo mln $ assuming wrongly that Apple had no alternatives; Apple ended up buying NeXT and bringing back Steve Jobs to Cupertino. (They also considered licensing Windows NT from MicroSoft.)

Re:Apple was buying an OS once, too

[Anonymous Coward]

Well, if you're going to buy a mobile OS, there's not a whole lot of choices. There's a litany of projects that have taken *far* longer than 9 months with even less to show for it -- Meego, Access Linux Platform, LiMo, RIM's new QNX-based OS, etc. Which is to say that if you want your own mobile OS, even a poorly constructed OS costing $1.2B is more likely to succeed than rolling your own.

Only some apps need speed and we have the tech.

[Anonymous Coward]

So the problem seems to be that apps are written with web-browser technology and can't compete with "fast" code. Here is my solution to HP, completely free: for demanding apps use Google's NaCl. The Chrome OS after all works in exactly the same way.

Re:Only some apps need speed and we have the tech.

[coolate]

or demanding apps, developers can use the PDK, its allows use of lower level c and c++ code. Angry birds and the need for speed game both use it.

Re:JavaScript was a joke that got taken seriously.

[Anonymous Coward]

Totally agree with your comment. They couldn't manage to choose. Fully compiled OS is a way better choice until we reach the point when processors are so powerful that the OS animations and user interactions are totally insignificant. Probably won't be true for another few years. So you could say that webOS being built in 2008 running on webkit was about 7 years ahead of its time.. which is equivalent to saying that it was a big mistake to choose to go that way.

You can clearly tell the method that Apple went with. When you scroll a list, it effectively is scrolling an image left and right or up and down (not a dynamically updating javascript/html page). This makes the OS appear to be fantastically smooth and fast in iPhone case and can run with less memory and less processor power--in fact it appears that this will be a huge benefit to Apple when switching to higher resolution displays like the iPad3 may be. This smoothness you see on iPhone/iPad is equivalent to people that drive a car for the first time and saying "man the ride is smooth, and quiet, and it feels nice when I turn the wheel".

webOS appears to be dynamically loading things as you are scrolling, dynamically resizing things, overlaying multiple layers, etc. Honestly, its not clear what the real benefit of that is, but it has a major downside, which is that it makes scrolling and context switching jerky. It also feels like when you are moving icons or lists around that you don't have full control of them because they sometimes stutter. I still don't know why Palm didn't simply just take a "screenshot" and scroll that around, then unfreeze the "screenshot". In reality the "screenshot" would actually be an image much larger than what is on the screen. But the point is that there is no reason to use so many dynamic elements when there is little upside but huge downsides.

High level manager blames his own team

[Anonymous Coward]

Yet another high-level manager who doesn't bother to understand the low-level and finds someone else on his team to blame for his mis-management.

At least Apotheker and Hurd didn't do that.

Oh yeah?

[Anonymous Coward]

I'm an insider, and I call WebOS software inherently awesome.

Xbill

[Anonymous Coward]

Is this the same Matias Duarte that created the game Xbill? I loved that game. I played it the first time shortly after my first Linux install (Redhat 5.0?) around 1997.

If it is the same person, he is a living legend in my book. I couldn't care less about WebOS.

Works fine!

[coolate]

I have been using webOS for years now, it works just fine, and the newer hardware like the pre3 kept up just fine with the iPhone, also they forget to talk about the fact that webOS has a PDK that allows C and C++ apps, so apps like angry birds run at full native speed. As a developer, we were able to make a canvas based game, that played just fine, something we could not do on android or iOS, canvas and javascript were just to slow on them. True a lot of talent has left it now, but when it goes open source, it will allow many that find no room to work on android a home.

Re:webos developer here - the "insider" has no ide

[coolate]

Totally Agree. The PDK has been around for over a year, and is very well documented. I am also a developer, and this "insider" info is nothing but bull.

Evidence

[Anonymous Coward]

Evidence as provided suggests "open source" Webkit a Trojen Horse perpatrated by Apple for the purpose of slowing web development so as to enhance their efforts (with closed source Webkit), enhance their market share and further their gains in patent holdings which means OEM license agreements tot THEM.

was webos aimed at high performance?

[shadowrat]

I never thought the idea behind webOS was to create the highest performance UI. I thought it's selling point was the low barrier to entry for development. At least that's what i remember the selling point being back in '09. iPhone was king. Apps were huge and everyone was talking about how Palm's app store was going to swiftly rise to the top as the whole world began creating apps with html and javascript instead of that unforgiving objective-c.

That sounds like a sound engineering decision to me. Lets trade some performance for ease of development. That mantra has boosted countless platforms over the years. Everything from .net to java to, well, even c++ is really trading performance for ease of development.

Plus, if UI performance was really all it took to be a good phone, Android wouldn't be where it is right now. Android in '09 certainly didn't hold a candle to ios when it came to snappy UI. Honestly, i remember webOS being pretty snazzy. Also, android wasn't exactly known for having a good api either. I don't really think the tech was what hurt webos. Maybe it didn't perform like IOS, but it seemed as good as android and more accessible at the time.

I think if anything was fundamentally broken with webOS, it's that the company didn't remember what they set out to make. Their app store certainly wasn't friendly to developers. They don't even seem to remember why the ui was webkit based.

Re:Modern cpus handle such loads pretty well

[DocSavage64109]

"Modern cpus handle such loads pretty well."

Funny. They've been saying that ever since Pentium 90 days -- maybe even before. Unless you're counting cpu's with integrated gpu units, I doubt they'll ever compare to equivalent generation discrete hardware.

webOS seemed smoother to me than Android

[Anonymous Coward]

I bought an HP Touchpad with the intent of putting Cyanogenmod on it, but I played around with webOS a bit to see what all the fuss was about and I have to say that it seemed smoother and more responsive than Android on my G2. I was expecting it to be even slower/choppier than Android, but I was shocked at how fluid and smooth all the transitions were and made me hope that all the promises of ICS fixing the slowness in Android are true.

Re:Modern cpus handle such loads pretty well

[anomaly256]

We're not talking about rasterising 3d objects into a 2d plane here.. we're talking about SIMD-instructions moving 1's and 0's from one memory address into another (framebuffer). CPUs /are/ very good at this today.

Re:Modern cpus handle such loads pretty well

[anomaly256]

And besides, the 'handle such loads' remark was referring to the context switching and script interpreting.... I'd love to see a gpu-accel'd javascript interpreter

parent moderation

[Medievalist]

Inside information, score zero. Welcome to the post-Taco slashdot, I guess.