7 ms·

HTML5 Mythbusting

111 points by caludio 14y ago

tptacek 14y ago
Most of these don't seem like "myths" so much as "uncomfortable realities". It's not a myth that native apps are faster because they get preferential access to the hardware, for instance, it's just a fact.
- marknutter 14y ago
  There are "uncomfortable realities" associated with native development as well, such as the cost of porting to other platforms, forcing users to upgrade their hardware to stay current, app discoverability issues, etc.
  - randomdata 14y ago
    - the cost of porting to other platforms On the other hand, while it is rapidly getting better, the tooling for HTML5 apps are still generally the wild west. You can hack together an HTML5 app in no time, but unless you are doing something that is completely bog standard, by the time you properly engineer your HTML5 app, you probably could have delivered on two or three native platforms. - forcing users to upgrade their hardware to stay current If your app needs something from newer hardware to function properly (more processing power, new I/O devices, etc.), how does HTML5 alleviate that problem? If you mean forcing users to upgrade their operating systems (which is sometimes dictated by the hardware) for new features, I'll note that the browsers/HTML5 rendering systems are generally part of that upgrade, still requiring said upgrade to use those features in HTML5. - app discoverability issues Given that a native mobile app can use all of the same marketing tools a web app has, plus the vendor's app marketplace, couldn't it be said that native apps have better discoverability?
    - nwienert 14y ago
      - the cost of porting to other platforms Where in mobile can you live-debug an application both visually and functionally like you can with Web Inspector? I mean literally you are coding and debugging your app at the same time. And with LiveReload you don't even leave your editor to see your code changes instantly. Not to mention you are coding in JavaScript and CSS so the time it takes to iterate between various solutions is a fraction of the time of Objective C or Java. I think you have your first point backwards. There may not be an equivalent IDE, but we have a runtime inspector/editor baked into our runtime platform. You can't beat that. - forcing users to upgrade their hardware to stay current On Android you can update your default browser through the app store. - app discoverability issues Perhaps, but then again your app could just be rejected/removed at any time. Plus the whole 30% cut, time to release, limited sales options, etc. You're not in control of your app.
      - rimantas 14y ago
        > Where in mobile can you live-debug an application both > visually and functionally like you can with Web > Inspector? Visually? Interface builder in Xcode. Functionally? Instrumenta, lldb. > coding in JavaScript and CSS so the time it takes to > iterate between various solutions is a fraction of the > time of Objective C or Java. You are vastly underestimating the capabilities of Cocoa Touch and UIKit. And tell me, how many iterations will it take to reimplement something like reusable cells in UITableView with comparable efficiency in CSS and JS. > Plus the whole 30% cut You get a lot for that: including hosting, payment processing, automatic notification about upgrades and access to millions people with credit cards a click away from your app.
        nwienert 14y ago
        No matter, saying HTML5 tools are the "wild-west" was "wildly" inaccurate. On the UITable thing... the efficiency is the whole point of this article. Does you UITableView code compile directly to any other platform? As for implementing, from a quick google search it looks like it would be trivial. A one day project, if less. How long would it take you to RE-code it in cocoa from scratch without going off the original code? Also, see Enyo if you want an easily re-usable kit like that[1]. Not to mention tons of other ones. If anything that example works in favor of HTML being easy and open. [1] http://enyojs.com/sampler/ http://enyojs.com/sampler/
        randomdata 14y ago
        I feel you may have completely missed my point about it being the wild west. Android, iOS, and many other mobile platforms provide a rich set of frameworks that solve much of the hard engineering challenges for you. HTML5 gives you a programming language or two and some rough system interfaces. By the time you are done your HTML5 app, it should be almost indistinguishable from a native app in terms of code, but you will have had to build many of those frameworks yourself; or, at best, extend one hundreds of competing frameworks that get you half way there but never all the way (again, unless you are doing something really simple). As mentioned, I do agree that this area does improve each day, and the time may come where it does meet, or even exceed, what the native platforms offer. In the meantime, however, you are going to be spending a portion of your development efforts being part of that improvement cycle instead of moving on to the next native platform. Six of one, half dozen of the other. Additionally, the reason I called it the wild west was in reference to the many HTML5 developers who choose to forego best practices altogether and program their app close to the "bare metal", doing only the bare minimum to get their app running. This provides a much shorter learning curve and quicker time to first product, which many non-native developers even consider a strong selling point of HTML5, but it sacrifices all of the lessons developers have learned over the past 30 years or so. Once upon a time, we used to program native applications that way too. Why sould we consider it a good idea now when it wasn't deemed a good idea back then?
  - scott_s 14y ago
    forcing users to upgrade their hardware to stay current I don't buy this argument. On my iPhone, the native apps perform great. It's the webpages I visit that sometimes cause slowdown. Yes, version of natives apps can come out that require an upgrade. But if an HTML5 application does not run well on current hardware, then a hardware update would be at least desired. In other words, I think it's an issue for both native and HTML5, which means it can't be used to distinguish the two.
- smsm42 14y ago
  It is a common pattern in "mythbusting": Myth: A is true Fact: In fact, B is true, and even though A is true too, it is because C, D, and E, and in case where conditions X, Y and Z are imposed, the effect of A being true can be reduced significantly. Also, it is unfair to say that A is true because A was also true many times before and M is also true sometimes which is better than A not being true. How it is "busting" any "myths" is a mystery to me, but journalists seem to love this pattern. Most use it gets in politics, especially near the elections, but popular journals on any topic love it too. Now Mozilla joins this venerable tradition.
btipling 14y ago
This article does not seem to be objective and honest. Yes you can monetize an HTML5 app, but there is a difference between can monetize and can monetize and actually make money. If you are going to criticize app stores, you might want to factor in the reality that Apple has paid out over 6 billion dollars to app developers. The article mentions phone gap, that's true, so that's fine, but I'm addressing the point about monetizing on the web. This article also is cherry picking news articles. It picks the Financial Time's article but doesn't mention Facebook's switch to native. The build once, run everywhere point is flawed as we know that you actually do have to test and add various fixes here and there and worry about screen size, poor development environments on mobile and the like. You also do not have to write the vast majority of your app more than once for multiple platforms. I know a featured developer with a game that has more than 7 million users who wrote their game in C++ and were able to port it to both Android and iOS without writing two different games. And really there are only two mobile platforms that users have to worry about, iOS and Android.
- marknutter 14y ago
  Without hard numbers on how easy it is to make a living off apps in the app store and apps on the web, all we're doing here is waving our hands. The few studies I've seen on the matter show that most of the app store income is concentrated into the hands of a select group of developers fortunate enough to have their apps featured in the top 10 for their category. http://www.kontain.com/plat4m/entries/98334/apps-dont-generate-profit-for-developers-the-great-app-bubble/ http://www.kontain.com/plat4m/entries/98334/apps-dont-genera...
- jgon 14y ago
  It also does something that always pisses me off when I see it in HTML5 boosterism, which is claim that HTML and Javascript are plenty performant, and hey look at this demo as proof! The problem is that the demo is always of a game that would have been impressive over a decade ago! I mean look at the wipeout clone they show a video of! The demo consists of a clone of a game that ran on a PS1 with 33mhz MIPS processor! And the PS1 version appears to have great complexity in its scenery! The only difference is the increased resolution of the Mozilla demo. Now all it takes is a quad-core I7 with 8GB of RAM and the latest Nvidia card to get the exact same experience with a higher-resolution. Take that people who are unimpressed by HTML5! https://www.youtube.com/watch?v=KRSVrkzDyuA https://www.youtube.com/watch?v=KRSVrkzDyuA Javascript and the web are technologies that are popular by virtue of their incredible reach, and not because of the skill and care that have gone into their design. I would really like to Mozilla and other concerned parties spend a lot more time dealing with the glaring deficiencies of the web than trying to convince me they don't exist.
old-gregg 14y ago
Interesting, when I look at the given "Things HTML5 can do that native Apps can not", I notice that those things are important to developers, not to the end users. End users do not care about "write once deploy everywhere". But they do care about the responsiveness, battery life, native look and feel, etc So far HTML5 apps are following the trajectory of "Java on a desktop".
- azakai 14y ago
  > End users do not care about "write once deploy everywhere" No, end users greatly care about that. They want to access their apps on all their devices, and to be able to buy a new device and use their apps on it. Just like they want to access their movies and music on all their devices. To them, apps and media are content and the computer/tablet/game console should just let them access it.
  - GHFigs 14y ago
    You're implicitly referring to the subset of end users that have chosen or would like to choose devices from incompatible ecosystems. I suspect this set of users is relatively small, given that it excludes what seems like the most common case: people that are satisfied with the platform they're on. I don't know that there are a lot of Android users (for example) that are eager to buy iOS devices but hesitate because they won't be able to use their existing apps.
    - nwienert 14y ago
      I think you're wrong. Especially going forward, how about apps that run on your TV, your tablet, your phone, your computer, etc. Want a chromebook? Runs there. On a friends phone? Load it there. What happens if a platform dies out? Or another becomes significantly more attractive to you because they release a poor maps application? What if you want a cheap tablet for your kids? There's a ridiculous amount of use cases that do matter to most people. The reason you're happy with your platform is actually because they've locked you into it. If another closed platform came around with all the new desirable apps, you'd be unhappy for the same reason you're happy about it now.
frozenport 14y ago
Internet based HTML5 has an intrinsic latency due to the connection with the server. Therefore the bottleneck for performance is not cpu but rather network latency., his makes much of the discussion concerning tailed suite moot, because the real issue is data delay and not code generation optimization. Lastly performance comparisons between Java and javascript hint that portability of code is not the bottleneck: because Java is much faster than javascript while still being portable.
- azakai 14y ago
  > Internet based HTML5 has an intrinsic latency due to the connection with the server. For first load, sure, just like it takes time to download and install an app. But you can then access HTML5 sites again quickly if you store data locally (using IndexedDB for example).
darkmarmot 14y ago
So, to demonstrate the awesomeness that is HTML5, they show a video of HTML5 rendered in Flash?
pootch 14y ago
I love the "cost of porting to other platforms" argument. I'd like to replace it with the "cost of delivering mushy web applications to customers who expect more". That cost is infinite, and you'll never get it back.
tonygrue 14y ago
Also amusing, WebGL is provided as an example of why perf is good, but is it really part of HTML5? The assumption that it is appears to be another myth. http://www.w3.org/TR/html5/ http://www.w3.org/TR/html5/ http://stackoverflow.com/questions/10185554/is-webgl-part-of-the-html5-specification http://stackoverflow.com/questions/10185554/is-webgl-part-of...
kombine 14y ago
> HTML5, on the other hand by its very definition is a web technology that should run independent of environment, display or technology. That's a false dichotomy all the way through. Why "web" apps have this advantage "by definition"? "Web" means network. Nothing more. That has nothing to do with its independence of environment. Actually, independence is also a false statement. Web apps are in fact very much dependant on the environment they run in - the browser. To the point that you can't do anything outside of what the browser allows you to. Then also this trait is not unique to HTML apps - Java and .NET are exactly the same, just an order of magnitude more powerful.
NinjaWarrior 14y ago
HTML5 means that some elite browser developers enjoy fun and performance native coding and they allow us to use only crappy HTML/CSS/JavaScript (altjs languages and Emscripten can't compensate, of course). I suspect Mozilla guys regard themselves as privileged classes or something. As a programmer, the freedom of programming languages and APIs is more important than Apple tax. I sometimes imagine a catastrophic future. They say all programmers will write software only on the browsers. Then, all programmers will forget how to write C++, and no one will be able to maintain browsers eventually :p IMO, the easiest way to prove HTML5 is a prison rather than open will be jailbreaking Firefox OS phones.

111 points by caludio 14y ago

Most of these don't seem like "myths" so much as "uncomfortable realities". It's not a myth that native apps are faster because they get preferential access to the hardware, for instance, it's just a fact.

marknutter 14y ago
There are "uncomfortable realities" associated with native development as well, such as the cost of porting to other platforms, forcing users to upgrade their hardware to stay current, app discoverability issues, etc.
- randomdata 14y ago
  - the cost of porting to other platforms On the other hand, while it is rapidly getting better, the tooling for HTML5 apps are still generally the wild west. You can hack together an HTML5 app in no time, but unless you are doing something that is completely bog standard, by the time you properly engineer your HTML5 app, you probably could have delivered on two or three native platforms. - forcing users to upgrade their hardware to stay current If your app needs something from newer hardware to function properly (more processing power, new I/O devices, etc.), how does HTML5 alleviate that problem? If you mean forcing users to upgrade their operating systems (which is sometimes dictated by the hardware) for new features, I'll note that the browsers/HTML5 rendering systems are generally part of that upgrade, still requiring said upgrade to use those features in HTML5. - app discoverability issues Given that a native mobile app can use all of the same marketing tools a web app has, plus the vendor's app marketplace, couldn't it be said that native apps have better discoverability?
  - nwienert 14y ago
    - the cost of porting to other platforms Where in mobile can you live-debug an application both visually and functionally like you can with Web Inspector? I mean literally you are coding and debugging your app at the same time. And with LiveReload you don't even leave your editor to see your code changes instantly. Not to mention you are coding in JavaScript and CSS so the time it takes to iterate between various solutions is a fraction of the time of Objective C or Java. I think you have your first point backwards. There may not be an equivalent IDE, but we have a runtime inspector/editor baked into our runtime platform. You can't beat that. - forcing users to upgrade their hardware to stay current On Android you can update your default browser through the app store. - app discoverability issues Perhaps, but then again your app could just be rejected/removed at any time. Plus the whole 30% cut, time to release, limited sales options, etc. You're not in control of your app.
    - rimantas 14y ago
      > Where in mobile can you live-debug an application both > visually and functionally like you can with Web > Inspector? Visually? Interface builder in Xcode. Functionally? Instrumenta, lldb. > coding in JavaScript and CSS so the time it takes to > iterate between various solutions is a fraction of the > time of Objective C or Java. You are vastly underestimating the capabilities of Cocoa Touch and UIKit. And tell me, how many iterations will it take to reimplement something like reusable cells in UITableView with comparable efficiency in CSS and JS. > Plus the whole 30% cut You get a lot for that: including hosting, payment processing, automatic notification about upgrades and access to millions people with credit cards a click away from your app.
      - nwienert 14y ago
        No matter, saying HTML5 tools are the "wild-west" was "wildly" inaccurate. On the UITable thing... the efficiency is the whole point of this article. Does you UITableView code compile directly to any other platform? As for implementing, from a quick google search it looks like it would be trivial. A one day project, if less. How long would it take you to RE-code it in cocoa from scratch without going off the original code? Also, see Enyo if you want an easily re-usable kit like that[1]. Not to mention tons of other ones. If anything that example works in favor of HTML being easy and open. [1] http://enyojs.com/sampler/ http://enyojs.com/sampler/
        randomdata 14y ago
        I feel you may have completely missed my point about it being the wild west. Android, iOS, and many other mobile platforms provide a rich set of frameworks that solve much of the hard engineering challenges for you. HTML5 gives you a programming language or two and some rough system interfaces. By the time you are done your HTML5 app, it should be almost indistinguishable from a native app in terms of code, but you will have had to build many of those frameworks yourself; or, at best, extend one hundreds of competing frameworks that get you half way there but never all the way (again, unless you are doing something really simple). As mentioned, I do agree that this area does improve each day, and the time may come where it does meet, or even exceed, what the native platforms offer. In the meantime, however, you are going to be spending a portion of your development efforts being part of that improvement cycle instead of moving on to the next native platform. Six of one, half dozen of the other. Additionally, the reason I called it the wild west was in reference to the many HTML5 developers who choose to forego best practices altogether and program their app close to the "bare metal", doing only the bare minimum to get their app running. This provides a much shorter learning curve and quicker time to first product, which many non-native developers even consider a strong selling point of HTML5, but it sacrifices all of the lessons developers have learned over the past 30 years or so. Once upon a time, we used to program native applications that way too. Why sould we consider it a good idea now when it wasn't deemed a good idea back then?
- scott_s 14y ago
  forcing users to upgrade their hardware to stay current I don't buy this argument. On my iPhone, the native apps perform great. It's the webpages I visit that sometimes cause slowdown. Yes, version of natives apps can come out that require an upgrade. But if an HTML5 application does not run well on current hardware, then a hardware update would be at least desired. In other words, I think it's an issue for both native and HTML5, which means it can't be used to distinguish the two.
smsm42 14y ago
It is a common pattern in "mythbusting": Myth: A is true Fact: In fact, B is true, and even though A is true too, it is because C, D, and E, and in case where conditions X, Y and Z are imposed, the effect of A being true can be reduced significantly. Also, it is unfair to say that A is true because A was also true many times before and M is also true sometimes which is better than A not being true. How it is "busting" any "myths" is a mystery to me, but journalists seem to love this pattern. Most use it gets in politics, especially near the elections, but popular journals on any topic love it too. Now Mozilla joins this venerable tradition.

btipling 14y ago

This article does not seem to be objective and honest. Yes you can monetize an HTML5 app, but there is a difference between can monetize and can monetize and actually make money. If you are going to criticize app stores, you might want to factor in the reality that Apple has paid out over 6 billion dollars to app developers. The article mentions phone gap, that's true, so that's fine, but I'm addressing the point about monetizing on the web. This article also is cherry picking news articles. It picks the Financial Time's article but doesn't mention Facebook's switch to native. The build once, run everywhere point is flawed as we know that you actually do have to test and add various fixes here and there and worry about screen size, poor development environments on mobile and the like. You also do not have to write the vast majority of your app more than once for multiple platforms. I know a featured developer with a game that has more than 7 million users who wrote their game in C++ and were able to port it to both Android and iOS without writing two different games. And really there are only two mobile platforms that users have to worry about, iOS and Android.

marknutter 14y ago
Without hard numbers on how easy it is to make a living off apps in the app store and apps on the web, all we're doing here is waving our hands. The few studies I've seen on the matter show that most of the app store income is concentrated into the hands of a select group of developers fortunate enough to have their apps featured in the top 10 for their category. http://www.kontain.com/plat4m/entries/98334/apps-dont-generate-profit-for-developers-the-great-app-bubble/ http://www.kontain.com/plat4m/entries/98334/apps-dont-genera...
jgon 14y ago
It also does something that always pisses me off when I see it in HTML5 boosterism, which is claim that HTML and Javascript are plenty performant, and hey look at this demo as proof! The problem is that the demo is always of a game that would have been impressive over a decade ago! I mean look at the wipeout clone they show a video of! The demo consists of a clone of a game that ran on a PS1 with 33mhz MIPS processor! And the PS1 version appears to have great complexity in its scenery! The only difference is the increased resolution of the Mozilla demo. Now all it takes is a quad-core I7 with 8GB of RAM and the latest Nvidia card to get the exact same experience with a higher-resolution. Take that people who are unimpressed by HTML5! https://www.youtube.com/watch?v=KRSVrkzDyuA https://www.youtube.com/watch?v=KRSVrkzDyuA Javascript and the web are technologies that are popular by virtue of their incredible reach, and not because of the skill and care that have gone into their design. I would really like to Mozilla and other concerned parties spend a lot more time dealing with the glaring deficiencies of the web than trying to convince me they don't exist.

old-gregg 14y ago

Interesting, when I look at the given "Things HTML5 can do that native Apps can not", I notice that those things are important to developers, not to the end users. End users do not care about "write once deploy everywhere". But they do care about the responsiveness, battery life, native look and feel, etc So far HTML5 apps are following the trajectory of "Java on a desktop".

azakai 14y ago
> End users do not care about "write once deploy everywhere" No, end users greatly care about that. They want to access their apps on all their devices, and to be able to buy a new device and use their apps on it. Just like they want to access their movies and music on all their devices. To them, apps and media are content and the computer/tablet/game console should just let them access it.
- GHFigs 14y ago
  You're implicitly referring to the subset of end users that have chosen or would like to choose devices from incompatible ecosystems. I suspect this set of users is relatively small, given that it excludes what seems like the most common case: people that are satisfied with the platform they're on. I don't know that there are a lot of Android users (for example) that are eager to buy iOS devices but hesitate because they won't be able to use their existing apps.
  - nwienert 14y ago
    I think you're wrong. Especially going forward, how about apps that run on your TV, your tablet, your phone, your computer, etc. Want a chromebook? Runs there. On a friends phone? Load it there. What happens if a platform dies out? Or another becomes significantly more attractive to you because they release a poor maps application? What if you want a cheap tablet for your kids? There's a ridiculous amount of use cases that do matter to most people. The reason you're happy with your platform is actually because they've locked you into it. If another closed platform came around with all the new desirable apps, you'd be unhappy for the same reason you're happy about it now.

frozenport 14y ago

Internet based HTML5 has an intrinsic latency due to the connection with the server. Therefore the bottleneck for performance is not cpu but rather network latency., his makes much of the discussion concerning tailed suite moot, because the real issue is data delay and not code generation optimization. Lastly performance comparisons between Java and javascript hint that portability of code is not the bottleneck: because Java is much faster than javascript while still being portable.

azakai 14y ago
> Internet based HTML5 has an intrinsic latency due to the connection with the server. For first load, sure, just like it takes time to download and install an app. But you can then access HTML5 sites again quickly if you store data locally (using IndexedDB for example).

darkmarmot 14y ago

So, to demonstrate the awesomeness that is HTML5, they show a video of HTML5 rendered in Flash?

pootch 14y ago

I love the "cost of porting to other platforms" argument. I'd like to replace it with the "cost of delivering mushy web applications to customers who expect more". That cost is infinite, and you'll never get it back.

tonygrue 14y ago

Also amusing, WebGL is provided as an example of why perf is good, but is it really part of HTML5? The assumption that it is appears to be another myth. http://www.w3.org/TR/html5/ http://www.w3.org/TR/html5/ http://stackoverflow.com/questions/10185554/is-webgl-part-of-the-html5-specification http://stackoverflow.com/questions/10185554/is-webgl-part-of...

kombine 14y ago

> HTML5, on the other hand by its very definition is a web technology that should run independent of environment, display or technology. That's a false dichotomy all the way through. Why "web" apps have this advantage "by definition"? "Web" means network. Nothing more. That has nothing to do with its independence of environment. Actually, independence is also a false statement. Web apps are in fact very much dependant on the environment they run in - the browser. To the point that you can't do anything outside of what the browser allows you to. Then also this trait is not unique to HTML apps - Java and .NET are exactly the same, just an order of magnitude more powerful.

NinjaWarrior 14y ago

HTML5 means that some elite browser developers enjoy fun and performance native coding and they allow us to use only crappy HTML/CSS/JavaScript (altjs languages and Emscripten can't compensate, of course). I suspect Mozilla guys regard themselves as privileged classes or something. As a programmer, the freedom of programming languages and APIs is more important than Apple tax. I sometimes imagine a catastrophic future. They say all programmers will write software only on the browsers. Then, all programmers will forget how to write C++, and no one will be able to maintain browsers eventually :p IMO, the easiest way to prove HTML5 is a prison rather than open will be jailbreaking Firefox OS phones.