6 ms·
As an employee I have mixed feelings here. For a long time (I've been with the company for 2 years), I was the main person at the company arguing for the basics
by malandrew 12y ago
As an employee I have mixed feelings here. For a long time (I've been with the company for 2 years), I was the main person at the company arguing for the basics necessary for all apps like you suggest we should have done. However, looking at this from the inside my view has changed to where the approach we're taking probably makes the most sense long term even though it may not be immediately obvious.
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.
- dragonwriter 12y ago> No, we've got a ways to go. However for mobile devices, I would argue that Famo.us is definitely already there. 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.
- malandrew 12y agoFWIW, KitKat isn't on the list of versions we support. We target Ice Cream Sandwich and above. Also, are you using the stock Android browser or did you install Chrome? 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.
- dragonwriter 12y ago> FWIW, KitKat isn't on the list of versions we support. We target Ice Cream Sandwich and above. 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.