Seems pretty solid! I tested on iPhone 4, which I use for my subjective performance testing when comparing libraries.
Transitions worked nicely, both meme and YouTube video thumbnail views were smooth. Compared to a possible native implementation the image search didn't work that smoothly during image loading, but it was still usable after all images were loaded. Also the list view for long lists with presumably dynamic loading (UITableView style) wasn't that smooth during scrolling.
If you're a Java aficionado GWT has a similar stack of widgets mGWT http://mobilegwt.appspot.com/showcase/ which actually are tuned to produce optimal repaints/scrolls in WebKit/Chrome with minimal DOMs. Combine with gwt-phonegap to produce native deployable apps for AppStore and Play.
My personal take is that you should always develop for the platform you are targeting.
It is not so much about weather the UI is drawn so that it looks native and it is not about performance (although important). It is more about what you can and cannot do natively. For example, in iOS/Mac certain things are not easy to do because the UI components that you are extending are not designed to work in they way you want them to work. This may look like a limitation but I see it as an enabler because it forces applications to have more or less the same behaviour. This is what makes AppKit/Cocoa etc. a better platform for development on iOS/Mac.
I am just amazed at all of the new cross platform toolkits and frameworks popping up nowadays. Seems to rival the number of new javascript libraries. The attempt to bring cross platform development to mobile is reaching a fever pitch. So many approaches, but there are still compromises or shortcomings from them all. One thing that I've noticed is that most of the newer frameworks are based on web tech and stacks. Which I guess is a good thing, or maybe not.
If someone built one of these mobile webapp frameworks using famo.us, but exposed it to the developer as something much less alien vs actual famo.us... I would be so happy.
I am trying to learn Javascript, coming from a Perl / Python / RDBMS background.
What a mess the JS landscape is. There are so many frameworks, and no clear reason to choose one over the other. Angular has a reputation as being one of the better ones, but it seems overly complex, the documentation is terrible, and the learning curve is steep. And its still one of the better of the ones that I have tried.
chocolatechip-ui is a nightmare, at least for me. It has tons of micro-issues. Mostly just awkward interaction / behavior and missing key basic features.
Scrolling is a big issue here. I haven't looked into the source carefully but I saw the same behavior of wrong thing getting scrolled. My experience tells me that it's because they use div's scroll or multiple iframes. HTML in mobile browser is terrible at handling multiple scroller because it doesn't know where people touch or intend to scroll. Only famo.us seems to fix this problem by re-writing the whole scrolling feature. However, they screwed it up on some other parts (lolz..) which we heard things might improve.
It's actually just using the browsers scrolling mechanism. Android 4+, iOS 5+ ship with touch-scrolling that you can enable on an element so it's as close to native scrolling as you can get.
Right. I have tried that with jQuery Mobile and the behavior was similar to what I saw in this framework. Basically for mobile, it's nearly impossible to have main page scrolling and swipe right to pop out the left menu which also has its own scrolling.
* Fixed the scrolling issue. Ios safari doesn't let you disable the bounce so there is a workaround now.
* Ios back gesture works fine... Except in mobile safari, again because there is no way to disable apples back gesture. This would work best in phonegap or Kik where you can control these kinds of things
It seems this is really good for single page (WebView) embedded in a native app. I am curious whether the wrong scrolls will happen if turn off the scroll functionality of the WebView on iOS or Android.
I would be a bigger fan if there were some included phonegap utilities & tutorials.
Famo.us is making the same mistake for some reason. Aggressively targeting mobile, with half of the toolchain missing to actually shipping mobile apps.
Not that I can blame the OP, who is likely not a SF startup with millions in funding.
Like the others said, this is written by Kik Interactive (http://kik.com/) which is well-funded.
The idea is that Kik's browser has the PhoneGap-like utilities that you described built-in, while this is a library for building the UI of an application. http://dev.kik.com/
It's actually a Canadian startup with millions in funding, but this is not their product. It's the Kik messenger, which has a built-in browser. They provide this library to make making apps for their messenger easier.
The live demo doesn't work with a mouse on desktop Chrome on a Microsoft 8.1 Surface as it thinks it's a touch screen only. I'm experiencing more and more issues with this, one a large UK retailer's e-commerce web site hit this issue and the Ghost blogging platform.
The interesting thing is, Apple originally intended that this should be the goto way to get user generated applications on the iPhone.
But then, the jailbreak scene came up and somehow Apple changed their stance by creating the app store and thus the possibility to control what kind of native applications will run on the devices.
Of course this way has the advantage of not needing a paid developer account or need to have the app approved by Apple but then again, such a webapp is harder to monetize if that's what you are after than to simply write a native app and sell it in the app store.
Longer title tag, please. I just bookmarked the site and found "App.js" in my database with no other context :-( Should help with search bots, too, IIRC~
Transitions worked nicely, both meme and YouTube video thumbnail views were smooth. Compared to a possible native implementation the image search didn't work that smoothly during image loading, but it was still usable after all images were loaded. Also the list view for long lists with presumably dynamic loading (UITableView style) wasn't that smooth during scrolling.
All in all, kudos for the good work!