First, the goal posts have moved. With iOS7 and Jelly Bean, the expectations of people building apps have become an impossibly high bar for the traditional web. If we had built a simple app framework, then we'd be competing with native apps circa 2009. I think that hyperlinks alone would have helped us win the battle against native apps, but there would always be lots of use cases we wouldn't be able to touch.

Second, focusing on trying to do everything you can do with iOS and Android provided us with much more challenging performance constraints. This extremely high bar has resulted in a design where performance is considered in everything we do. If we didn't squeeze out as much performance as possible, it would leave a much smaller margin for the developers using Famo.us. Looking at everyone who has built stuff with Famo.us, many people have been able to make demos and apps that compete easily with any mobile app built by very senior developers.

Furthermore, there is one major yet unrealized optimization that all the browser makers are aware of that once implemented will completely eliminate 90% of the overhead. Basically, HTML, being XML, inherits XML's poor type system of only strings and children. When interfaces to the DOM were designed they adopted XML's weak type system for the getters and setters. This means that when Famo.us sets a CSS 3D Matrix transform, it needs to take an array of floats, stringify it and then set the style property on a DOM element. Once set, the browser then needs to take this string and parse it back into an array of floats. This marshaling of an array of floats to a string and back again is horrible for performance. This is why Famo.us is currently limited to moving 200-400 surfaces simultaneously on a desktop browser. When this bottleneck is eliminated, everything changes. Famo.us which is relatively fast compared to all techniques out there will become several orders of magnitude faster.

What I don't get is all the hate out there. Yes, we've misstepped in places. Is what we've built thus far perfect? No, not yet. We're competing with operating systems that have years of head start on the web. If we want something that can compete with native, then we need to start building something that is as ambitious in scope with what already exists in native. What other option out there even comes close to giving us a path to combining an experience that is comparable to native (for the average web user, not us neckbeards), supports semantic web content (at the Surface level), has a faster development workflow for iterating on designs and supports the most important feature of the web: hyperlinks?

Lastly, I think the importance of native scrolling and other native-like features are actually overblown. I've been on the web long enough to remember when people used to say that webmail would never compete with desktop mail and that Excel would never compete with something like Google Spreadsheets. Even ExtJS was born out of the need to have a javascript framework that aped the Microsoft Windows look and feel.

What is so special about native scrolling that puts it on a pedestal where it cannot be disrupted? If we define "quality" as "fitness for use", does our scroller yet meet the definition of a quality scroller for the desktop? No, we've got a ways to go. However for mobile devices, I would argue that Famo.us is definitely already there. I encourage everyone to take the demos we have, boot them up on a local server on your machine and view them on your phone or tablet. Those are definitely fit for use now and give you access to a market that is already larger than any native platform and can be opened via a link (many greenfield opportunities not available in native land).

There will come a time where native scroller is going to be shown to be the false god that it is. All you really need is to reach parity with respect to fitness for use and you're at a tipping point where that's no longer a hard and fast requirement. From there, things eventually shift far enough that it's no longer a consideration.

Looking at it on Chrome in Galaxy Note 3 with KitKat, no, you aren't "already there". Scrolling is painfully erratic.

And if you really want to be "mobile first", which makes sense, it would probably be a good idea to have content which (a) scaled to the width of the device, or (b) failing to scale to device width, at least provided horizontal scrolling. As it is, even in landscape your "Famo.us University" content extends beyond both sides of the viewport.

> There will come a time where native scroller is going to be shown to be the false god that it is.

Sure, someone may one day build something that makes not using the native scroller sensible. But Famo.us hasn't, as yet, done that.

The problem isn't with that device isn't Famo.us, and IIRC it's not the hardware either, it's the implementation of the APIs we rely on in the browser.

Many people replace their mobile phones every 1-3 years. Now that smartphones are becoming feature phones and all these phones have the most recent versions of Android, it's only a matter of time.

Since when is KitKat (4.4) not "above" Ice Cream Sandwich (4.0)?

> Also, are you using the stock Android browser or did you install Chrome?

Well, I said Chrome, but the problems (at least, the ones listed in my previous post) are identical in the stock browser.

> Many people replace their mobile phones every 1-3 years.

Well, yeah, I just replaced my long-in-the-tooth iPhone 4 with a still-top-of-the-line Galaxy Note 3 (though the GNote 4 will be out fairly soon.) That's the phone we're talking about here.

> Now that smartphones are becoming feature phones and all these phones have the most recent versions of Android, it's only a matter of time.

But KitKat is the most recent version of Android, and you just said you don't support it.

Yes, we support KitKat. We'll investigate the experience on your device.

Looks like KitKat has been out for 6 months. Just a heads up, the best Android devices are running KitKat, like the S4 & S5. I can confirm, the Famo.us scrolling & animations have issues on the S4.

That being said, your framework is amazing on iOS, and feels like a native app. I'm sure your team will have no problem with KitKat, if time is dedicated to it.

FWIW, I made this versioning mistake because I'm one of the two people in the company who is the least familiar with Android versioning because I work on backend systems and tooling that we'll be releasing later this year. 90% of my time is spent in the terminal.

Anyways, homepage clearly needs some a lot of love. In the meantime, do you mind trying the following instructions in this comment, https://news.ycombinator.com/item?id=7771330 , on your Android device to see how the demos perform?

Ordinary websites that don't do anything fancy but just let the browser handle the scrolling work beautifully in all three browsers, with smooth, natural feeling scrolling and easing.

Hmm... Just tried it in Chrome in Windows. I can't scroll at all! Tried a bunch of things but nothing would scroll. Dragging the scroll bar just turns text blue. Cursor keys and PgUp/PgDn don't do anything.

I even tried the middle TrackPoint button figuring that would fool it, but no, they disabled that too.

With that in mind, what would you have to see to be convinced that native scrolling is not as important as many people claim it is? Also, what do you think it would take to convince many of those that hold native scroll in high regard that maybe it's not as deserving of the pedestal upon which it stands?

Dead serious here, besides meeting the definition of "fitness for use" by the common app user, it's as important to meet the definition of "fitness for use" by those that will be tasked with implementing an app that is built upon our framework and by extension uses our scrollview.

Something that actually is provides basic scrolling function effectively that replaces native scrolling -- as opposed to something that stutters badly on current, top-of-the-line mobile platforms, performs poorly (and, with many expected interaction methods, doesn't work at all) on desktop, etc.

If you are going to convince people to buy into your reinvention of the wheel, it better at least roll properly.

Native scrolling isn't actually important -- what is important is access to content that meets expectations either because it works as expected from past experiences or because there are clear affordances that make the transition easy. Native scrolling is an easy way to achieve that because users of a platform are almost certainly familiar with the platforms scrolling behavior, and every major platform has native scrolling that works acceptably in virtually all reasonable circumstances.

If I have scrolling content with no scrollbar, that's bad.

If I have a scrollbar I can't interact with as expected and nothing that clues me into how I should interact with it, that's bad.

If, on desktop, I can't scroll with the keyboard, that's bad.

If scrolling is erratic and jumpy on any platform, that's bad.

If content obviously extends past the viewport and there is no obvious way to scroll the viewport at all (as happens horizontally on mobile with the Famo.us website), that's bad.

It's all well and good to say "don't put native scrolling on a pedestal" but if the alternative simply isn't usable that pedestal sure seems justified.

Well you did hype it quite a bit. Just pretend the "hate" is HN hazing for your launch; it's a bit of trend around these parts.

I have a question: is the Lumosity iOS app built on Famo.us?

Between us and developers that participated in our private beta, many of the iOS transitions found on http://capptivate.co/ have been implemented and we're challenging Famo.us developers to try an build them all. IMHO, almost all if not all the iOS and Android apps showcased on Capptivate can be implemented with Famo.us. Those demos built so far were built by developers with a wide range of skills from junior to senior. Are all the demos perfect, nope. But do they all demonstrate that you can accomplish with the web pretty much anything you can accomplish in native without jumping through hoops and resorting to hideous hackery.

I think people are going to naturally be dismissive when there's such hype and buildup and then the results are in any way disappointing. It also didn't help that you had "Open Source JS Framework" on your AngelList profile and then everything was closed source. A lot of people felt that you guys just didn't understand what open source is. If you had released it early, like Meteor, I think the launch would have been a lot smoother.

I have many friends from my home country (Brazil) far removed from San Francisco and the Bay Area that know about what I'm working on without me telling them. The fact that they know about what Famo.us is working and we don't have the luxury of having the visibility of a Google or Apple, is a testament that this approach may have value.

Many of us are entrepreneurs here. Having a great technical solution is half the battle. Awareness is the other half. I've been doing this for a long time, and I think there's gobs of merit in our solution despite the rough edges. I also know there's gobs of skepticism of our approach. If how we've communicated has been less than ideal, but succeeded in getting people to at least try to framework out that either would have dismissed it out of hand or sat on the sidelines waiting for others to test it first, then it might have been worth it.

What I do know is that despite some of our foibles, that when someone who is knowledgeable actually takes the time to sit down and build something, they come back a believer in the approach we're taking. A few months ago, I replied calmy to one of the first naysayers I encountered early on on reddit who was about to dismiss us. He gave it a shot and he's now become one of our biggest supporters.

Lastly, to you and everyone else, if the criticism you're giving us comes deep down from your values (and is not just a kneejerk reaction and bandwagon haterism), please tell us. It's a learning experience. We're a pretty motley crew here as Famo.us and not all of us come from an Open Source background, thus not all of us have the same experience upon which to draw when making decisions on how to handle an issue that might be controversial. Some open source ideas are controversial among people with a different business background, just as some good business decisions may be controversial among us that work on open source. Oftentimes the solution that produces the most good is somewhere in the middle. Furthermore, just because someone doesn't have the same experience as you or I, it doesn't make their decision necessarily invalid, since they may be operating based on experience which we lack and informs them to the contrary to the conclusions we'd come to. I know that I myself joined Famo.us with far less experience on how to generate attention for the important work I may be working on. I learned a ton about the value of that skill. Sometimes the difference between succeeding or failing with a good solution is generating publicity that increases willingness to experiement with your solution. Howard Aiken once said, "Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats.". The lesson I've learned is that if you've got a good idea and you're worried about ramming it down their throats, you're probably selling it wrong.

Thanks for your thoughtful, balanced comments.

Nearly every day I curse Google for breaking the native interactions with my browser (I mostly use Opera and they seem to only care about support for Chrome). For instance, today I was trying to type an equals sign and Google Docs only wanted to enter a plus, with or without the shift key. Please don't use them as your role model.

The thing about native toolkits is that they are battle-tested and you can trust them to work. Custom UI components are bound to have nasty little lurking bugs, so you should use them as icing on the cake. For things that are absolutely essential, like scrolling or entering data, please use components I can trust.

I've been around software long enough to remember when desktop application devs thought it was a good idea to develop their own basic UI components. Needless to say (or maybe not) they were often broken, usually in unexpected and irregular ways. I suppose it's only fitting that web devs would try, though to be honest I hoped that impulse had ended with the death of Flash.

We only work better on Webkit over other browsers because Webkit has the most mature implementation of the W3C APIs upon which we rely. We do not not rely on special vendor-specific features that are only implemented in Chrome or Safari.

If something doesn't work properly in some browsers, like Internet Explorer thus far, then that is because that browser has yet to implement the features upon which we depend or has yet to implement it correctly. We'll work to account for variability between implementations, but at the end of the day that's how things get done.

Native toolkits are battle-tested because they have had the luxury of time. There is nothing inherent about the web that excludes it from the opportunity of also being battle tested.

Our plan is not to have custom one-off UI components, but to actually mature what we're building into something that rivals what is done in native land. What better way long term is there for the open-source world to hedge risk against closed platforms than to move those native features to the web and perfect them.

    "For things that are absolutely essential, like scrolling or 
    entering data, please use components I can trust."

    "I suppose it's only fitting that web devs would try, though to 
    be honest I hoped that impulse had ended with the death of 
    Flash."

The only difference between the native components you keep on a pedestal and what we're building with the help of the community is time and polish.

Perform a mind experiment here: fast forward 1-2 years and just assume we are at parity with the native controls you prefer today. Given that what we're building is open and extensible to new unforeseen use cases, is that really a set-back or a leap forward in terms of what it enables us to explore as a community? The only thing standing between us and that future is time and effort.

Classic Vista moment.