This is a good first shot and ported from webOS to Android in just a few days - mostly dealing with the PhoneGap and android packaging learning curve, and porting native services to PhoneGap plugins.
Its written to the Enyo 1.0 framework that only really targeted the webOS implementation of webkit, so there are some performance issue with sliding and scrolling under Android that didnt appear on the TouchPad.
The scrollers and sliders are glitchy. I think it may be some interaction between the touch events and scrolling specific to the Android webkit implementation when hosted in an app rather than the native browser.
If you switch to "paged" mode rather than scrolling the article the transitions are generally fast when you tap or swipe - atleast with testing on a Nexus S and a TouchPad both running ICS.
I dont think its purely rendering speed, but some odd DOM interactions.
You don't have to use the .write method. The way enyo 1.0 works and the way that's still supported is to use .renderInto(domNode) to replace the innerHtml of a node with the new content. This is especially useful from the console, since writes don't work there.
I imagine it makes the API easier for non-JS developers. Considering its origins as a purely client-side library it does makes sense, as there would be no need to worry about moving script tags down the page to speed up execution.
Technically, you could probably replace the document.write with something like:
var scripts = document.getElementsByTagName('script');
var current = scripts[scripts.length - 1];
var temp = document.createElementNode('div');
temp.innerHTML = this.generateHTML();
current.parentNode.insertBefore(temp, current);
I wrote a script that hijacks document.write calls a little while back (https://github.com/joshduck/Injector.js) which lets you inject arbitrary HTML into your document and then execute inline scripts (including document.write) at a later time.
Enyo 2 [...] doesn’t yet include a UI package, but features a tight, cross-platform core that will serve as the foundation for future Enyo development, supporting libraries and add-ons of all kinds.
Honestly, I'd wait until they have a UI framework and see if it compares to Bootstrap. The core certainly enables more organized, JS-focused code. Probably good for large web apps.
This is to javascript as rails is to ruby. (that might not be the best analogy, but better than bootstrap) While there is a UI portion, the reason it does not exist right now is because it's not meant to be solely a UI framework, such as Bootstrap. I don't think comparing it to bootstrap is, by any stretch of the imagination, reasonable. In fact, there shouldn't be any reason why you couldn't use Enyo in conjunction with bootstrap.
You can certainly use the CSS parts of Bootstrap with Enyo 2.0... I've been playing with that myself. Once we have new widgets, we're hoping to avoid the need to do a lot of CSS work to make great looking apps.
It is the very next thing we are working on, and we hope to have it out in about a month. We’ll update you with regular builds as work progresses, now that Enyo is an open source project.
Mainly "something" instead of nothing at all. HP was unable to find a suitor willing to buy or license webOS from them to recoup some of the massive cost of purchasing Palm. As a webOS user (TouchPad and a FrakenPre2 on Sprint) I can't wait for all of webOS to be open-sourced. At that point there will be the possibility of porting to current hardware by the webos-internals team.
Making it open source could potentially lead to future revenue similar to the way other companies that heavily leverage open source. Red Hat and Google come to mind. They QA new features into the main build and offer service and consulting for Enyo/webOS. Maybe the mere fact of open sourcing the code will generate more interest vs. when it was closed.
Backbone and Ember (at least for some extent) are MVC frameworks that provide you with classes to extend to have certain functionality (events, validations, iterations over collections, bindings etc.).
Enyo seems to be more declarative framework for defining your UI components.
In fact, you most probably could combine two together (esp. taking the 13KB weight in account, makes it a really-lightweight thingie).
Such a web based interactive was a big reason for why I found it so easy to get up and running with Mongo (http://try.mongodb.org/).