4 ms·
I've published a Dropbox client for webOS written in Mojo, the previous webOS framework, and have started an Enyo rewrite for the Touchpad. I have an opinion fr
by pacemkr 15y ago
I've published a Dropbox client for webOS written in Mojo, the previous webOS framework, and have started an Enyo rewrite for the Touchpad. I have an opinion from both a consumer side and the developer side.
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.
- bergie 15y agoDoesn'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/qdeclarativeintroduction.html 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-reintroducing-the-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
- pacemkr 15y agoThe built in integration only allows you to open documents. Not pictures, videos, music, etc. It also does not allow you to upload new files.
- pacemkr 15y agoI 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.
- untog 15y agoCould 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.
- pacemkr 15y agoI 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.
- elarquitecto 15y agoFwiw, you only need those flags when running from file://. If you run from a server (http:// http://, even just on localhost) it works out of the box.