8 ms·

It's more complicated than you make it out to be. Facebook has to work consistently on so many different platforms (not just iPhone, Android, Blackberry and Wi

by pdog 14y ago

It's more complicated than you make it out to be. Facebook has to work consistently on so many different platforms (not just iPhone, Android, Blackberry and Windows Phone; also, the billion+ feature phones out there) and continuous deployment is the process at the heart of Facebook (the motto: move fast, break things). Facebook is always adding new features and improvements. By using Web technologies, they can share code and make these changes on the server side, not to ease developers' efficiency but to guarantee interoperability and a consistent user experience.

flatline3 14y ago
> It's more complicated than you make it out to be. I didn't make it out to be simple or complicated. They valued their sense of developer efficiency over user experience.
- snowwrestler 14y ago
  No matter how efficient your developers are, it's gonna take longer to get a new version of a native app submitted, approved, and downloaded by users, than it is to simple deploy to a webserver. By going native, Facebook has greatly improved the user experience of this version of their app (which I applaud), but greatly slowed the speed at which they can iterate to the next version.
  - flatline3 14y ago
    User spend their time using the application, not waiting for an update. Sacrificing their user experience for rapid updates is putting a sense of engineering efficiency ahead of user experience.
    - smackfu 14y ago
      What if the update is a bug fix?
      - flatline3 14y ago
        That still isn't where the vast majority of user time is spent. If the goal is putting user experience first, and you're concerned about critical bugs, then expend the engineering effort required to reduce the risk of rolling out a bug. Related aside; Apple can roll out an emergency fix in an hour or two.
        peterhunt 14y ago
        Because it's their app store.
        flatline3 14y ago
        To clarify, I was referring to Apple's policy regarding emergency fixes for 3rd party applications.
        eberyvody 14y ago
        I think you're missing the point. How long does it take for that fix to be downloaded? Tons of users will never see it. Tons of users will continue to use the version with the vulnerability. Here's a good talk on the subject: http://www.youtube.com/watch?v=MksKaRpWD-o http://www.youtube.com/watch?v=MksKaRpWD-o
        flatline3 14y ago
        How is this an argument in favor of an over-all worse user-experience? If this is a significant concern to you, then prompt or enforce upgrades in your application.
    - snowwrestler 14y ago
      Consider a UI update that is, provably, an improvement to the user experience. Delaying that update by 3 weeks (due to the App Store process) is itself a form of sacrificing the user experience. Or more likely, consider an example where Facebook is not sure which of 3 UI changes would most improve the user experience, and they want to serve each of the 3 to small subsets to collect test data. Native UI rendering takes away this ability, potentially reducing Facebook's ability to improve the user experience--also a form of sacrifice. Now maybe you believe that the poor performance of the HTML5 UI was an even greater sacrifice than these, and thus the switch to the native UI is a net improvement in user experience. I happen to agree with that, but that doesn't mean there aren't tradeoffs. Performance issues aside, the user experience of the Facebook mobile app is miles better now than it was when they last rendered the iOS UI natively. A big reason for that is the speed at which they iterate changes in the HTML5 UI. Edit to add TL;DR: There is more to optimizing the user experience than maximizing UI performance.
      - shadesandcolour 14y ago
        Given the reaction to any small UI update Facebook has rolled out since people began using the site has be pretty bad, maybe it's better that it takes more time to roll the changes out.
        nostrademons 14y ago
        The reaction to any small UI update, anywhere, is pretty bad. People hate change (or more specifically, they hate having change forced upon them). The reaction to rolling back the changes after they've been out several months is usually equally bad.
      - mahyarm 14y ago
        If you look into their tech blog post about the update, they use HTML5 as a fallback render for new stuff. They then create the native renderer for the widget and push it with the new update a few weeks/months later. So they can still A/B test as quickly as they want.
  - revetkn 14y ago
    Who cares how fast you can iterate if your product is unusably and unfixably bad?
- saturdaysaint 14y ago
  I didn't make it out to be simple or complicated. They simply valued their sense of efficiency over user experience. There's not much room for "simply" when you're talking about a service that has to work across dozens of OS/browser variants, is practically a utility to its (hundreds of millions of) users, and receives multiple daily updates. This isn't an upstart web service that can optimize around a platform that might be only a fraction of their potential user base either.
  - jpxxx 14y ago
    Perhaps not. But when your most valuable customers are clustering around one or two platforms...
- marknutter 14y ago
  Give me a freaking break, please. Tell me where the Android 100% native app is? Oh, it doesn't exist yet? In my book, not existing is the worst kind of user experience. There are concessions to be made when going full native just like they are when going hybrid. In this case, it's speed of development.
- zmmmmm 14y ago
  You just repeated your oversimplification: "They valued their sense of developer efficiency over user experience" No, they made a judgement that user experience would ultimately be better from being able to deploy rapid changes via a consistent cross platform experience under their control vs writing OS specific code and placing themselves under the control of a third party and that will significantly operationally limit them ("Can we roll out the new user profile yet? No, we're still waiting on Apple to approve the change ..."). They may have been wrong, but it doesn't change their original intent. If anything we should all be lamenting the failure of HTML5 as a truly viable app replacement at this point; I can't blame Facebook for wanting to believe it would be possible.
  - flatline3 14y ago
    I'm curious as to whether you think users want, need, benefit, or care about whether Facebook can deploy rapid changes via a "consistent cross platform experience". In my experience, users want a consistent platform experience -- one that fits in with the platform that they're using. They're also not interested in your development processes, especially if it means rapid dispatch of potentially breaking changes. In fact, I'd say that runs counter to user's interests. Engineers and product managers seem to be the primary cheerleaders of "consistent cross platform experience". I don't see why a user would want that. I do see why developers and product managers would want that. > If anything we should all be lamenting the failure of HTML5 as a truly viable app replacement at this point; I can't blame Facebook for wanting to believe it would be possible. I'm not lamenting HTML5 as a viable application platform replacement, because it never was going to be one. The web industry consistently ignores 30+ years of experience that the desktop (and now mobile) development industries have in bringing high quality applications to user's devices. The web universe eschews common platform conventions, common rendering approaches, common widget libraries, and instead has attempted to force everyone to individually reinvent application development on top of DOM, CSS, and JavaScript -- a SGML-derived history-laden mess that served documents well and applications poorly. The lesson for the web industry should be that they need to figure out how to bring align whatever ethos they have -- presumably of a common, open platform -- and bring them to bear on implementing something genuinely competitive with the native development platforms. DOM/CSS/JS is not it.
rburhum 14y ago
Since mobile is their biggest growth platform and considering that they have the resources, I just don't see this as a strong argument. I always thought it was very silly that the website ran better and faster in Safari vs the "native" app.
- DonnyV 14y ago
  That's not Facebook's fault its Apple's. iOS's UIWebView uses an older version of webkit and a much older version of there javascript engine. Apple doesn't want you building web apps they can't monetize.
  - taligent 14y ago
    You know it takes talent to write a statement that is so completely wrong. Others have addressed the JS point but Apple originally wanted developers to only build web apps and it took a lot of convincing to get them to change their mind. Also Apple has a lot of free apps. So this idea that Apple is somehow obsessed with monetizing apps is simply not true.
    - DonnyV 14y ago
      Not really... if you write an app that's native, then in-app purchases are controlled by Apple and they get a 30% cut of those sales. If you build an app using UIWebView then you could by pass those in-app purchases and get 100% of the sale. ref: https://developer.apple.com/appstore/in-app-purchase/index.html https://developer.apple.com/appstore/in-app-purchase/index.h...
      - taligent 14y ago
        I'm well aware that in app purchases exist. And absolutely nothing is stopping you from offering payments from a website in a UIWebView. So not really sure what your point is ?
        cageface 14y ago

by pdog 14y ago

flatline3 14y ago

> It's more complicated than you make it out to be. I didn't make it out to be simple or complicated. They valued their sense of developer efficiency over user experience.

snowwrestler 14y ago
No matter how efficient your developers are, it's gonna take longer to get a new version of a native app submitted, approved, and downloaded by users, than it is to simple deploy to a webserver. By going native, Facebook has greatly improved the user experience of this version of their app (which I applaud), but greatly slowed the speed at which they can iterate to the next version.
- flatline3 14y ago
  User spend their time using the application, not waiting for an update. Sacrificing their user experience for rapid updates is putting a sense of engineering efficiency ahead of user experience.
  - smackfu 14y ago
    What if the update is a bug fix?
    - flatline3 14y ago
      That still isn't where the vast majority of user time is spent. If the goal is putting user experience first, and you're concerned about critical bugs, then expend the engineering effort required to reduce the risk of rolling out a bug. Related aside; Apple can roll out an emergency fix in an hour or two.
      - peterhunt 14y ago
        Because it's their app store.
        flatline3 14y ago
        To clarify, I was referring to Apple's policy regarding emergency fixes for 3rd party applications.
      - eberyvody 14y ago
        I think you're missing the point. How long does it take for that fix to be downloaded? Tons of users will never see it. Tons of users will continue to use the version with the vulnerability. Here's a good talk on the subject: http://www.youtube.com/watch?v=MksKaRpWD-o http://www.youtube.com/watch?v=MksKaRpWD-o
        flatline3 14y ago
        How is this an argument in favor of an over-all worse user-experience? If this is a significant concern to you, then prompt or enforce upgrades in your application.
  - snowwrestler 14y ago
    Consider a UI update that is, provably, an improvement to the user experience. Delaying that update by 3 weeks (due to the App Store process) is itself a form of sacrificing the user experience. Or more likely, consider an example where Facebook is not sure which of 3 UI changes would most improve the user experience, and they want to serve each of the 3 to small subsets to collect test data. Native UI rendering takes away this ability, potentially reducing Facebook's ability to improve the user experience--also a form of sacrifice. Now maybe you believe that the poor performance of the HTML5 UI was an even greater sacrifice than these, and thus the switch to the native UI is a net improvement in user experience. I happen to agree with that, but that doesn't mean there aren't tradeoffs. Performance issues aside, the user experience of the Facebook mobile app is miles better now than it was when they last rendered the iOS UI natively. A big reason for that is the speed at which they iterate changes in the HTML5 UI. Edit to add TL;DR: There is more to optimizing the user experience than maximizing UI performance.
    - shadesandcolour 14y ago
      Given the reaction to any small UI update Facebook has rolled out since people began using the site has be pretty bad, maybe it's better that it takes more time to roll the changes out.
      - nostrademons 14y ago
        The reaction to any small UI update, anywhere, is pretty bad. People hate change (or more specifically, they hate having change forced upon them). The reaction to rolling back the changes after they've been out several months is usually equally bad.
    - mahyarm 14y ago
      If you look into their tech blog post about the update, they use HTML5 as a fallback render for new stuff. They then create the native renderer for the widget and push it with the new update a few weeks/months later. So they can still A/B test as quickly as they want.
- revetkn 14y ago
  Who cares how fast you can iterate if your product is unusably and unfixably bad?
saturdaysaint 14y ago
I didn't make it out to be simple or complicated. They simply valued their sense of efficiency over user experience. There's not much room for "simply" when you're talking about a service that has to work across dozens of OS/browser variants, is practically a utility to its (hundreds of millions of) users, and receives multiple daily updates. This isn't an upstart web service that can optimize around a platform that might be only a fraction of their potential user base either.
- jpxxx 14y ago
  Perhaps not. But when your most valuable customers are clustering around one or two platforms...
marknutter 14y ago
Give me a freaking break, please. Tell me where the Android 100% native app is? Oh, it doesn't exist yet? In my book, not existing is the worst kind of user experience. There are concessions to be made when going full native just like they are when going hybrid. In this case, it's speed of development.
zmmmmm 14y ago
You just repeated your oversimplification: "They valued their sense of developer efficiency over user experience" No, they made a judgement that user experience would ultimately be better from being able to deploy rapid changes via a consistent cross platform experience under their control vs writing OS specific code and placing themselves under the control of a third party and that will significantly operationally limit them ("Can we roll out the new user profile yet? No, we're still waiting on Apple to approve the change ..."). They may have been wrong, but it doesn't change their original intent. If anything we should all be lamenting the failure of HTML5 as a truly viable app replacement at this point; I can't blame Facebook for wanting to believe it would be possible.
- flatline3 14y ago
  I'm curious as to whether you think users want, need, benefit, or care about whether Facebook can deploy rapid changes via a "consistent cross platform experience". In my experience, users want a consistent platform experience -- one that fits in with the platform that they're using. They're also not interested in your development processes, especially if it means rapid dispatch of potentially breaking changes. In fact, I'd say that runs counter to user's interests. Engineers and product managers seem to be the primary cheerleaders of "consistent cross platform experience". I don't see why a user would want that. I do see why developers and product managers would want that. > If anything we should all be lamenting the failure of HTML5 as a truly viable app replacement at this point; I can't blame Facebook for wanting to believe it would be possible. I'm not lamenting HTML5 as a viable application platform replacement, because it never was going to be one. The web industry consistently ignores 30+ years of experience that the desktop (and now mobile) development industries have in bringing high quality applications to user's devices. The web universe eschews common platform conventions, common rendering approaches, common widget libraries, and instead has attempted to force everyone to individually reinvent application development on top of DOM, CSS, and JavaScript -- a SGML-derived history-laden mess that served documents well and applications poorly. The lesson for the web industry should be that they need to figure out how to bring align whatever ethos they have -- presumably of a common, open platform -- and bring them to bear on implementing something genuinely competitive with the native development platforms. DOM/CSS/JS is not it.

rburhum 14y ago

Since mobile is their biggest growth platform and considering that they have the resources, I just don't see this as a strong argument. I always thought it was very silly that the website ran better and faster in Safari vs the "native" app.

DonnyV 14y ago
That's not Facebook's fault its Apple's. iOS's UIWebView uses an older version of webkit and a much older version of there javascript engine. Apple doesn't want you building web apps they can't monetize.
- taligent 14y ago
  You know it takes talent to write a statement that is so completely wrong. Others have addressed the JS point but Apple originally wanted developers to only build web apps and it took a lot of convincing to get them to change their mind. Also Apple has a lot of free apps. So this idea that Apple is somehow obsessed with monetizing apps is simply not true.
  - DonnyV 14y ago
    Not really... if you write an app that's native, then in-app purchases are controlled by Apple and they get a 30% cut of those sales. If you build an app using UIWebView then you could by pass those in-app purchases and get 100% of the sale. ref: https://developer.apple.com/appstore/in-app-purchase/index.html https://developer.apple.com/appstore/in-app-purchase/index.h...
    - taligent 14y ago
      I'm well aware that in app purchases exist. And absolutely nothing is stopping you from offering payments from a website in a UIWebView. So not really sure what your point is ?
      - cageface 14y ago