Scrollability

http://joehewitt.github.com/scrollability/

by mynameisraj • 15 years ago

118 38 15 years ago

joehewitt.github.com

jordanekay3• 15 years ago

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.

Web apps are hacks.

olivercameron• 15 years ago

That is incredibly short sighted. The web is universal, iOS is not.

jordanekay3• 15 years ago

Is it not?

jordanekay3• 15 years ago

Please, tell me where to find these mobile web apps that are superior to their native iOS counterparts.

benreesman3• 15 years ago

while i agree that there are ways in which native user interface controls are currently more compelling than their web alternatives, shouldn't we all be diligent in hoping for and working towards the end of that situation? it might not be as impossible as it once seemed, they're doing angry birds in a browser now!

either way i can't imagine that an iOS monoculture in high-end mobile applications really serves anyone but apple in the long run. i think there's a general consensus that it didn't work out that well with windows, and there's arguably a lot more at stake this time.

cfinke• 15 years ago

Joe has been live-tweeting his development of this library today: http://twitter.com/#!/joehewitt

11:55 AM: "I feel suddenly motivated to write a tiny JS library that does scrolling right, or at least as close as possible."

10:20 PM: "I think we're ready to demo."

Now that's gumption.

aheilbut• 15 years ago

Doesn't seem to work on a desktop, in Chrome.

cleverjake2• 15 years ago

its not supposed to. its for mobile devices that lack the ability to scroll inner divs

MatthewPhillips• 15 years ago

You can scroll inner divs on iOS, with 2 fingers.

chubs• 15 years ago

Sounds like a good thing. iScroll is another option too, however if this is simple and small, it could be a winner.

rudiger• 15 years ago

Link: http://cubiq.org/iscroll-4

benreesman3• 15 years ago

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.

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.

joehewitt2• 15 years ago

Libraries like these should not be necessary, but since Apple has not implemented proper scrolling of elements and iframes, we're left to do it ourselves. Perhaps iOS 5 (just two weeks until wwdc!) will solve the problem and make this project obsolete (I hope so).

Even if they do, libraries like these may still be necessary for more advanced scrolling mechanisms like those that snap to page boundaries or involve scrolling/zooming hybrids (like photo viewers common to many apps).

benreesman3• 15 years ago

fantastic work and thanks for the quick reply. i'm eager to show this to some of the guys i work with as they're working on similar stuff. http://www.npr.org/webapp loaded on an ipad 2 is pretty slick, particularly in terms of multi-finger scrolling.

i'm sure i speak for a lot of people when i say thanks for working to advance the prospect of truly first-class web applications on mobile. these are exciting times!

smickie• 15 years ago

Yeah. That is really smooth and fast on the iPhone 3G. It's a great job.

This is what overflow-scrollable areas on webpages should have been in iOS Safari. At the moment you have to mash two fingers into the screen and slowly drag it around; real clunky.

Fingers crossed (badum-tish) for an update next month.

lloeki• 15 years ago

I must admit I'm impressed. Barring a very slight jerkiness at some random times it actually feels native: fluid, fast, and the "physics" is very, very close. In comparison iScroll 4 is better on general smoothness but feels strangely alien to iOS (notably the inertia bounce at list ends).

With the swarm of crappy alternatives - barely mimicking the native behaviour - I saw before I was giving up on the hope that something like this could even remotely exist.

ericflo2• 15 years ago

Looks promising! It doesn't work properly yet on the Droid Incredible, but I'm sure he'll work out the kinks.

nrbafna• 15 years ago

it is supposed to be for iOS.

ericflo2• 15 years ago

He updated it to say that after I made my comment: https://github.com/joehewitt/scrollability/commit/a7eac85ad3...

koushd• 15 years ago

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?

PS, yes, I'm that Koush of Android. I'm a little opinionated when it comes to mobile development. :)

joehewitt2• 15 years ago

I assume you're testing on an Android device then... I don't have one to test (but I will soon), so I'm not surprised it doesn't perform well there.

Anyway, the current code is trying to replicate the feel of iOS scrolling. An Android implementation should try to replicate the feel of Android scrolling, which is much different. I will get around to it...

mnutt• 15 years ago

Apple has a patent on momentum-based touch scrolling that looks like it covers this:

http://reviews.cnet.com/8301-19512_7-20015237-233.html

mckoss• 15 years ago

Given that momentum based mouse scrolling existed in the prior art, I doubt that the addition of touch would pass the non-obviousness test in court.

voidfiles• 15 years ago

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.

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.

newhouseb• 15 years ago

I agree, as a user of iScroll I'm puzzled as to why he didn't just fork iScroll. He mentioned that he didn't like how it "felt" on twitter but I would imagine the formulas used to calculate momentum are, relatively speaking, a _very small_ part of the iScroll code.

As an aside, I think that github might be able to help a lot with encouraging collaboration in light of so many duplicate projects by working on better ways to discover projects (either by better search indexing, better SEO or otherwise). And as a disclaimer: I think github is one of the most innovative companies today, so this is by no means an attempt to point fingers, rather an observation that they have a huge opportunity to really change how OSS works.

nupark2• 15 years ago

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.

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.

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.

JoelSutherland• 15 years ago

Mobile processing power is doubling annually, GPU speed at an even faster rate. Hardware acceleration for CSS transforms is only starting to get good. (No negative values on cubic-bezier timing functions!)

No, web components haven't met native ones yet, but they only need to achieve 60 fps. They will get there, it's a safe bet.

lurker19• 15 years ago

By the time HTML is as good as native is, native will have moved on to something else, like holograms. Look what happened on the desktop: after 10 years webtech finally became usable as a UI, just in time for everyone to jump to mobile and set performance back another 10 years.

lukifer2• 15 years ago

Apple actually fell down on this one; it should be possible to create natively scrolling divs without resorting to JS trickery. (In fairness, Android only acquired this feature very recently.)

> 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.

While there is some truth to this, it doesn't tell the whole story. Most developers don't have the time or desire to maintain multiple native codebases, and so using web tools improves user experience by allowing the app to exist on their platform at all. Also, sometimes these things come in handy on actual websites (personally, I consider "Click here to download our mobile app!" terrible UX).

btrask• 15 years ago

Given Apple's App Store restrictions, the choice is often between cloned UI in web apps or no iOS support at all.

jpeterson• 15 years ago

Wow, I can't believe this is the top comment on HN. It's the kind of shortsighted sentiment that you look back on two years later and have a good chuckle.

mbrubeck• 15 years ago

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: https://github.com/cubiq/iscroll

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.

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 break scrollable elements that work fine without the library.

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.

(disclosure: I am a mobile Firefox developer)

MrNibbles• 15 years ago

Its easy to detect these features, ideally one would only load this lib if the features are supported.

The -webkit-transform: translate3d(0,x,y) (3D, not 2D transforms) property forces the element to be hardware accelerated under mobile safari, without this, the redraw would be around 10 times slower. This is the whole point of the library (hacking around a known issue in mobile safari)

Besides, he states that the code requires iOS. It is not a mistake to include vendor specific code in this way when targeting a specific platform for optimisation.

Scrollability

Related Stories