Joe has been live-tweeting his development of this library today: <a href="http://twitter.com/#!/joehewitt" rel="nofollow">http://twitter.com/#!/joehewitt</a><p>11:55 AM: "I feel suddenly motivated to write a tiny JS library that does scrolling right, or at least as close as possible."<p>10:20 PM: "I think we're ready to demo."<p>Now that's gumption.
While improving the web application experience is commendable, there is still simply no replacement for the native components. Broadly speaking, investment in mobile webapps largely seems to be about improving the entrenched web developer's experience, rather than the actual user's experience.<p>Insofar as Apple continues to invest in UI R&D, a clone of their UI's look and feel will always lack fidelity to the original, sit in the uncanny valley when approached by users, and require ongoing maintenance to track upstream changes as best as possible.<p>Additionally, fluid scrolling on iOS devices is resource intensive and requires a very careful attention to performance details; I've yet to see HTML5 UIs scroll as smoothly as a tuned native UI.
I don't want to pick too much on this project since it's in very early development, but this repeats a mistake that's also found in more mature libraries like iscroll.js: <a href="https://github.com/cubiq/iscroll" rel="nofollow">https://github.com/cubiq/iscroll</a><p>The problem is that it uses CSS that works only in WebKit, but does not fall back gracefully in any other browser. It depends on CSS3 2D Transforms. Because the 2D Transforms spec is not yet a Candidate Recommendation, browser vendors currently implement it with vendor prefixes in case the spec changes before it's finalized. 2D Transforms are implemented in recent versions of IE (-ms-transform), Opera (-o-transform), Gecko (-moz-transform), and WebKit (-webkit-transform). However, the library uses only -webkit-transform.<p>That wouldn't be so bad, except that it does this in a way that potentially breaks the page in other browsers. For example, mobile Firefox supports overflow scrolling without any need for libraries. In the latest nightly builds of mobile Firefox 6 (which support touch events), adding iscroll.js to your page will actually <i>break</i> scrollable elements that work fine without the library.<p>The solution is two-fold: (1) If you are using vendor-prefixed APIs you can easily support more implementations, and (2) do feature detection to fail gracefully on implementations that you don't support. And yes, I plan to submit patches to these projects to address these problems.<p>(disclosure: I am a mobile Firefox developer)
Previous coments about re inventing the wheel are correct, but not because this has been done natively, but because this has been done before, and in a multiple platform way.<p>The best thing he could do is work with others. Not go all lone wolf on the very people he said he wanted to help.
this is awesome! it's really very close to a native experience (on iphone 4 at least). my hat's off to mr hewitt. for a comparable experience check out gmail in mobile safari, it's also very convincing.<p>apologizing for my ignorance, does anyone know for sure why these libraries are necessary? it seems like it wouldn't be hard to offer a standard way (or even a meta tag, i appreciate that pinch zooming is a reasonable default) to get smooth accelerated scrolling of fixed and/or overflow:auto containers.
Apple has a patent on momentum-based touch scrolling that looks like it covers this:<p><a href="http://reviews.cnet.com/8301-19512_7-20015237-233.html" rel="nofollow">http://reviews.cnet.com/8301-19512_7-20015237-233.html</a>
Joe has done some amazing development in his time. But, honestly, that page was a real eye sore on my phone. It ran like crap.
If such a notable engineer can only develop an app of lacking caliber with the html/javascript, what does that say for web development on mobile?<p>PS, yes, I'm that Koush of Android. I'm a little opinionated when it comes to mobile development. :)
This is some impressive work, but at the end of the day it's just another unecessary attempt to reinvent the wheel, a wheel that will always lag behind the original. The time he spent reverse engineering UITableView could have been spent doing useful things with actual UITableViews.<p>Web apps are hacks.