Steps to save webOS(quirksmode.org)
quirksmode.org
Steps to save webOS
http://www.quirksmode.org/blog/archives/2011/08/twelve_steps_fo.html
19 comments
Doesn't TouchPad come with built-in DropBox integration? I haven't tried it, but at least DropBox was in the accounts list.
Agreed that Enyo is cool. Reminds me a lot about QML: http://doc.qt.nokia.com/4.7-snapshot/qdeclarativeintroductio... ...especially with Qt Quick Components: http://labs.qt.nokia.com/2010/09/10/building-the-future-rein...
Actually, I wonder how hard it would be to either:
1. Map Enyo to QML so that webOS apps could be run elsewhere
2. Make QML run under Enyo, so webOS could have apps from other systems
Agreed that Enyo is cool. Reminds me a lot about QML: http://doc.qt.nokia.com/4.7-snapshot/qdeclarativeintroductio... ...especially with Qt Quick Components: http://labs.qt.nokia.com/2010/09/10/building-the-future-rein...
Actually, I wonder how hard it would be to either:
1. Map Enyo to QML so that webOS apps could be run elsewhere
2. Make QML run under Enyo, so webOS could have apps from other systems
I was actually thinking QML too when I started using Enyo. There is a huge difference though, QML is yet another language. "We should totally reinvent CSS and HTML!" If I had a nickel for every time that happened...
The difficulty of running QML on a webOS device, or Enyo apps on Android or iOS, is not technical. It's more about look and feel. One glance into Qt code (not QML, Qt proper) and you can see how painful it is to make a single app look native across platforms.
Here is where I think Enyo has potential. It should be possible to style Enyo for different platforms AND to easily include components that implement OS specific behaviors and paradigms.
The difficulty of running QML on a webOS device, or Enyo apps on Android or iOS, is not technical. It's more about look and feel. One glance into Qt code (not QML, Qt proper) and you can see how painful it is to make a single app look native across platforms.
Here is where I think Enyo has potential. It should be possible to style Enyo for different platforms AND to easily include components that implement OS specific behaviors and paradigms.
The built in integration only allows you to open documents. Not pictures, videos, music, etc. It also does not allow you to upload new files.
Could you run Enyo apps on iPhone/Android as webapps? Because that would make it a very interesting proposition for something I'm working on right now.
Also- is it still accessible? Even googling 'WebOS Enyo', the first result is an Engadget article.
Also- is it still accessible? Even googling 'WebOS Enyo', the first result is an Engadget article.
I think it's more of a licensing issue. This is where they have to step up. Enyo needs an open license. I don't even know what it is right now, but I assume its not OK to use elsewhere, yet.
In it's current state it also wont run in Chome without --allow-file-access-from-files and --disable-web-security flags.
--allow-file-access-from-files to load local resources, I presume. --disable-web-security to allow cross-domain requests for the service bridge.
In it's current state it also wont run in Chome without --allow-file-access-from-files and --disable-web-security flags.
--allow-file-access-from-files to load local resources, I presume. --disable-web-security to allow cross-domain requests for the service bridge.
Fwiw, you only need those flags when running from file://. If you run from a server (http://, even just on localhost) it works out of the box.
Is webOS open source? Presumably not yet, or I would have seen it ported to more devices by now?
Its fans would be insane to pour effort into saving a platform which is controlled by some completely-disinterested corporate entity. Any platform with significant closed-source components requires caution and compromise, but signing on to webOS is like a death wish at this point unless you own the thing.
Instead, make sure that enthusiastic users can spread your apps by themselves — directly from phone to phone without any centralised system.
I hear they invite kids to Defcon now. Maybe one of the third graders can give a talk about the problems with this idea.
Its fans would be insane to pour effort into saving a platform which is controlled by some completely-disinterested corporate entity. Any platform with significant closed-source components requires caution and compromise, but signing on to webOS is like a death wish at this point unless you own the thing.
Instead, make sure that enthusiastic users can spread your apps by themselves — directly from phone to phone without any centralised system.
I hear they invite kids to Defcon now. Maybe one of the third graders can give a talk about the problems with this idea.
1. Sell the division formerly known as Palm (including webOS) to Facebook
2. Profit!
It would make a lot of sense for facebook to turn webos into the facebook mobile platform, making canvas apps first class citizens and tightly integrating facebook into the OS. The Palm acquisition would come with Palm's hardware engineers (HP hasn't fired them yet, right?), which would allow Faecbook to design their own hardware and outsource manufacturing to CM's.
Designing their own hardware would allow for a less powerful, less expensive device to have as good a user experience as the mid-range Android devices. Remember the PSP? It had a 200mhz MIPS cpu and 32mb of ram. The reason why it felt so powerful is that it was a known quantity to developers, so they could make assumptions that wouldn't be violated when a new device came out. That low price would allow the Facebook phone to play in the low end of the market, which is mostly currently populated by feature phones. And being able to run Facebook canvas apps natively would provide thousands of applications right out of the gate.
2. Profit!
It would make a lot of sense for facebook to turn webos into the facebook mobile platform, making canvas apps first class citizens and tightly integrating facebook into the OS. The Palm acquisition would come with Palm's hardware engineers (HP hasn't fired them yet, right?), which would allow Faecbook to design their own hardware and outsource manufacturing to CM's.
Designing their own hardware would allow for a less powerful, less expensive device to have as good a user experience as the mid-range Android devices. Remember the PSP? It had a 200mhz MIPS cpu and 32mb of ram. The reason why it felt so powerful is that it was a known quantity to developers, so they could make assumptions that wouldn't be violated when a new device came out. That low price would allow the Facebook phone to play in the low end of the market, which is mostly currently populated by feature phones. And being able to run Facebook canvas apps natively would provide thousands of applications right out of the gate.
> Ditch Enyo. No more messing around with your own frameworks and stuff. Writing them is fun, but web developers don’t want to learn yet another framework. The framework wars are over, and jQuery is the winner.
jQuery is not a framework...
I agree generally but I don't think he takes it far enough. If Enyo is just a js framework like Cappuccino or Backbone.js then the first thing they have to do is open source Enyo. I should be able to run an Enyo app on iOS or Android or Fennec or whatever.
Next they need to drop their packaging mechanism and embrace Open Web Apps[1].
Next they need to allow non-Enyo js apps to be packaged and installed as "native" apps.
Doing these things would put WebOS on footing with other competitor "web oses", specifically ChromeOS and Boot to Gecko. Except that WebOS would have beaten them to the punch on having a mobile UI perfect for multitasking web apps.
[1]https://apps.mozillalabs.com/
jQuery is not a framework...
I agree generally but I don't think he takes it far enough. If Enyo is just a js framework like Cappuccino or Backbone.js then the first thing they have to do is open source Enyo. I should be able to run an Enyo app on iOS or Android or Fennec or whatever.
Next they need to drop their packaging mechanism and embrace Open Web Apps[1].
Next they need to allow non-Enyo js apps to be packaged and installed as "native" apps.
Doing these things would put WebOS on footing with other competitor "web oses", specifically ChromeOS and Boot to Gecko. Except that WebOS would have beaten them to the punch on having a mobile UI perfect for multitasking web apps.
[1]https://apps.mozillalabs.com/
You can already use jQuery, and you can package non-Enyo apps to submit and install as "native" already. A good number of both webOS 1.x, 2.x, and 3.x apps do this because of the familiarity.
Not sure that the author has written an app with Enyo before coming up with a plan to save WebOS (Quick tutorial: https://developer.palm.com/content/resources/develop/extende...)
The SDK for Enyo doesn't force you to do anything. To build an app with Enyo, you need: 1) A WebKit browser for testing 2) A copy of Enyo's CSS and JS on your file system No required text editors or anything else.
Also in the SDK is a virtual machine that runs WebOS for testing or if you use Palm services that aren't supported in just WebKit. There are some simple command-line tools to package and install an Enyo app on the emulator or a device, and some tools to open a shell on a WebOS device or emulator
The SDK for Enyo doesn't force you to do anything. To build an app with Enyo, you need: 1) A WebKit browser for testing 2) A copy of Enyo's CSS and JS on your file system No required text editors or anything else.
Also in the SDK is a virtual machine that runs WebOS for testing or if you use Palm services that aren't supported in just WebKit. There are some simple command-line tools to package and install an Enyo app on the emulator or a device, and some tools to open a shell on a WebOS device or emulator
Most interesting bit in this article for me was the advice to woo web developers and not mobile app developers. Seems like a tactic that could win, assuming webOS lives on (unlikely). There are tons of web developers who didn't make the jump to mobile who would love the chance to experiment with mobile without completely throwing out the years of web knowledge they have earned.
This was the tactic all along in theory; the idea that web developers could immediately leverage their existing skills into the mobile space.
In reality, though, they never really focused on driving this point IMO, deferring to their own "webOS Meetups" and sending representatives to mobile conferences when they should have been sending their developer relations reps and evangelists to web development conferences such as An Event Apart.
In reality, though, they never really focused on driving this point IMO, deferring to their own "webOS Meetups" and sending representatives to mobile conferences when they should have been sending their developer relations reps and evangelists to web development conferences such as An Event Apart.
>The fates of Motorola and of Palm itself show that the days of US-centric mobile strategies are over.
One could argue that part of Nokia's demise was that they had no US market penetration. If they had, it would've given them enough time for MeeGo to be ready.
There was an article on TechCrunch about a year ago (I don't have the link) asking why European startups were having such a difficult time being successful in other countries. The argument by the writer is that Europe was too broken up; there were differing laws from country to country and that it took too long to become dominant. The US is an easy market to target because it has a large population that mostly speaks one language. Today it still controls 25% of the smartphone market. I would expect a country like China to become a leader (over Europe) as well for the same reasons.
WebOS could still become successful but only if it's open sourced. This may or may not be in HP's best interests though. It's quite possible that Samsung would choose it over Bada and HTC over Brew.
One could argue that part of Nokia's demise was that they had no US market penetration. If they had, it would've given them enough time for MeeGo to be ready.
There was an article on TechCrunch about a year ago (I don't have the link) asking why European startups were having such a difficult time being successful in other countries. The argument by the writer is that Europe was too broken up; there were differing laws from country to country and that it took too long to become dominant. The US is an easy market to target because it has a large population that mostly speaks one language. Today it still controls 25% of the smartphone market. I would expect a country like China to become a leader (over Europe) as well for the same reasons.
WebOS could still become successful but only if it's open sourced. This may or may not be in HP's best interests though. It's quite possible that Samsung would choose it over Bada and HTC over Brew.
> I’ve been thinking a lot about the future of webOS, and have decided it does have one, maybe even a glorious one, provided the new owner or licensee reaches out to web developers, as Palm should have done back in 2009.
I think the most likely new owner if HP sells will be Google, Microsoft, or Apple. They will be buying for the patents and will have no interest in doing anything with WebOS.
HP could try to sell WebOS separate from the patent portfolio, but no sane entity would buy unless the sale included some kind of permanent license to any of the Palm patents that WebOS implements. Such a license would would lower the market value of the patent portfolio, so I don't see much chance of HP doing that.
If Google, Apple, or Microsoft fail to buy the Palm IP, then maybe there is a chance. Perhaps one of the non-Motorola Android phone makers might be interested in diversifying--they can't be too happy with Google buying Motorola's phone business. Samsung would be a good candidate.
I think the most likely new owner if HP sells will be Google, Microsoft, or Apple. They will be buying for the patents and will have no interest in doing anything with WebOS.
HP could try to sell WebOS separate from the patent portfolio, but no sane entity would buy unless the sale included some kind of permanent license to any of the Palm patents that WebOS implements. Such a license would would lower the market value of the patent portfolio, so I don't see much chance of HP doing that.
If Google, Apple, or Microsoft fail to buy the Palm IP, then maybe there is a chance. Perhaps one of the non-Motorola Android phone makers might be interested in diversifying--they can't be too happy with Google buying Motorola's phone business. Samsung would be a good candidate.
1. The webOS app format needs to change away from the custom webOS framework (with its own directory layout etc.) to a single index.html (that can link to wherever and include any resources via HTML 5 app cache).
2. First class support for IndexedDB and quota management, with performance on mobile at least an order of magnitude faster than desktop Chrome or Firefox. It may sound unthinkable but the Chrome and Firefox IDB implementations are at present rather buggy and slow.
3. Excellent Javascript interfaces to device hardware.
4. Bundler to enable any app targeting webOS device-specific apis to run natively on iPhone or Android.
5. Sell the printer division, it's distracted HP from making a technical contribution for too long already.
2. First class support for IndexedDB and quota management, with performance on mobile at least an order of magnitude faster than desktop Chrome or Firefox. It may sound unthinkable but the Chrome and Firefox IDB implementations are at present rather buggy and slow.
3. Excellent Javascript interfaces to device hardware.
4. Bundler to enable any app targeting webOS device-specific apis to run natively on iPhone or Android.
5. Sell the printer division, it's distracted HP from making a technical contribution for too long already.
Most of your points are already covered.
1. You could do this from day one. You didn't have to include Mojo or any other device specific framework. index.html was enough (you would also need appinfo.json for metadata and packaging.) With Enyo, even if you use the framework, there is no longer a need for any specific directory structure.
2. They have CouchDB (really not sure, it is a JSON object store though) running and accessible to all apps via a service bridge. This db is also backed up to the cloud for when user restores or changes devices.
3. Same service bridge. Which is nothing more than an AJAX call to a specific url.
4. They already run in Chrome with Enyo. With Enyo, I think this is actually possible.
5. Or keep it as a huge source of revenue. Nobody but HP's marketing dept wants webOS on printers though, I'll give you that. Think John Deere acquiring Ferrari and putting their engines into lawn mowers, because "it's the logical thing to do."
I'll add 6.
6. You can write your own Node.js services that are accessible via the same service bridge mechanism.
webOS is the mobile OS we should be cheering for to survive. It is slightly ahead of the curve and is about to be killed off. The news about Mozila WebAPI are an indicator.
1. You could do this from day one. You didn't have to include Mojo or any other device specific framework. index.html was enough (you would also need appinfo.json for metadata and packaging.) With Enyo, even if you use the framework, there is no longer a need for any specific directory structure.
2. They have CouchDB (really not sure, it is a JSON object store though) running and accessible to all apps via a service bridge. This db is also backed up to the cloud for when user restores or changes devices.
3. Same service bridge. Which is nothing more than an AJAX call to a specific url.
4. They already run in Chrome with Enyo. With Enyo, I think this is actually possible.
5. Or keep it as a huge source of revenue. Nobody but HP's marketing dept wants webOS on printers though, I'll give you that. Think John Deere acquiring Ferrari and putting their engines into lawn mowers, because "it's the logical thing to do."
I'll add 6.
6. You can write your own Node.js services that are accessible via the same service bridge mechanism.
webOS is the mobile OS we should be cheering for to survive. It is slightly ahead of the curve and is about to be killed off. The news about Mozila WebAPI are an indicator.
If Enyo is open-sourced we can decouple the webos device APIs from the framework so you can plug-in the Mozilla WebAPIs or Phonegap APIs if so desired.
Enyo already has hooks to run on PhoneGap.
I have a lot of Enyo test apps that are just an appinfo.json file, an index.html file (with the JS source in an inline script tag), and an icon file.
The webOS app environment has a couple of quirks that are easily handled by a couple of calls (tell the system that the UI is ready for display). There's also no native scroller for apps, so they need to implement something like iScroll in order to show more content than fits in the on-screen card. Outside of that, HTML + JS just works.
The webOS app environment has a couple of quirks that are easily handled by a couple of calls (tell the system that the UI is ready for display). There's also no native scroller for apps, so they need to implement something like iScroll in order to show more content than fits in the on-screen card. Outside of that, HTML + JS just works.
I'm not sure if HP is trying to sell Palm/their mobile division or not, but they should. They've just pushed out all of their WebOS devices into the market (at a big loss), so now people are actually using their OS, which makes it much more valuable to a prospective buyer than it was a week ago. There was a huge frenzy over Touch Pads, sure it's only because it was cheap, but at least people are using it now. I don't think HP should continue making them, but it wouldn't be such a bad buy for another company.
The organizational and cultural changes needed to implement this list of steps are enormous. Massive. I really don't see how they could every become reality while managed by a company like HP.
Changing software is easy. Changing a business is damn hard, doing it overnight straight out impossible.
I doubt the OP realises what he's asking.
Changing software is easy. Changing a business is damn hard, doing it overnight straight out impossible.
I doubt the OP realises what he's asking.
From TFA:
> I … have decided [webOS] does have [a future], maybe even a glorious one, provided the ɴᴇᴡ ᴏᴡɴᴇʀ ᴏʀ ʟɪᴄᴇɴsᴇᴇ reaches out to web developers…
> I … have decided [webOS] does have [a future], maybe even a glorious one, provided the ɴᴇᴡ ᴏᴡɴᴇʀ ᴏʀ ʟɪᴄᴇɴsᴇᴇ reaches out to web developers…
Won't work. In order for WebOS to avoid being the next AmigaDOS it needs to displace either iOS or Android. It's not a question of quality. It's a question of how much the market will tolerate another proprietary player.
What do you mean.. Workbench 4.0 is coming out any day now! ;) Seriously, reading the quirksmode article thoughts of AmigaDOS kept running through my mind...
I didn't know much about writing apps on webOS so I found this recent video on using JavaScript in Enyo and Node.js
http://vimeo.com/25762560
http://vimeo.com/25762560
I don't have much hope for webOS, even if it becomes open sourced it will end up as a toy OS without major financial backing and support.
re 11) In my experience, Palm hands out WebOS devices like candy; I know very few people who have a WebOS device, in fact, who didn't get one free from Palm because they had expressed a vague interest in developing for the platform.
[deleted]
I have to disagree with him about Enyo. Writing Enyo, and writing jQuery, I have to say writing Enyo is orders of magnitude more pleasant. Maybe they should also have jQuery in there, and several other libraries just to give developers familiar tools. But Enyo, beats jQuery no doubt when it comes to writing applications.
If HP would allow Enyo outside of webOS, I'm sure many many web developers would agree.
Also, I don't see what he means when he says don't force SDKs. I develop the exact same way he describes no problem.
And his suggestion to distribute using bluetooth... OK?
For #10, does Android even have a method of first accepting apps via bluetooth from non-Android phones and then opening the browser to those apps? By the way, Enyo apps run just fine in the Android browser, but he is eager to throw Enyo out anyway.
For #11, dude must not have noticed there is a firesale going on, not only the Touchpad, but also the phones.
He makes some good points, but it just seems to me that he didn't really think things through before writing that post.
If HP would allow Enyo outside of webOS, I'm sure many many web developers would agree.
Also, I don't see what he means when he says don't force SDKs. I develop the exact same way he describes no problem.
And his suggestion to distribute using bluetooth... OK?
For #10, does Android even have a method of first accepting apps via bluetooth from non-Android phones and then opening the browser to those apps? By the way, Enyo apps run just fine in the Android browser, but he is eager to throw Enyo out anyway.
For #11, dude must not have noticed there is a firesale going on, not only the Touchpad, but also the phones.
He makes some good points, but it just seems to me that he didn't really think things through before writing that post.
I'm not sure the people calling for "ditch Enyo" have any idea just how much fun it can be to use or how easy it is to build apps that easily change the appearance based on the size of the device it's on. Think fragments in Android, but with HTML/JS. It's quite neat.
1. Somebody should wake up and take RIM's lunch, not Apple's. Build a thin candy bar webOS device with an excellent keyboard and a decently sized screen. Palm went all in on the Pre form factor instead of Pixi, which I maintain was their biggest mistake to date.
2. Deliver on the webOS promise to developers. Mojo wasn't it. Surprisingly, Enyo is! My hat is off to the Enyo guys.
"Just use jQuery" is the new "just use RegEx." I loooove jQuery, but it doesn't really help you in managing a huge application. There is a reason why people use backbone.js, knockout.js, javascriptmvc, and the like, in addition to jQuery.
Enyo lets you assemble your apps from components. I'd be the first to say that my bs meter went live when I heard that. 99% of the time, "its modular" is an empty promise. However, for version one, Enyo is bang on. I'll be honest though, the thought "another fucking framework..." _has_ crossed my mind in frustration.
Yet, I am staring at my webOS mobile app running in Chrome right now -- inspector working and all -- and it's like staring into the future. _This_ is the way mobile apps are meant to be built. _This_ was the promise.
This brings me back to the article re: packaging. I package this enyo app in a second's time and it's up running the same code on the device or emulator, and it all feels native to the OS. As long as the code is the same, I don't care if you package it in a cup cake.
Enyo is actually a very good idea. All they have to do is give it an appropriate, free to use without restriction, license.