5 ms·

Web Developer Admits: Objective-C Beats HTML5

25 points by jesskah 14y ago

chrisringrose 14y ago
Beats it in how easy it is to create, yes. But HTML5 is cross platform, and if done properly, the speed differences are not noticeable to the human eye. In fact, "Fastbook" is proof that an HTML5 app can be FASTER than it's iOS counterpart. http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story http://www.sencha.com/blog/the-making-of-fastbook-an-html5-l... Check out their video. They literally duplicated the iOS functionality, and made it faster, with HTML5.
- millstone 14y ago
  They did not "literally duplicate the iOS functionality." After months of work, and modifying their own framework, they produced...a technology demo, which omits core functionality like searching. Also, I don't agree that the Fastbook app is HTML5 "done properly." From their article: So the Fastbook app is the first to make use of a brand new “Sandbox Container” which programmatically detaches complex views and renders them into their own iframes, and thus partitioning the DOM tree...events, positioning, styling, and JavaScript code have to be proxied between the parent window and the child sandboxes. I would characterize this as "heroics."
  - chrisringrose 14y ago
    No, of course they didn't duplicate every bit of Facebook's functionality. You missed the point, I'm afraid. The very specific functionality they targeted performed as well as the native app, and in some cases, better. They are both pulling the same data from Facebook, and just displaying it to the user. One is native, one is HTML5.
- jmcdonald-ut 14y ago
  Given the considerable resources that Facebook has, and the amount of effort they put into an HTML5 application at first, it seems reasonable that native still gives a much superior experience. Sencha has done some great things, but one must consider the bias Sencha has for HTML5 to be great. It is in Facebook's best interest to deliver the best experience possible, but it is in Sencha's interest to deliver promising HTML5 results. I'm not sure we can mark this as a win for HTML5, but what Sencha did is impressive. HTML5 will certainly continue to grow, and this is a fantastic step forward. You are also correct that HTML5 is cross platform, and Sencha has proven that HTML5 can be taken into serious consideration when starting a new project.
  - greggman 14y ago
    > Given the considerable resources that ____ has ... This is far from true. Example: Given the amount of resources Microsoft has and all the effort they put in UX it seems reasonable they have made the best UX decisions No, that's provably not true. It seems logical that the large resources of big companies would work that way but that's not how the real world works. It always comes down to just a few people and their taste. Rarely are these kinds of decisions made based on anything more than a few people's opinions whether it's Microsoft, Google, Apple or Facebook. Whoever is the lead programmer for a particular project or lead UX designer for another or one of the 2 or 3 people around them decide this stuff based on nothing more than their professional opinion. That opinion might be more informed than your average joe but it has nothing to do with the size of the company and their "considerable resources".
    - chrisringrose 14y ago
      Agreed. The resources Facebook put into HTML5 are irrelevant. 9 women can't have a baby in 1 month. I think the biggest problem with HTML5 is development obstacles, and mobile browsers being under-powered. Think of it this way: creating a fluid GUI can require AJAX, and a number of other tricks to streamline loading. But a native app can load the whole GUI at once instantly. To make a fast and responsive native app is hard NOT to do, while doing the same in HTML5 is HARD to do.
    - jmcdonald-ut 14y ago
      I do agree that it comes down to a few people and their personal taste, but I still contend that those few people are often some of the brightest in the industry. That being said, the example such as Microsoft does ring true, and perhaps Facebook didn't give HTML5 a fair try. I still think that overall evidence has been pretty clear that native can still provide better performance.
- mikeash 14y ago
  Do you have any example of HTML5 "done properly"? I don't believe I've ever seen any. (Yes, saw the video link, but it would be nice to have something I can actually try.)
  - chrisringrose 14y ago
    Sure. Gmail.com run on the iPhone. In some cases, such as opening a subfolder that I haven't been in, loads more quickly than Apple's Mail app. (This is provably because of IMAP lag.)
    - mikeash 14y ago
      Scrolling has a noticeable and jarring pause when reaching the top or bottom of the list, and in general isn't smooth when the "pull to refresh" area is visible, at least on my 4S. It's really good overall, but definitely not quite in the realm of no noticeable difference from a native app.
      - chrisringrose 14y ago
        This is a result of Google's decision to not "perfect" this on their web app - but it could be. It's just low priority. Just as there is lag and jittery scrolling when loading older posts in the Android native Facebook app, it's not a result of the platform, but a result of poor design, or not putting the effort into that one area of optimization.
  - chrisringrose 14y ago
    For more examples of HTML5 in use, check: http://12devsofxmas.co.uk/post/2012-12-26-day-1-the-future-of-games-on-the-web http://12devsofxmas.co.uk/post/2012-12-26-day-1-the-future-o...
- pooriaazimi 14y ago
  > HTML5 done properly I've seen Gmail.app on a friend's iPhone 4S (with dual-core A5) and it's slower than Apple's Mail.app on my sister's iPhone 3G (with a 300MHz ARMv6, which I think is under clocked to 230MHz or something like that). When Google (king of the Internet and HTML5) fails to "do HTML5 properly", then the rest of us really don't have much chance. (and, no, it's not (entirely) UIWebView's fault. If Google were allowed to use Nitro or V8, Gmail.app would be 40% faster. But that iPhone 5's CPU is like 20 times faster than that crummy old iPhone 3G)
  - greggman 14y ago
    I wasn't aware the gmail ios app is HTML5. Do you have some link that claims that it is?
    - wmil 14y ago
      It's a hybrid app. Native with some features implemented with web views. http://geeks.everything.me/2012/12/09/451/ http://geeks.everything.me/2012/12/09/451/
      - pooriaazimi 14y ago
        > Native with some features implemented with web views Well, some is a little bit misleading. More like most (60-70%) :) - the old app was like 95% web-stuff. The new one (released a few weeks ago) does things more "natively"
  - chrisringrose 14y ago
    An email app like Mail just download and keep offline copies of most of the mail. Opening the app and it instantly shows the pre-downloaded stuff. Yes, so in that sense, the mail app is faster. Bravo. The 40% faster boost takes us into the range of not-really-noticeable. If there were a dev tool to make efficient HTML5 apps just like there is to make native, and this speed difference was in miliseconds, not seconds, developers will flock to HTML5.
    - 14y ago
hayksaakian 14y ago
Right tool for the right job and all that jazz. We don't need more flamebait like the OP.
- jonathantrevor 14y ago
  One of the points I was trying to get through, and perhaps didn't do a great job of, was that I keep seeing people/apps trying to use HTML and various wrapping frameworks / toolkits to create the look and feel of an iOS app. Even worse, many of these "apps" don't even need to be apps (end of the article). We went this route too and hoped we could re-use lots of code we already had but, as you say, the right tool for an iOS app is Objective-C. Un-JITed JS inside a wrapped app with a zillion Objective-C stubs using the DOM in a view-like manner its not meant to represent just doesn't do it.
yuhong 14y ago
Personally I think "HTML5" is a misnomer even as a buzzword. Better to compare a specific browser instead.
jayfuerstenberg 14y ago
I loved this quote: "The best way of creating that awesome app is not to insulate yourself from the power of the operating system you are running on but to embrace it."
Executor 14y ago
Title should be renamed to "native code beats html5". I'd rather program in html5/js than obj-c anyday!
- jonathantrevor 14y ago
  Its not really a question of what you'd prefer to code in (you'll always prefer something familiar) but what delivers the best result for what you're trying to do. In essence we created two real, not test, apps, one using HTML and one using Objective-C. The clear winner was Objective-C in our experience, at this time. Creating a great mobile interface using HTML5 is certainly worth doing and can be done - but I dont think it should be made to look and feel like an app (either in safari or wrapped) since the "not-quite-right" issues just keep piling up, and if you want the look and feel of iOS you should just go native in the first place.

25 points by jesskah 14y ago

Beats it in how easy it is to create, yes. But HTML5 is cross platform, and if done properly, the speed differences are not noticeable to the human eye. In fact, "Fastbook" is proof that an HTML5 app can be FASTER than it's iOS counterpart. http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story http://www.sencha.com/blog/the-making-of-fastbook-an-html5-l... Check out their video. They literally duplicated the iOS functionality, and made it faster, with HTML5.

millstone 14y ago
They did not "literally duplicate the iOS functionality." After months of work, and modifying their own framework, they produced...a technology demo, which omits core functionality like searching. Also, I don't agree that the Fastbook app is HTML5 "done properly." From their article: So the Fastbook app is the first to make use of a brand new “Sandbox Container” which programmatically detaches complex views and renders them into their own iframes, and thus partitioning the DOM tree...events, positioning, styling, and JavaScript code have to be proxied between the parent window and the child sandboxes. I would characterize this as "heroics."
- chrisringrose 14y ago
  No, of course they didn't duplicate every bit of Facebook's functionality. You missed the point, I'm afraid. The very specific functionality they targeted performed as well as the native app, and in some cases, better. They are both pulling the same data from Facebook, and just displaying it to the user. One is native, one is HTML5.
jmcdonald-ut 14y ago
Given the considerable resources that Facebook has, and the amount of effort they put into an HTML5 application at first, it seems reasonable that native still gives a much superior experience. Sencha has done some great things, but one must consider the bias Sencha has for HTML5 to be great. It is in Facebook's best interest to deliver the best experience possible, but it is in Sencha's interest to deliver promising HTML5 results. I'm not sure we can mark this as a win for HTML5, but what Sencha did is impressive. HTML5 will certainly continue to grow, and this is a fantastic step forward. You are also correct that HTML5 is cross platform, and Sencha has proven that HTML5 can be taken into serious consideration when starting a new project.
- greggman 14y ago
  > Given the considerable resources that ____ has ... This is far from true. Example: Given the amount of resources Microsoft has and all the effort they put in UX it seems reasonable they have made the best UX decisions No, that's provably not true. It seems logical that the large resources of big companies would work that way but that's not how the real world works. It always comes down to just a few people and their taste. Rarely are these kinds of decisions made based on anything more than a few people's opinions whether it's Microsoft, Google, Apple or Facebook. Whoever is the lead programmer for a particular project or lead UX designer for another or one of the 2 or 3 people around them decide this stuff based on nothing more than their professional opinion. That opinion might be more informed than your average joe but it has nothing to do with the size of the company and their "considerable resources".
  - chrisringrose 14y ago
    Agreed. The resources Facebook put into HTML5 are irrelevant. 9 women can't have a baby in 1 month. I think the biggest problem with HTML5 is development obstacles, and mobile browsers being under-powered. Think of it this way: creating a fluid GUI can require AJAX, and a number of other tricks to streamline loading. But a native app can load the whole GUI at once instantly. To make a fast and responsive native app is hard NOT to do, while doing the same in HTML5 is HARD to do.
  - jmcdonald-ut 14y ago
    I do agree that it comes down to a few people and their personal taste, but I still contend that those few people are often some of the brightest in the industry. That being said, the example such as Microsoft does ring true, and perhaps Facebook didn't give HTML5 a fair try. I still think that overall evidence has been pretty clear that native can still provide better performance.
mikeash 14y ago
Do you have any example of HTML5 "done properly"? I don't believe I've ever seen any. (Yes, saw the video link, but it would be nice to have something I can actually try.)
- chrisringrose 14y ago
  Sure. Gmail.com run on the iPhone. In some cases, such as opening a subfolder that I haven't been in, loads more quickly than Apple's Mail app. (This is provably because of IMAP lag.)
  - mikeash 14y ago
    Scrolling has a noticeable and jarring pause when reaching the top or bottom of the list, and in general isn't smooth when the "pull to refresh" area is visible, at least on my 4S. It's really good overall, but definitely not quite in the realm of no noticeable difference from a native app.
    - chrisringrose 14y ago
      This is a result of Google's decision to not "perfect" this on their web app - but it could be. It's just low priority. Just as there is lag and jittery scrolling when loading older posts in the Android native Facebook app, it's not a result of the platform, but a result of poor design, or not putting the effort into that one area of optimization.
- chrisringrose 14y ago
  For more examples of HTML5 in use, check: http://12devsofxmas.co.uk/post/2012-12-26-day-1-the-future-of-games-on-the-web http://12devsofxmas.co.uk/post/2012-12-26-day-1-the-future-o...
pooriaazimi 14y ago
> HTML5 done properly I've seen Gmail.app on a friend's iPhone 4S (with dual-core A5) and it's slower than Apple's Mail.app on my sister's iPhone 3G (with a 300MHz ARMv6, which I think is under clocked to 230MHz or something like that). When Google (king of the Internet and HTML5) fails to "do HTML5 properly", then the rest of us really don't have much chance. (and, no, it's not (entirely) UIWebView's fault. If Google were allowed to use Nitro or V8, Gmail.app would be 40% faster. But that iPhone 5's CPU is like 20 times faster than that crummy old iPhone 3G)
- greggman 14y ago
  I wasn't aware the gmail ios app is HTML5. Do you have some link that claims that it is?
  - wmil 14y ago
    It's a hybrid app. Native with some features implemented with web views. http://geeks.everything.me/2012/12/09/451/ http://geeks.everything.me/2012/12/09/451/
    - pooriaazimi 14y ago
      > Native with some features implemented with web views Well, some is a little bit misleading. More like most (60-70%) :) - the old app was like 95% web-stuff. The new one (released a few weeks ago) does things more "natively"
- chrisringrose 14y ago
  An email app like Mail just download and keep offline copies of most of the mail. Opening the app and it instantly shows the pre-downloaded stuff. Yes, so in that sense, the mail app is faster. Bravo. The 40% faster boost takes us into the range of not-really-noticeable. If there were a dev tool to make efficient HTML5 apps just like there is to make native, and this speed difference was in miliseconds, not seconds, developers will flock to HTML5.
  - 14y ago

hayksaakian 14y ago

Right tool for the right job and all that jazz. We don't need more flamebait like the OP.

jonathantrevor 14y ago
One of the points I was trying to get through, and perhaps didn't do a great job of, was that I keep seeing people/apps trying to use HTML and various wrapping frameworks / toolkits to create the look and feel of an iOS app. Even worse, many of these "apps" don't even need to be apps (end of the article). We went this route too and hoped we could re-use lots of code we already had but, as you say, the right tool for an iOS app is Objective-C. Un-JITed JS inside a wrapped app with a zillion Objective-C stubs using the DOM in a view-like manner its not meant to represent just doesn't do it.

yuhong 14y ago

Personally I think "HTML5" is a misnomer even as a buzzword. Better to compare a specific browser instead.

jayfuerstenberg 14y ago

I loved this quote: "The best way of creating that awesome app is not to insulate yourself from the power of the operating system you are running on but to embrace it."

Executor 14y ago

Title should be renamed to "native code beats html5". I'd rather program in html5/js than obj-c anyday!

jonathantrevor 14y ago
Its not really a question of what you'd prefer to code in (you'll always prefer something familiar) but what delivers the best result for what you're trying to do. In essence we created two real, not test, apps, one using HTML and one using Objective-C. The clear winner was Objective-C in our experience, at this time. Creating a great mobile interface using HTML5 is certainly worth doing and can be done - but I dont think it should be made to look and feel like an app (either in safari or wrapped) since the "not-quite-right" issues just keep piling up, and if you want the look and feel of iOS you should just go native in the first place.