“WebKit remains not ready for prime time, because the Web cannot deliver yet.”
– Paul Mercer, creator of a non-Web OS
There has been a lot of chatter over the article on the HP Touchpad flop, which conflates success of the Touchpad with the success of webOS and even gets into anti-Web territory.
I do think that the HP Touchpad was doomed, mainly due to how it was released before ready, with the hardware of an iPad 1. It wasn’t fair.
The sad thing is that there is a great story behind the rise and fall of Palm (and webOS). I wasn’t there for all of it, but learned a lot from stories… and my time in the belly of the beast. Palm was a juxtaposition for me. On the one hand I met phenomenal engineers. They were hard working (working all hours of the day for my entire time there, and I know beyond), and cared a lot. Many of them came from Apple, and other great companies. Some folks are posting that Palm should have hired better caliber engineers, and that is just wrong….there were plenty there. The fact that they shipped webOS in the timeline that they did amazes me. The other side of the coin is one of dysfunction throughout the company. Going up against iOS (and later Android) was a tough proposition, but I really think that we coulda been a contender, and we shot ourselves in the foot time and time again.
The New York Times article quotes Paul Mercer heavily. It is important to know where those quotes are coming from. Paul is a technologist who left Apple to create the Pixo OS (which sold to Sun) and later created technology that Palm acquired. This was not webOS as you know it. It was a Java based operating system (hand written JVM!) with a proprietary XML dialect for layout. Does that sound familiar? (I have seen Paul and Andy Rubin together in Los Altos many a time :) Can you imagine if Palm came out with a new OS that was basically Android, but not Android? It would have flopped. Instead, imagine a brave engineer hacking WebKit as the head to the system…. and suddenly you have webOS. There was a reason that people were excited when Palm announced webOS. The user experience was superior to iOS of the time in many ways (cards, network sync, multi-tasking, etc). For developers, especially Web developers, in theory they could write web apps that would live in this beautiful UI.
In practice, I admit that there were real issues. webOS 1.0 was more like a beta. Timing required that it just had to ship, but the performance wasn’t there and it was buggy. The article also mentions the return issues on the hardware. If you think about it, this is beyond a bummer. Apple has their own stores that customers can’t wait to go to. When you walk in, the experience is all Apple, and you will walk out with some of their product. Contrast that to where webOS devices were. I don’t know about you, but I never enjoy walking into carrier stores, and even in retail venues such as a Best Buy…. you are surrounded by competitors product. If the sales force sees a large return rate, they will push people to buy something else. I remember going into Sprint stores asking for a Palm Pre and being told “hey, get a Blackberry instead!” That was an immediate “uh oh” moment for me. The sales channel was poisoned. Doom.
With the early webOS releases, there were scrambles to fix issues on software and hardware, and then a classic second system syndrome kicked in. Many shortcuts were in place, so people wanted to go in and fix those problems and “build it right”. There were some real core architectural issues to be fixed here too (no sandboxing of apps so any bad code could mess up any other bad code, a lesson not learned from Pixo) and “fixing” these in a performant way is far from trivial! Needless to say, webOS 2.0 came waaaay too late and didn’t fix the core performance problems. In hindsight it would have been much better to have had a performance tzar who had people sitting with profilers open and fixing the darn problems.
The structure of the teams was also wrong in my opinion. App teams ran all the way up and down the stack, and there was no real platform. At one point there was a VP of Developer Platform that didn’t have direct reports that mapped to the platform itself!
So, there were a ton of core issues, from market timing to executive decisions etc… but none of these meant that the Web wasn’t up to the task.
Brendan Eich mentioned that B2G already has 60Hz flicker/tear-free panning/zooming using HTML/JS/WebGL. and that isn’t on bleeding edge devices. It is hard work to pull this off. Apple has a core system that is optimized for this, and they have to work their arses off to keep it solid (I am sure), and Android still has a ton of issues here, even with dual-core systems. It is naive to think “all you need is GPU acceleration!” and that there are other silver bullets. Blood, sweat, and tears is still needed. When you have a GPU in the mix, you have to worry about moving data between CPU and GPU… and using both in an optimized way. iOS views map nicely to GPU textures which is great, and can help a lot at the architecture level. Another great example is Kinoma. This crew came from the Quicktime and Carbon teams of Apple. Check out their demos and then think to yourself…. this is all done in software. Videos playback beautifully and when you minimize them they keep playing as their shrink into the icon location. Amazing. Again…. blood, sweat, and tears… on low end devices.
Don’t get me wrong. A Web runtime is a tough proposition. The Web wasn’t built to be an app platform, but its evolution is fast. Core platforms such as WebKit, and V8…. with standards such as WebGL and hardware accelerated graphics, make it better than ever to pull this off. But those who poo-poo the Web as “just a document platform” miss the great things about the Web. This is where webOS missed out. It was a Mojo platform more than it was a Web platform. We tried to change that and get functionality into the Web platform layer rather that in the “user land” of Mojo.
If we brought a true, reliable, performant, Web platform with the great UI of Matias and friends…. webOS wouldn’t be in the hands of Meg right now.
Great engineers, such as the Enyo team, keep the torch alive. Being able to create an Enyo+PhoneGap application that can deploy to iOS and Android as well as webOS is key. I keep harping on PhoneGap Plugins as a way to get into the land of native when needed… and it *is* needed. Android WebKit and even iOS WebKit are not there yet. At Walmart we build native+Web hybrid applications for a reason, but in my heart I long for someone to come along with a true Web runtime that lets developers write to a standards-based multi-vendor platform that no one company owns. Democracy is messy, but the Open Web is worth it. Don’t read one article and think that it can’t be done.
We often love to focus on the mistakes. The things that “went wrong”, but there is a lot that went right too. To truly learn from the rise and fall, it is important to know both sides.