7 ms·

Mobile Apps: HTML5 vs Native

67 points by Rexxar 14y ago

pjmlp 14y ago
This is quite right, HTML 5 sucks for application development. It has come to replace Java with code once, debug everywhere. Every single browser version, even from the same vendor, or operating system has a different understating what CSS, HTML, JavaScript means.
- rimantas 14y ago
  And all this on top of the fact that HTML was not intended to build apps and it shows. No matter what is built on top foundation will still be messy and shaky. Just a few months ago I was working on moderately complex web app and even with some nice tools helping to bring some sanity into it (backbone, coffeescript, etc.) we had to reinvent a lot of thing that native APIs give you for free. It really makes me wonder about those proclaiming superiority of HTML5 over native: did they build anything nontrivial in it and did they try to do the same with native approach. Alas, I see html approach as "mediocre everywhere and pain to develop". And I say this as a guy who does know HTML, CSS and JS :(
  - pjmlp 14y ago
    As a contractor most of the projects I work on are web based ones. Every time I manage to land a native application contract I am thrilled to get away from such headaches. Specially the ones discussing pixel level behavior with the customer or trying to making him/her understand why certain desktop like features are not possible at all in a browser world.
rodion_89 14y ago
The argument that HTML5 apps cannot provide sufficient quality is growing increasing weak. There is no question that native apps provide better UI's, especially in the case of iOS. As for Facebook, they built a terrible iOS app and blamed the technology. It doesn't matter what technology you use: own up and build good products. HTML5's problem is mobile browsers. They are all non-compliant with a myriad of quirks. You can build nifty native-like UI's in the iOS browser, but it takes lots of time to understand exactly how Mobile Safari implements 3d transforms and how they are so terribly bizarre. I won't even start with the Android browser because the situation is significantly worse[1]. We can build good mobile browsers. The problem is that mobile OS venders have had little incentive to build browsers capable of hosting competing apps with their respective marketplaces. They all build browsers that can view traditional webpages well, but no more. [1] Anyone who brings up mobile Chrome will get a mouthful about why that's terrible as well.
- melling 14y ago
  Rather than provide an academic argument as to why HTML5 apps are as good as native, it would be better to provide great examples of where it has worked. Even Steve Jobs originally thought web apps were all you needed but he was eventually convinced otherwise. In short, how about some proof by example? Lots of examples...
  - rodion_89 14y ago
    I've always wondered why the App Store was a web app. It seems really out of place considering its job is to distribute native apps. On the other hand it has probably been the driving force to make mobile safari better.
    - wahnfrieden 14y ago
      Probably so that they can make iterations on its design without requiring people to download new software updates - a huge attraction of web apps.
      - rodion_89 14y ago
        I guess my question then is, why does that hold more true for the App Store than for any of their other native apps?
        wahnfrieden 14y ago
        Their other built-in apps don't involve as much marketing efforts inside them and don't drive post-purchase sales. I guess there is Newsreader or whatever but I haven't used it and can't comment on it.
        mmariani 14y ago
        Because the iTunes platform is written in Java with a legacy web framework called WebObjects. Also the iTunes business unity has more characteristics in common with Amazon than Apple itself. That's why we're stuck with a thin client for the AS.
elpool2 14y ago
I'm not seeing how thick vs thin clients has anything to do with the html5 vs. native debate. You can build an html5 based app that's just as "thick" as a native iOS app, it just uses a different technology to render the UI.
- rodion_89 14y ago
  UI rendering and a sane threading model are two major steps that could end these premature HTML5 vs native debate. I wait for the day when these debates are equivalent to arguments about programming language preference.
  - wahnfrieden 14y ago
    What's insane about web workers? (Just curious.)
    - rodion_89 14y ago
      I actually like the way Web Workers can't touch the DOM. It's nice to finally give the DOM it's personal space for UI operations, which often leads to much more responsive apps especially at a large scale. The pain points for me come in the form of shared dependencies. Large pieces of code that are accessible to multiple threads, and perhaps the UI thread, must get imported several times. The lack of access to localStorage hurts in a lot places because any cache access must send data back and forth on the UI thread for operations that are probably entirely unrelated. The lack of console.log makes debugging considerably worse. There are a couple of hacks to get around this but it's a bit crazy to pass messages between threads just to get a log printed. Having to create a file per thread is very much a pain. Certain operations are tiny in terms of code and make more sense in the context of where you want to run theme. It'd be nice to run any function on a separate thread. Conceptually that would get weird because it would violate several properties of JavaScript closures. But it'd be nice to find some acceptable way of doing this sort of thing. Web Workers are pretty good but can be unfriendly to developers at times.
      - 14y ago
javis 14y ago
The reason everyone asumes HTML5 apps can't work on mobile is because how awful UIWebView is on iOS. Apple really need to explain how limiting JavaScript speed in WebView makes it anymore more secure.
- rodion_89 14y ago
  JavaScript execution speed is no longer a major limiting factor on mobile. In terms of UI JavaScript execution speed will help you if you're using jQuery (or any naive animator) to animate 2d CSS properties. The DOM, 3d transforms, etc are the real pain points. As bad as UIWebView is, it somehow manages to be the best webview out of any mobile OS.[1] [1] as for BB10, I'll believe it when I see it.
  - notatoad 14y ago
    I'm going to assume you're getting downvotes for saying that jquery animations are better performing than native CSS animations. From everything I've seen, that's simply not true, regardless of the platform. I sure hope the downvotes aren't for saying that iOS's uiwebview is the best one we've got. Android web views mean using the android browser rendering engine, which is terrible. It might not be intentionally crippled like apple's is, but it is less capable to begin with.
    - rodion_89 14y ago
      I'm pretty sure I made no comment as to which is better, jQuery or CSS3 animations. On mobile there is no question whatsoever that CSS3 animations are much better. The big issues tend to be regarding 3d stacking contexts. You can end up with strange artifacts, z-index breaking transforms, and sometimes downright wrong positioning. Also GPU accelerated elements can sometimes come out blurred. jQuery animations fix this but perform much worse. On desktop it really depends. Browser compliance is an issue a lot of the time. You can actually slow down a 2d transition by using translate3d or any other GPU accelerated value. GPU acceleration hasn't had all its kinks worked out yet in browsers but its very likely that CSS3 transitions will be miles ahead for regular use cases in the future. I'm not saying that CSS3 transitions are worse, just that they are not better all of the time (only most of the time).
georgemcbay 14y ago
We are now into year 5 of "HTML5 is going to obsolete native apps in the next couple of years"... with no end in sight.
- marknutter 14y ago
  Come on now, it took at least this long for web apps to obsolete most native desktop apps. As mobile devices get more powerful with every passing year, I see no reason why history won't repeat itself.
  - rimantas 14y ago
    Can you be more specific about "most"? I enjoyed GMail, but now I use Sparrow (desktop and mobile) to access it: it is just much nicer. A lot of people use apps to access twitter.
  - TheFuture 14y ago
    Yeah, none of us are using Microsoft Word any more. Ever print anything from Google Docs? Look at the typography. Look at the letter spacing and kerning. It's a joke. And don't even get me started on javascript. I like to use word processing as an example because it's probably been the #1 client app for 40 years with no web app competitor even close. I would argue 1992 WordPerfect is better than Google Docs in quality, features, and reliability. The last decade of software development has been focused on web apps, and the promise that it's write-once-run-everywhere. So we've all been suffering by taking a huge step backwards in UI/UX by shoving everything in a browser. It is just not there. So you can keep struggling with your ugly javascript hacks and unsupported CSS quirks. But the best stuff is being made on the client right now. It's cleaner, easier to maintain code, and the UI/UX is delighting users. User's don't care about cross-platform.
    - ssk42 14y ago
      Would you mind elaborating on how WordPerfect in 1992 is better than modern day Google Docs?
  - 14y ago
ripperdoc 14y ago
Nice analysis, but only half of the story. As pointed out in the comments, you can make thick or thin clients in both native and HTML5. The issue is rather the one about lowest common denominator. HTML5 aims at working in very varied "runtime environment", where standards are bendable, bugs are rife and feature support a few years behind what native could muster. HTML5 is more difficult, and does not have all the tools, of the native environment. So the question is rather - will HTML5 develop faster than native and thereby be on par with it, or will it always be the straggler?
- chii 14y ago
  There is incentive from the platform creators to make their native UI better and better, but not the same incentives for making the HTML5 support (if they are in charge of it, e.g., a browser). By this argument, native will always have features that HTML5 is not able to achieve.
joelhooks 14y ago
My single biggest headache with "HTML5" mobile browser applications has been the text fields/inputs.
hnriot 14y ago
I can't help but find his arrogance about being right annoying, especially when he points to how battery technology hasn't improved since Kennedy was in power, which is just ignorant and wrong. Much of the limiting growth in mobile computing power has been gated by battery power and steadily the technology has improved. The debate has been going on since the browser was created, and it's really not a debate at all, the HTML to render a text box and the iOS native code to do so all call the same operating system library anyway, it's just a matter of where the development team decide to draw the line between ease if install and development vs speed and a richer user experience. This is fluid and shifts over the years as browser technology becomes more expressive. But I dislike reading articles that are just full of weasel wording, no examples to back up his points and technology inaccuracies.
hxf148 14y ago
My two latest HTML5 apps, http://appeio.com http://appeio.com for App.net which made it into the Apple iOS store and brand brand new http://podglass.com http://podglass.com which is my personal solution to podcast headaces.. and a reason to start pushing boundaries with <audio> and <video>. It's getting there, in two years a good HTML5 app will be very close and in some situations a better choice. Native will improve also but browser tech is due to leap by 2014. iOS will have a good run and so will Android but the web is open and will never get obsoleted.
johnyzee 14y ago
I don't get it. Client thickness is one area that seems to have no bearing on the HTML5 vs. native debate. A canvas and Javascript based application will most often be as thick as a native app, the client downloads it once off the web never to be heard from again. With the HTML5 game I'm developing[1] I can reboot the server with hundreds of active players and no one is the wiser. Tell me HTML5 apps feel wrong, are unresponsive, a pain in the ass to develop or lack features, but framing it as thin vs. thick client makes it sound like we are talking about native versus the page-based web apps of the 90's, which is unfair to the web. The art has developed and HTML5 in particular, with the immediate mode graphics of the canvas element and the increasingly sophisticated Javascript frameworks, is as capable a platform for rich clients as any, imho. [1]: http://www.webworks.dk/enginetest http://www.webworks.dk/enginetest
89a 14y ago
Not even a question at this point. Mobile is still too limited for HTML to even begin to compete with native.
ABS 14y ago
take a look at Calatrava then http://calatrava.github.com/ http://calatrava.github.com/ open source, mobile cross-platform logic, freedom to build great UIs

67 points by Rexxar 14y ago

pjmlp 14y ago

This is quite right, HTML 5 sucks for application development. It has come to replace Java with code once, debug everywhere. Every single browser version, even from the same vendor, or operating system has a different understating what CSS, HTML, JavaScript means.

rimantas 14y ago
And all this on top of the fact that HTML was not intended to build apps and it shows. No matter what is built on top foundation will still be messy and shaky. Just a few months ago I was working on moderately complex web app and even with some nice tools helping to bring some sanity into it (backbone, coffeescript, etc.) we had to reinvent a lot of thing that native APIs give you for free. It really makes me wonder about those proclaiming superiority of HTML5 over native: did they build anything nontrivial in it and did they try to do the same with native approach. Alas, I see html approach as "mediocre everywhere and pain to develop". And I say this as a guy who does know HTML, CSS and JS :(
- pjmlp 14y ago
  As a contractor most of the projects I work on are web based ones. Every time I manage to land a native application contract I am thrilled to get away from such headaches. Specially the ones discussing pixel level behavior with the customer or trying to making him/her understand why certain desktop like features are not possible at all in a browser world.

rodion_89 14y ago

The argument that HTML5 apps cannot provide sufficient quality is growing increasing weak. There is no question that native apps provide better UI's, especially in the case of iOS. As for Facebook, they built a terrible iOS app and blamed the technology. It doesn't matter what technology you use: own up and build good products. HTML5's problem is mobile browsers. They are all non-compliant with a myriad of quirks. You can build nifty native-like UI's in the iOS browser, but it takes lots of time to understand exactly how Mobile Safari implements 3d transforms and how they are so terribly bizarre. I won't even start with the Android browser because the situation is significantly worse[1]. We can build good mobile browsers. The problem is that mobile OS venders have had little incentive to build browsers capable of hosting competing apps with their respective marketplaces. They all build browsers that can view traditional webpages well, but no more. [1] Anyone who brings up mobile Chrome will get a mouthful about why that's terrible as well.

melling 14y ago
Rather than provide an academic argument as to why HTML5 apps are as good as native, it would be better to provide great examples of where it has worked. Even Steve Jobs originally thought web apps were all you needed but he was eventually convinced otherwise. In short, how about some proof by example? Lots of examples...
- rodion_89 14y ago
  I've always wondered why the App Store was a web app. It seems really out of place considering its job is to distribute native apps. On the other hand it has probably been the driving force to make mobile safari better.
  - wahnfrieden 14y ago
    Probably so that they can make iterations on its design without requiring people to download new software updates - a huge attraction of web apps.
    - rodion_89 14y ago
      I guess my question then is, why does that hold more true for the App Store than for any of their other native apps?
      - wahnfrieden 14y ago
        Their other built-in apps don't involve as much marketing efforts inside them and don't drive post-purchase sales. I guess there is Newsreader or whatever but I haven't used it and can't comment on it.
      - mmariani 14y ago
        Because the iTunes platform is written in Java with a legacy web framework called WebObjects. Also the iTunes business unity has more characteristics in common with Amazon than Apple itself. That's why we're stuck with a thin client for the AS.

elpool2 14y ago

I'm not seeing how thick vs thin clients has anything to do with the html5 vs. native debate. You can build an html5 based app that's just as "thick" as a native iOS app, it just uses a different technology to render the UI.

rodion_89 14y ago
UI rendering and a sane threading model are two major steps that could end these premature HTML5 vs native debate. I wait for the day when these debates are equivalent to arguments about programming language preference.
- wahnfrieden 14y ago
  What's insane about web workers? (Just curious.)
  - rodion_89 14y ago
    I actually like the way Web Workers can't touch the DOM. It's nice to finally give the DOM it's personal space for UI operations, which often leads to much more responsive apps especially at a large scale. The pain points for me come in the form of shared dependencies. Large pieces of code that are accessible to multiple threads, and perhaps the UI thread, must get imported several times. The lack of access to localStorage hurts in a lot places because any cache access must send data back and forth on the UI thread for operations that are probably entirely unrelated. The lack of console.log makes debugging considerably worse. There are a couple of hacks to get around this but it's a bit crazy to pass messages between threads just to get a log printed. Having to create a file per thread is very much a pain. Certain operations are tiny in terms of code and make more sense in the context of where you want to run theme. It'd be nice to run any function on a separate thread. Conceptually that would get weird because it would violate several properties of JavaScript closures. But it'd be nice to find some acceptable way of doing this sort of thing. Web Workers are pretty good but can be unfriendly to developers at times.
    - 14y ago

javis 14y ago

The reason everyone asumes HTML5 apps can't work on mobile is because how awful UIWebView is on iOS. Apple really need to explain how limiting JavaScript speed in WebView makes it anymore more secure.

rodion_89 14y ago
JavaScript execution speed is no longer a major limiting factor on mobile. In terms of UI JavaScript execution speed will help you if you're using jQuery (or any naive animator) to animate 2d CSS properties. The DOM, 3d transforms, etc are the real pain points. As bad as UIWebView is, it somehow manages to be the best webview out of any mobile OS.[1] [1] as for BB10, I'll believe it when I see it.
- notatoad 14y ago
  I'm going to assume you're getting downvotes for saying that jquery animations are better performing than native CSS animations. From everything I've seen, that's simply not true, regardless of the platform. I sure hope the downvotes aren't for saying that iOS's uiwebview is the best one we've got. Android web views mean using the android browser rendering engine, which is terrible. It might not be intentionally crippled like apple's is, but it is less capable to begin with.
  - rodion_89 14y ago
    I'm pretty sure I made no comment as to which is better, jQuery or CSS3 animations. On mobile there is no question whatsoever that CSS3 animations are much better. The big issues tend to be regarding 3d stacking contexts. You can end up with strange artifacts, z-index breaking transforms, and sometimes downright wrong positioning. Also GPU accelerated elements can sometimes come out blurred. jQuery animations fix this but perform much worse. On desktop it really depends. Browser compliance is an issue a lot of the time. You can actually slow down a 2d transition by using translate3d or any other GPU accelerated value. GPU acceleration hasn't had all its kinks worked out yet in browsers but its very likely that CSS3 transitions will be miles ahead for regular use cases in the future. I'm not saying that CSS3 transitions are worse, just that they are not better all of the time (only most of the time).

georgemcbay 14y ago

We are now into year 5 of "HTML5 is going to obsolete native apps in the next couple of years"... with no end in sight.

marknutter 14y ago
Come on now, it took at least this long for web apps to obsolete most native desktop apps. As mobile devices get more powerful with every passing year, I see no reason why history won't repeat itself.
- rimantas 14y ago
  Can you be more specific about "most"? I enjoyed GMail, but now I use Sparrow (desktop and mobile) to access it: it is just much nicer. A lot of people use apps to access twitter.
- TheFuture 14y ago
  Yeah, none of us are using Microsoft Word any more. Ever print anything from Google Docs? Look at the typography. Look at the letter spacing and kerning. It's a joke. And don't even get me started on javascript. I like to use word processing as an example because it's probably been the #1 client app for 40 years with no web app competitor even close. I would argue 1992 WordPerfect is better than Google Docs in quality, features, and reliability. The last decade of software development has been focused on web apps, and the promise that it's write-once-run-everywhere. So we've all been suffering by taking a huge step backwards in UI/UX by shoving everything in a browser. It is just not there. So you can keep struggling with your ugly javascript hacks and unsupported CSS quirks. But the best stuff is being made on the client right now. It's cleaner, easier to maintain code, and the UI/UX is delighting users. User's don't care about cross-platform.
  - ssk42 14y ago
    Would you mind elaborating on how WordPerfect in 1992 is better than modern day Google Docs?
- 14y ago

ripperdoc 14y ago

Nice analysis, but only half of the story. As pointed out in the comments, you can make thick or thin clients in both native and HTML5. The issue is rather the one about lowest common denominator. HTML5 aims at working in very varied "runtime environment", where standards are bendable, bugs are rife and feature support a few years behind what native could muster. HTML5 is more difficult, and does not have all the tools, of the native environment. So the question is rather - will HTML5 develop faster than native and thereby be on par with it, or will it always be the straggler?

chii 14y ago
There is incentive from the platform creators to make their native UI better and better, but not the same incentives for making the HTML5 support (if they are in charge of it, e.g., a browser). By this argument, native will always have features that HTML5 is not able to achieve.

joelhooks 14y ago

My single biggest headache with "HTML5" mobile browser applications has been the text fields/inputs.

hnriot 14y ago

I can't help but find his arrogance about being right annoying, especially when he points to how battery technology hasn't improved since Kennedy was in power, which is just ignorant and wrong. Much of the limiting growth in mobile computing power has been gated by battery power and steadily the technology has improved. The debate has been going on since the browser was created, and it's really not a debate at all, the HTML to render a text box and the iOS native code to do so all call the same operating system library anyway, it's just a matter of where the development team decide to draw the line between ease if install and development vs speed and a richer user experience. This is fluid and shifts over the years as browser technology becomes more expressive. But I dislike reading articles that are just full of weasel wording, no examples to back up his points and technology inaccuracies.

hxf148 14y ago

My two latest HTML5 apps, http://appeio.com http://appeio.com for App.net which made it into the Apple iOS store and brand brand new http://podglass.com http://podglass.com which is my personal solution to podcast headaces.. and a reason to start pushing boundaries with <audio> and <video>. It's getting there, in two years a good HTML5 app will be very close and in some situations a better choice. Native will improve also but browser tech is due to leap by 2014. iOS will have a good run and so will Android but the web is open and will never get obsoleted.

johnyzee 14y ago

I don't get it. Client thickness is one area that seems to have no bearing on the HTML5 vs. native debate. A canvas and Javascript based application will most often be as thick as a native app, the client downloads it once off the web never to be heard from again. With the HTML5 game I'm developing[1] I can reboot the server with hundreds of active players and no one is the wiser. Tell me HTML5 apps feel wrong, are unresponsive, a pain in the ass to develop or lack features, but framing it as thin vs. thick client makes it sound like we are talking about native versus the page-based web apps of the 90's, which is unfair to the web. The art has developed and HTML5 in particular, with the immediate mode graphics of the canvas element and the increasingly sophisticated Javascript frameworks, is as capable a platform for rich clients as any, imho. [1]: http://www.webworks.dk/enginetest http://www.webworks.dk/enginetest

89a 14y ago

Not even a question at this point. Mobile is still too limited for HTML to even begin to compete with native.

ABS 14y ago

take a look at Calatrava then http://calatrava.github.com/ http://calatrava.github.com/ open source, mobile cross-platform logic, freedom to build great UIs