HTML5 mythbusting

The ongoing discussion about the “readiness” of HTML5 is based on a lot of false assumptions. These lead to myths about HTML5 that get uttered once and then continuously repeated – a lot of times without checking their validity at all.

HTML5 doesn’t perform?

The big thing everybody who wants to talk about the problems with HTML5 is performance. The main problem here is that almost every single comparison misses the fact that you are comparing apples and pears (no pun intended).

Comparing an HTML5 application’s performance with a native App is comparing a tailored suit with one bought in a shop. Of course the tailored suit will fit you like a glove and looks amazing but if you ever want to sell it or hand it over to someone else you are out of luck. It will not be the same for the next person.

That is what native Apps are – they are built and optimized for one single environment and purpose and are fixed in their state – more on that later.

HTML5, on the other hand by its very definition is a web technology that should run independent of environment, display or technology. It has to be as flexible as possible in order to be a success on the web. In its very definition the web is for everybody, not just for a small group of lucky people who can afford a very expensive piece of hardware and are happy to get locked into a fixed environment governed by a single company.

Native applications need to be written for every single device and every new platform from scratch whereas an HTML5 App allows you to support mobiles, tablets and desktops with the same product. Instead of having fixed dimensions and functionality an HTML5 App can test what is supported and improve the experience for people on faster and newer devices whilst not locking out others that can not buy yet another phone.

Native Apps on the other hand do in a lot of cases need an upgrade and force the end user to buy new hardware or they’ll not get the product at all. From a flexibility point of view, HTML5 Apps perform admirably whilst native applications make you dependent on your hardware and leave you stranded when there is an upgrade you can’t afford or don’t want to make. A great example of this is the current switch from Apple to their own maps on iOS. Many end users are unhappy and would prefer to keep using Google Maps but can not.

HexGL – a WebGL powered racing game

Seeing that HTML5 is perfectly capable on Desktop to exceed in performance, from scrolling performance to analyzing and changing video on the fly up to running full 3D games at a very high frame rate and have high speed racing games we have to ask ourselves where the problem with its performance lies.

The answer is hardware access. HTML5 applications are treated by mobile hardware developed for iOS and Android as second class citizens and don’t get access to the parts that allow for peak performance. A web view in iOS is hindered by the operating system to perform as fast as a native App although it uses the same principles. On Android both Chrome and Firefox show how fast browsers can perform whereas the stock browser crawls along in comparison.

The stock browser on Android reminds us of the Internet Explorer of the 90s which threatened to be set in stone for a long time and hinder the world wide web from evolving – the very reason Mozilla and Firefox came into existence.

In essence HTML5 is a Formula 1 car that has to drive on a dirt road whilst dragging a lot of extra payload given to it by the operating system without a chance to work around that – for now.

HTML5 can not be monetized?

HTML5 is a technology stack based on open web technologies. Saying that HTML5 has no monetization model is like saying the web can not be monetized (which is especially ironic when this is written on news sites that show ads).

Whilst on the first glance a closed App-market is a simple way to sell your products there is a lot of hype about their success and in reality not many developers manage to make a living with a single app on closed App markets. As discovery and find-ability is getting increasingly harder in App markets a lot of developers don’t build one App but hundreds of the same App (talking dog, talking cat, talking donkey…) as it is all about being found quickly and being on the first page of search results in the market.

This is where closed App markets with native Apps are a real disadvantage for developers: Apps don’t have an address on the web (URL) and can not be found outside the market. You need to manually submit each of the Apps in each of the markets, abide to their review and submission process and can not update your App easily without suffering outages in your offering.

An HTML5 App is on the web and has a URL, it can also get packaged up with products like Adobe PhoneGap to become a native application for iOS or Android. The other way around is not possible.

In the long term that begs the question what is the better strategy for developers: betting on one closed environment that can pull your product any time it wants or distributing over a world-wide, open distribution network and cover the closed shops as well?

Many apps in the Android and iOS store are actually HTML5 and got converted using PhoneGap. The biggest story about this was the Financial Times releasing their app as HTML5 and making a better profit than with the native one. And more recently the New York Times announced it was following suit with its Web app.

HTML5 can not be offline?

As HTML5 is a web technology stack the knee-jerk reaction is thinking that you would have to be online all the time to use them. This is plain wrong. There are many ways to store content offline in a HTML5 application. The simplest way is the Web Storage API which is supported across all modern browsers (excluding Opera mini which is a special case as it sends content via a cloud service and has its own storage tools). You can also store the application itself offline using AppCache which is supported by all but Internet Explorer. If you have more complex data to store than Web Storage provides you can use either IndexedDB (for Chrome and Firefox) or WebSQL (for iOS and Safari). To work around the issues there are libraries like Lawnchair available to make it easy for developers to use.

HTML5 has no development environment?

One concern often mentioned is that HTML5 lacks in tooling for developers. Strangely enough you never hear that argument from developers but from people who want to buy software to make their developers more effective instead of letting them decide what makes them effective.

HTML5 development at its core is web development and there is a quite amazingly practical development environment for that available. Again, the main issue is a misunderstanding of the web. You do not build a product that looks and performs the same everywhere – this would rob the web of its core strengths. You build a product that works for everybody and excels on a target platform. Therefore your development environment is a set of tools, not a single one doing everything for you. Depending on what you build you choose to use many of them or just one.

The very success of the web as a media is based on the fact that you do not need to be a developer to put content out – you can use a blogging platform, a CMS or even a simple text editor that comes with your operating system to start your first HTML page. As you progress in your career as a developer you find more and more tools you like and get comfortable and effective with but there is no one tool to rule them all. Some developers prefer IDEs like Visual Studio, or Eclipse. Others want a WYSIWYG style editor like Dreamweaver but the largest part of web developers will have a text editor or other of some sorts. From Sublime Text, Notepad++ up to VIM or emacs on a Linux computer, all of these are tools that can be used and are used by millions of developers daily to build web content.

When it comes to debugging and testing web developers are lucky these days as the piece of software our end users have to see what we build – the browser – is also the debugging and testing environment. Starting with Firefox having Firebug as an add-on to see changes live and change things on the fly, followed by Opera’s Dragonfly and Safari and Chrome’s Devtools, all browsers now also have a lot of functionality that is there especially for developers. Firefox’s new developer tools go even further and instead of simply being a debugging environment are a set of tools in themselves that developers can extend to their needs.

Remote debugging is another option we have now. This means we can as developers change applications running on a phone on our development computers instead of having to write them, send them to the phone, install them, test them, find a mistake and repeat. This speeds up development time significantly.

Remote debugging in Firefox

For the more visual developers Adobe lately released their Edge suite which brings WYSIWYG style development to HTML5, including drag and drop from Photoshop. Adobe’s Edge Inspect and PhoneGap makes it easy to test on several devices at once and send HTML5 Apps as packaged native Apps to iOS and Android.

In terms of deployment and packaging Google just released their Yeoman project which makes it dead easy for web developers to package and deploy their web products as applications with all the necessary steps to make them perform well.

All in all there is no fixed development environment for HTML5 as that would neuter the platform – this is the web, you can pick and choose what suits you most.

Things HTML5 can do that native Apps can not

In essence a lot of the myths of HTML5 are based on the fact that the comparison was between something explicitly built for the platform it was tested on versus something that is also supported on it. Like comparing the performance of speedboat and a hovercraft would result in the same predictable outcome. The more interesting question is what makes HTML5 great for developers and end users, that native applications can or do not do:

Write once, deploy anywhere – HTML5 can run in browsers, on tablets and desktops and you can convert it to native code to support iOS and Android. This is not possible the other way around.
Share over the web – as HTML5 apps have a URL they can be shared over the web and found when you search the web. You don’t need to go to a market place and find it amongst the crowded, limited space but the same tricks how to promote other web content apply. The more people like and link to your app, the easier it will be found.
Built on agreed, multi-vendor standards – HTML5 is a group effort of the companies that make the web what it is now, not a single vendor that can go into a direction you are not happy with
Millions of developers – everybody who built something for the web in the last years is ready to write apps. It is not a small, specialized community any longer
Consumption and development tool are the same thing – all you need to get started is a text editor and a browser
Small, atomic updates – if a native app needs an upgrade, the whole App needs to get downloaded again (new level of Angry Birds? Here are 23MB over your 3G connection). HTML5 apps can download data as needed and store it offline, thus making updates much less painful.
Simple functionality upgrade – native apps need to ask you for access to hardware when you install them and can not change later on which is why every app asks for access to everything upfront (which of course is a privacy/security risk). An HTML5 app can ask for access to hardware and data on demand without needing an update or re-installation.
Adaptation to the environment – an HTML5 app can use responsive design to give the best experience for the environment without having to change the code. You can switch from Desktop to mobile to tablet seamlessly without having to install a different App on each.

Let’s see native Apps do that.

Breaking the hardware lockout and making monetization easier

The main reason why HTML5 is not the obvious choice for developers now is the above mentioned lockout when it comes to hardware. An iOS device does not allow different browser engines and does not allow HTML5 to access the camera, the address book, vibration, the phone or text messaging. In other words, everything that makes a mobile device interesting for developers and very necessary functionality for Apps.

To work around this issue, Mozilla and a few others have created a set of APIs to define access to these in a standardized way called Web APIs. This allows every browser out there to get access to the hardware in a secure way and breaks the lockout.

The first environment to implement these is the Firefox OS with devices being shipped next year. Using a Firefox OS phone you can build applications that have the same access to hardware native applications have. Developers have direct access to the hardware and thus can build much faster and – more importantly – much smaller Apps. For the end user the benefit is that the devices will be much cheaper and Firefox OS can run on very low specification hardware that can for example not be upgraded to the newest Android.

In terms of monetization Mozilla is working on their own marketplace for HTML5 Apps which will not only allow HTML5 Apps to be submitted but also to be discovered on the web with a simple search. To make it easier for end users to buy applications we partner with mobile providers to allow for billing to the mobile contract. This allows end users without a credit card to also buy Apps and join the mobile web revolution.

How far is HTML5?

All in all HTML5 is going leaps and bounds to be a very interesting and reliable platform for app developers. The main barriers we have to remove is the hardware access and with the WebAPI work and systems like PhoneGap to get us access these are much less of a stopper than we anticipated.

The benefits of HTML5 over native apps mentioned above should be reason enough for developers to get involved and start with HTML5 instead of spending their time building a different code base for each platform. If all you want to support is one special platform you don’t need to go that way, but then it is also pointless to blame HTML5 issues for your decision.

HTML5 development is independent of platform and browser. If you don’t embrace that idea you limit its potential. Historically closed platforms came and went and the web is still going strong and allows you to reach millions of users world-wide and allows you to start developing without asking anyone for permission or having to install a complex development environment. This was and is the main reason why people start working with the web. And nobody is locked out, so have a go.

Evangelist for HTML5 and open web. Let's fix this!

124 comments

Ollie Wells

This is a refreshing article to see amidst all the “Native vs HTML5” posts out there.

This is prob the first that categorically shows what HTML5 is very good at and why in certain circumstances it can stand up to native apps… but at the same time not pretending HTML5 are the “new” native app.

Nice one.

November 1st, 2012 at 07:43
Joe

This is all great and good, but the problem isn’t necessarily what was mentioned in this article.

HTML5 doesn’t extend HTML4 well at all. It shouldn’t be called HTML anymore if it’s not extensible. I’d like to have seen better compatibility between the language versions. It’s like HTML5 is a different entity. It might as well be a version of XML made for the web.

Also, how does XHTML relate to HTML5?

November 1st, 2012 at 08:49
1. Chris Heilmann
  
  Joe you answered your own question: XHTML was XML for the web and thus not feasible as any error would have stopped the page from rendering at all. XHTML was never an option, mostly because IE6 never showed it when you rightfully declared it as XML. HTML5 was a complete reboot of markup for the web and its main principle was backwards compatibility instead of locking users out. I agree that semantically we failed to make it much better, but I don’t get where you are going with “it isn’t extensible”. HTML4.01 was never either…
  
  November 1st, 2012 at 09:10
  1. Joe
    
    Hmmmm, interesting. Thanks for the reply Chris. Well that makes sense in terms of XHTML vs HTML. I guess I just don’t like how much HTML5 deviates from HTML4. I don’t disagree that it’s better and a whole lot smarter, I just feel like we were on a certain path for semantic language and associations and HTML5 is so different.
    
    Maybe I have a problem with change. I hope not, otherwise that’ll mean I’m getting old.
    
    November 1st, 2012 at 12:54
    1. David
      
      HTML5 deviates from HTML4? How so? As far as browsers are concerned, there’s really only two rendering modes: strict and quirks. Whether you call it HTML5 or HTML4 is meaningless. All that matters is the doctype, and all that does is set the rendering mode.
      
      As for the article, Firefox performance is crap on Linux. Deploy once, run everywhere is (sometimes) technically true, but UX is often terrible. It’s more like “Deploy once, run on Windows and Mac, but forget about Linux or Mobile”. There’s also the old elephant in the room that is IE6-8… They’re not going away any time soon. Maybe in another two years we’ll be able to put IE8 to bed, but we’ve been saying that about IE6 for the past 5 years…
      
      November 1st, 2012 at 17:40
      1. Robert O’Callahan
        
        Do you have a specific issue with Firefox performance on Linux? It’s a bit hard to address your comment otherwise.
        
        November 2nd, 2012 at 02:34
      2. David
        
        @Robert,
        
        I had abit of a play today to try to find why Firefox feels slow in Linux. I think I’ve now found what’s been bugging me. It’s scrolling with a mousewheel in FF on Linux that feels slow. When you use the mousewheel, scrolling lags a bit, and stutters compared to using the scrollbar. Not a typical site, but one that shows the issue is http://2011.beercamp.com. Ignore the clipping and layering issues, and only look at how smooth the scrolling is.
        
        Scrolling using the scrollbar on Linux is relatively smooth. Not as snappy as Chrome, but still quite good.
        
        When scrolling using the mousewheel, it stutters a lot. I tried turning off smooth scroll, which makes things a little better, but still not great.
        
        On Windows, it scrolls just fine with either the mousewheel or scrollbar and smooth-scroll enabled.
        
        Note that I tried these sites on 1 year old Core i7 machines. Two years ago, I had an HP Core 2 Duo laptop running Ubuntu and an old IBM ThinkPad (yes, *that* old) running Windows. Scrolling in Firefox was faster and smoother on the IBM than on the HP.
        
        November 4th, 2012 at 20:40
mpmedia

Great article.
However the “write once deploy everywhere” is not always true. especially on mobile , especially when you try to write games for devices. performance is not there on devices too. If UX really matters , then going native is still the way to go, because it will always be a lot more faster than anything written in js/html.
front-end tend to write code for webkit first for instance , because it is common to google and apple devices. then make quick fixes for other plateforms. HTML5 is great but is it not a silver bullet. It is a standard , it is important but you cant make people think writting HTML5 will be easier than writing Java or Obj-C, these languages come with a lot of batteries HTML5 doesnt provide.

November 1st, 2012 at 09:05
1. Chris Heilmann
  
  Agreed. This is covered in the article though – the issue is not the language but the performance of web views on those devices. If that were not an issue any longer it wouldn’t matter what language you write in. Right now especially for gaming on mobiles the hardware lockout makes it impossible to have performance parity. On the desktop companies get sued for that kind of thing :)
  
  November 1st, 2012 at 09:13
  1. Eelis
    
    If you use Emscripten to compile C/C++ to Javascript, as was done for BananaBread, the result is 3 or 4 times slower than if you’d compile it to native code (according to the Emscripten FAQ). So it seems to me that the performance problems with Javascript based web apps run a lot deeper than just unoptimized web views.
    
    November 1st, 2012 at 12:16
    1. Chris Heilmann
      
      Not an expert there, but I wouldn’t be surprised if this is part of the conversion process. Conversion is meant as a quick way to re-use, not optimised JS.
      
      November 1st, 2012 at 14:01
    2. Justin McCandless
      
      The result of the compilation to Javascript will then have to run in a webview and suffer from the hardware lockout, while the result of the compilation to native code will run uninhibited as a native app. I’m not familiar with Emscripten, but I don’t think the fact that your Javascript/native code was compiled from C lets you makes any new comparison here, if I understand you correctly.
      
      November 1st, 2012 at 23:16
      1. Eelis
        
        The 3-4 Emscripten slowdown isn’t due to “hardware lockouts”, it’s due to the fact that LLVM IR is much lower level than Javascript, which means that if you compile LLVM IR to Javascript, efficient low level operations (like raw memory access) are translated into far less efficient high level operations (like accessing a Javascript array that models raw memory).
        
        Hence, it is not the case that if only the hardware lockouts were gone and the webviews were optimized, it would no longer matter what language you use. Even if the hardware lockouts are gone and the webviews are optimized, it /will/ still matter what language you use, because anything other than Javascript will have to be compiled to Javascript, and due to the nature of Javascript, for a lot of performance-oriented languages, that means a *severe* slowdown.
        
        November 2nd, 2012 at 08:20
Fabian

While a lot of that is true, sadly there is no usable way to debug what’s going on in a web view. Things like Weinre are a last resort for the desperate, it doesn’t really count.

November 1st, 2012 at 10:15
1. Chris Heilmann
  
  True, again the ball is in the court of the OS developers there :(
  
  November 1st, 2012 at 10:31
NinjaWarrior1976

> Native applications need to be written for every single device and every new platform from scratch

You can make native apps portable. Just like you are doing on Firefox. I stopped reading seriously here.

Please stop writing crappy articles like this. Prove the performance of web platform by implementation, not by words. Please.

November 1st, 2012 at 11:01
we

“True, again the ball is in the court of the OS developers there :(”

lol, but your whole point it’s not device/os dependent… FAIL. Also – majority of the apps only target OS and not specific architecture (also – you have common framework that ease development of software for multiple OS). Not to mention that a lot of online ‘apps’ lacks funtionality, *REQUIRE* at least *SOME* connection (mostly rather bigger then smaller) and well… often run (well) only on chrome (and most of the time on Fx)… yay, it’s worse than Win/Mac/Linux trio…

November 1st, 2012 at 11:07
Michael

Great article. I used to work at Palm a few years ago and I remember how we built the entire WebOS on HTML5 from the ground and let developers have direct access to the hardware stack for building HTML5 apps. Hardware wasn’t quite ready yet so performance was a little bit of an issue until the later Palm Pre 2 release and iOS was already too embedded to gain market share. Hopefully Firefox OS will stand out.

November 1st, 2012 at 11:27
Bobby Newmark

The non-SSL URL for this post redirects to HTTPS, but the HTTPS page elicits a mixed content warning when the page is loaded. That is kind of annoying.

November 1st, 2012 at 11:32
Scott

Why is an HTML5 evangelist showing HTML5 demos using Flash videos? Is this a troll?

November 1st, 2012 at 13:16
1. Chris Heilmann
  
  No we call it YouTube. It shows as html5 video here… also: http://www.zeldman.com/2011/11/18/it-is-not-ironic/
  
  November 1st, 2012 at 13:25
2. Pluto
  
  Just because you don’t have HTML5 turned on through Youtube, doesn’t mean anyone else doesn’t. https://www.youtube.com/html5
  
  November 3rd, 2012 at 14:11
pjmlp

You forgot:

– write once, debug everywhere.

November 1st, 2012 at 13:45
1. Chris Heilmann
  
  Write progressively, only debug where you need. How’s that?
  
  November 1st, 2012 at 13:55
  1. Haakon Løtveit
    
    «Yeah, your application doesn’t work, but since you use Linux/OSX/Windows XP we won’t fix it, because you don’t use Windows 7 and IE 9 or newer.»
    
    That’s pretty much how it sounds.
    
    Although it’s probably not what you /meant/.
    
    November 2nd, 2012 at 06:39
2. Pluto
  
  It’s easier to download multiple browsers and test the same URL/web app than install multiple OS’s, run them, install the apps you want to test, and then test them.
  
  Don’t forget it’s even harder when you have to build an application and then copy that over into your other operating system to test it. Wouldn’t you say it’s easier to save a change to a text file (JavaScript, HTML, CSS, etc) that’s part of a web app and refresh the page?
  
  November 3rd, 2012 at 14:22
Achim Schlemmer

Chris, I only want to say thanks for this strong Plädoyer for independence. Strong, passionate.

November 1st, 2012 at 14:25
Luke

Chris,
Are you a programmer, or just Mozilla PR? I’ve done some testing myself with Banana Bread and as stated above, it was at least 4x slower than the native Cube 2 app running a simple map. Throw in complex geometry, and it was a good 10x slower.

Sure a high end PC can run a HTML5 Wipeout clone, like HexGL, as well as my 10 year old PS2. You still haven’t made your point that HTML5 is competitive with Native apps in term of performance. Farmville or PS2 level games yes, but good luck trying to build a modern game like BF3 level game using HTML5 tech.

November 1st, 2012 at 15:05
1. Chris Heilmann
  
  This was not my point to make. I’d be happy to let the emskripten and WebGL team of Mozilla take that challenge on. I don’t think we are close to 3D performance like you want to achieve on mobile devices in any technology (playing some games on my Nexus 7 and seeing how warm it gets and how fast my battery is drained shows me that). It is also not the point of this article – you can find other performance related posts about that here.
  
  November 1st, 2012 at 16:05
  1. Luke
    
    Chis what was your point? The title of the article is “HTML5 mythbusting – HTML5 doesn’t perform?” I reread your article and your points seemed to be that it performs “good enough” and that the only thing holding it back HTML5 performance was “the OS”.
    
    How can you claim to be “Myth busting” with such weak arguments? It’s like saying my Apple IIe’s graphics were good enough.
    
    And as far as OS being the limitation, now that’s just patently false. The OS is not holding firefox and HTML5 apps back. What’s holding them back is the VM that they run it. The Javascript VM itself takes a massive about of RAM, often 300Mb-1GB, and then has to spend precious CPU cycles converting this code to native. All of which results in a huge performance hit. Other HTML5 technology’s like CSS was never designed to be hardware accelerated. Take away the OS, and you’re still going to be running much slower than native apps because you can’t access the hardware’s features. It’s an issue with HTML5, NOT the OS, not the browser.
    
    So if battery performance and CPU usage concerns you, then you should stick to your Nexus 7 Native games or iOS game, because any HTML5 version of the same app will use an order of magnitude more CPU power to get the same results you are seeing.
    
    I want you guys to succeed. But you’ll do it by making high performance browers. We know what your platforms it capable of, and you’re nowhere near its full potential. Give me updates on electrolysis project. Then web apps can take advatange of more that one CPU core. Give us stuff like that, not this BS.
    
    November 1st, 2012 at 19:19
    1. Chris Heilmann
      
      The point of this article was to present a counterpoint to all the articles that make sweeping statements that HTML5 can not be offline, plainly doesn’t perform and can not be monetised. There are many out there and this is what analysts and journos read as they have no time to look into benchmark results and detailed technical setup discussions.
      
      The Nexus 7 example was with a native game… Again, we can optimise Firefox till the cows come home, but if it isn’t even _allowed_ to run on the OS (like it is in the case of iOS) then our WebAPI work and the performance work is not hitting the mark.
      
      The point here is to raise awareness that things _are_ possible, that the WebAPI work is under way and that it is not applied across browsers because of repeated arguments that “native is better anyways, so why bother”.
      
      The title was not mine – originally I called this “HTML5 myths and some solutions”.
      
      If you think there was no point to this, fine, but then step up and write something better, or step up when in other articles – read by executives and quoted by the press claims are being made about performance of browsers that are plain wrong. We are _damn_ good at shooting at each other with technical details but we are very much performing sub par when it comes to preventing from truisms about web technologies to go out. Want the best example of that: see the misquoting of Zuckerberg about why HTML5 was not a good choice for Facebook.
      
      November 2nd, 2012 at 01:17
      1. Luke
        
        You wrote a “Myth Buster” article, which I’m sure you knew would generate some controversy (and hits). Thank you for stepping up to address the issues people here had with it. Your points on offline use and monetization, I agree are dead on. If you had just said in your headline that HTML5 performance is good enough for casual games, you would have had no argument from me.
        
        I still don’t follow you how you go from your Nexus 7 to iOS being locked down? Your Nexus 7 is not only fully open source, but it’s also not locked down. You are free to load any piece of software you want. You don’t even need to use Google’s app store. You are free to install Amazon’s app store or even make your own Mozilla apps store. I had no issue downloading FF from Google Play and I don’t think Google places any restrictions on how you develop it, right? If you make a better browser than Chrome, people will use it.
        
        So that’s my challenge, just to make FF a leader of the pack again. JavaScript performance is getting much better with improvements like IonMonkey But, it’s 2012 and most new CPUs are 4, 6, 8, 12, even 16 cores which IE and Chrome both fully utilize. FF is still single threaded. You guys need to keep at the electrolysis project, so devs can access more than 1 core. Good luck!
        
        November 2nd, 2012 at 05:32
2. Ants Bull
  
  @Luke – wow, so because of your Strawman argument about BF3 not being possible in HTML5, that entirely invalidates every other HTML5 application out there?
  
  Did you bother to read the article at all? Triple-A games are, what, 0.0001% of the entire app market? Get a clue you genius……
  
  November 1st, 2012 at 16:45
  1. Luke
    
    Ants Bull, I said “modern games like BF3” NOT “every HTML5 application” In fact, I admitted, HTML5 was fine for “Farmville or PS2 type games”. Nice try with your Strawman argument, trying to change my premise :)
    
    Chris admitted they are “not close to 3D performance like I want to achieve” As someone who has spent quite a few hours evaluating the performance of 3D HMTL5 engines like Unigine and Banana Bread, I appreciate Chris’s honestly and willingness to discuss FF’s performance openly.
    
    November 2nd, 2012 at 05:14
bobx

This all sounds great, but its not really accurate. Ask any experienced web developer about write once deploy anywhere. Browsers themselves are a big problem…namely they suck for anything but basic document rendering. (and they are even very good at that). So I think this article is trying to convince me that the browser is a great development platform. Its not, its horrible, until its not I wont waste my time cutting HTML. There is simply no point.

November 1st, 2012 at 15:56
1. Chris Heilmann
  
  Then don’t. As stated in the article, if you don’t want to take on the challenge, don’t do it. But don’t blame the tech if you discard it from the get-go.
  
  November 1st, 2012 at 16:01
2. Jon H
  
  Bobx, I don’t think Chris was trying to say that HTML5 web app development is *easier* than native app development, because, well, it isn’t. I recently worked on a web app that had to work on iOS 5+, Android 2.3+ and BB6+ and it was a HUGE pain in the ass. There is a point to doing this because once a team of developers (in my case) gains extensive knowledge of all mobile web browser ins, outs and fragmentation, then the building of an app becomes a lot easier, therefore takes less time and is a more viable solution than building native apps for every single platform.
  
  As an experienced web app dev, I wholeheartedly agree with the points you make in this article, Chris. Nobody said this road was going to be easy, and if they did they were dead wrong.
  
  November 2nd, 2012 at 09:14
Ryan Brady

Um, no mention of flash?

I started reading this article and it started very well with “You can’t compare write-once multi platform languages with native ones” and was really excited because I thought I was in for a comparison of flash vs. HTML 5 performance. Cool.

ctrl + f flash, not found.

What?

Find and replace html5 with flash (or any other write-once platform such as HaXe) and most of this article still works… this is a HUGE hole in this article…

November 1st, 2012 at 16:54
1. Chris Heilmann
  
  You mean the Flash that doesn’t run on mobile devices – at all?
  
  November 2nd, 2012 at 01:18
  1. Andrew
    
    http://www.adobe.com/au/products/air.html
    
    “What is Adobe AIR?
    
    The Adobe® AIR® runtime enables developers to package the same code into native apps for iPhone, iPad, Kindle Fire, Nook Tablet, and other Android™ devices”
    
    November 2nd, 2012 at 01:51
    1. Robert O’Callahan
      
      I think everyone knows that Flash is going away on mobile first and then everywhere else.
      
      November 2nd, 2012 at 02:37
      1. Tomas
        
        So how could HTML5 compete well if it’s worse than other current technologies? How could it progress fast if there is more money in native technologies? HTML5 should in theory work well on mobile devices but it doesn’t at the moment. The response is also often “we have seen that in Flash years ago”.
        
        November 2nd, 2012 at 07:57
      2. Frank
        
        No Robert. The Flash Player is already gone from mobile browsers. Andrew is talking about AIR, which let’s you use Flash technology to build native apps for the app stores. There are already tons of Flash-based apps out there, some in the top charts. You might have a couple on your phone right now and not even know it.
        
        November 13th, 2012 at 13:36
  2. facebook_jonathan.hart.sf
    
    Chris,
    
    Adobe AIR allows Flash developers to take their codebase and run it natively on mobile devices. It supports Stage3D which is a wrapper to OpenGL and provides the same GPU access that WebGL would.
    
    So Flash developers don’t have a mobile browser plugin because they don’t need one. Mobile web is dead for applications, the app stores are here to stay. Adobe AIR gets Flash games in the app store quite handily.
    
    November 28th, 2012 at 12:34
Tony G

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://stackoverflow.com/questions/10185554/is-webgl-part-of-the-html5-specification

November 1st, 2012 at 18:32
1. Chris Heilmann
  
  Incredible, neither is CSS. Now make a great app without CSS.
  
  November 2nd, 2012 at 01:17
  1. notzed
    
    The last great app i made for android didn’t use CSS anywhere?
    
    November 3rd, 2012 at 16:59
  2. Joe
    
    I agree with Tony G.
    
    Chris it is unfair to compare WebGL with CSS, there are many reasons for that starting from CSS has been there since ’96 and WebGL is hardly used, but the most important is that CSS is part of the W3C standards and WebGL no, which would invalidate your whole point about “Built on agreed, multi-vendor standards”
    
    There are many HTML5 perf examples out there running at 60fps without having to use WebGL. For instance the ones created by the IE team http://ie.microsoft.com/testdrive/Views/SiteMap/
    
    I also don’t see the point saying IE does not support webcache or indexedDB when both are supported in the latest version.
    
    It’s sad to see that most of the points you use to reinforce using HTML5 are things that could be done with Flash or Java long time ago.
    
    You can do it better next time
    
    November 3rd, 2012 at 17:18
    1. Chris Heilmann
      
      Or you could – we need more people to tell the good stories about HTML5 without hyping it. I am confused about your comment – as far as I can see in the article I never even mentioned WebGL vs. CSS. My problem with the IE examples is that they run on a preview browser in a preview OS and on a browser that is only available on one OS. It is great that the performance there is amazing but I can’t even test that as I have no Windows machine.
      
      November 4th, 2012 at 03:45
  3. Antoine Bapst
    
    http://devblog.blackberry.com/2012/02/playbook-native-webgl-development/
    
    November 5th, 2012 at 06:14
2. Robert O’Callahan
  
  HTML5 is just a popular brand name for the entire Web-standards platform.
  
  November 2nd, 2012 at 02:38
3. jeff fall
  
  However, WebGL is not supported on any mobile device web browser…
  
  http://caniuse.com/#feat=webgl
  
  November 5th, 2012 at 16:14
  1. Robert Nyman
    
    Actually, WebGL has support in a few mobile web browsers.
    
    November 5th, 2012 at 16:25
    1. Chris Heilmann
      
      Including Firefox for Android… http://imgur.com/qIECB
      
      November 5th, 2012 at 16:32
      1. Ghaladen
        
        A very forward thinking developer got the idea of creating a native WebGL emulation layer using OpenGL on iOS. Granted this makes your WebGL app native and not a web app, but at least it’s a nice stop gap until Apple implements WebGL in Mobile Safari and make it not suck.
        
        https://github.com/phoboslab/Ejecta
        
        November 7th, 2012 at 10:15
4. Jonathan Hart
  
  Tony G is 100% right. WebGL is not HTML5. It’s a feature that must be applied to browsers outside of the HTML5 spec, and not really a valid tool an HTML5 advocate should be allowed to use.
  
  Besides that, Microsoft refuses to ever support it, so there goes 50% of your potential market right there. It doesn’t run in any mobile browsers and is against the shareholders’ interest at Apple to enable it in Safari. So your only hope is that Apple decides to cut into its app store sales by turning it on, and IE’s market share dwindle to something so low that you don’t want to reach out to those users anyway. That will take years. In the meantime, you can make a game like the one you posted above in AS3, and via Adobe AIR publish it to a Mac or PC desktop app, reach every web browser via Flash, iPhone, iPad, Android, Blackberry and even Samsung TV all using the same codebase..
  
  I think it’s obvious that developers, especially us game developers, are not in the business of making games like websites are made: spending half their time getting cross-browser compatibility issues corrected. Those days are done.
  
  November 28th, 2012 at 12:29
Luther Goh Lu Feng

One concern I have with HTML5 apps is that over a slow mobile connection, the time taken to load some of the assets and libraries can be quite substantial, which in turns affect usability experience tremendously.

I don’t believe there is a workaround for this except going hybrid or native, where there is only need for a one time download (or as many updates there are).

Also some features like WebRTC and web notifications are still not in mobile browsers yet afaik. So the UX is suboptimal IMHO when it comes to native push notifications.

November 1st, 2012 at 19:21
1. Robert O’Callahan
  
  Load time shouldn’t really be an issue. Assets aren’t any bigger for Web apps than native apps. The user is going to have to download them once in both cases. We have the technology (HTML5 application cache and IndexedDB) to make sure that they stick around and don’t have to be downloaded again.
  
  November 2nd, 2012 at 02:39
One size fits all

I find it ironic that top comment on reddit
mythbusting this mythbusting.

November 1st, 2012 at 19:38
Lori

Is it true that HTML5 only works if you have a fairly advanced graphic card?

FWIW, I see non-monetizability as a feature, not a bug :)

November 1st, 2012 at 20:14
1. Joey Martinez
  
  No, to use HTML5 all you need is a browser that supports it like Chrome or Firefox. However, if you want hardware acceleration to speed up performance, you’ll need a modern graphics card and the latest drivers.
  
  November 1st, 2012 at 20:29
Joey Martinez

I came here to read about progress being made in HTML5 or the browser. Instead all I find is fluff and finger pointing.
“HTML5 apps are treated as second class citizens and don’t get access to the parts that allow for peak performance” That’s because the HTML5 API’s don’t exist yet. As you rightly pointed out, when they do like GPS, they are often used.

Yes, in the mobile space WebGL is not yet, but despite all your hot air. WebGL app performs terribly compared to their native counterparts. So the consumers are better off with Native Apps.

And if you really want WebGL in the Moble space, what’s stopping you from implementing it in your Fennic browser? If the performance is really there,we’ll use it. Problems with Android? Fix them and share them with Google.
http://source.android.com/source/submit-patches.html

You got where you are today, by making the fastest, leanest, browser on the market. Don’t forget your roots

November 1st, 2012 at 20:26
1. Chris Heilmann
  
  And how can we make the best and fastest browser when the OS doesn’t allow any other VMs and browsers?
  
  November 2nd, 2012 at 01:05
  1. Joey Martinez
    
    Current JavaScript VMs are CPU and memory hogs. This is why people complain that the HTML5 Google Maps App runs much worse than its native counterpart. FF is still trailing the pack in Javascript performance. You’re own
    http://arewefastyet.com/
    Shows FF trailing Chrome in every benchmark. You want to “Bust some Performance Myths” Post an article with FF leading.
    
    Let’s say hardware gets faster and you improve your VMs performance to acceptable levels for mobile apps. What’s stopping us from using it in Android? The platform is open source, accepts outside patches, and does not lock down the default store or stop users from installing additional app stores.
    
    FF is out for the Android platform. But we don’t use it, because it slower than Chrome and actually supports LESS HTML5 features. You want direct hardware access. It’s yours for the taking with NDK.
    
    You complain about Apple iOS locking you out, well make them irreverent. Why not make a browsers so much faster and better, people chose open platforms like Android to run your browser? One of the main reasons people including myself bought iPhones originally was because it was the first phone to have decent mobile browser.
    
    But now there are choices, and I have had Android and WebOS phones.
    http://news.cnet.com/8301-13579_3-57542628-37/iphone-users-get-less-loyal/
    Stop complaining about iOS and give the consumers something better. If you build it, we will use it.
    
    November 2nd, 2012 at 12:33
Andrew Betts

Worth clarifying that the FT app doesn’t use Phonegap, which is kind of implied in the article. Otherwise, top stuff.

November 2nd, 2012 at 04:42
Vivien

I agree with you on most of what you said. HTML5 is the future. There’s just one little thing about it: offline doesn’t work. Well, basic feature works somehow but updates are just a right pain. Plus try to use a manifest file on other devices like nokia, blackberry or a < 2.3 android …? I can tell you my brain was dead carpet when I managed to get something working. Still getting weird behaviours every now and then… Real-life feedback.

November 2nd, 2012 at 05:39
Alex Bertram

Offline mode for HTML5 is currently a disaster: the split between IndexedDB and WebSql has created major headaches for developers like ourselves building industrial-strength HTML5 apps, and it’s getting worse:

In 2008, the Gears plugin allowed developers to build offline apps targeting all major browsers with a single, if imperfect API.

After Mozilla and Microsoft rejected the already-available WebSQL standard, we’re back to fragmentation.

Choose IndexedDB and loose IE, Safari, Opera, and iOS, IE10 will support indexeddb, but that’s years away for enterprise users. IndexedDB is also an order of magnitude more complex when trying do otherwise simple things like joins. (the inverse is not true– sqlite is a great key value store)

Choose WebSQL and no Firefox or IE10. The Gears plugin still provides a polyfill, if unsupported, means for building against sqlite in IE6-9.

Obstruction on standards is expected from Microsoft, but Mozilla’s contrarion stance on WebSQL is disappointing, and has set HTML5 back at least a few years.

:-(

November 2nd, 2012 at 05:40
1. Chris Heilmann
  
  You did see lawnchair linked in the article?
  
  November 2nd, 2012 at 08:15
  1. Alex Bertram
    
    I hadn’t seen it thanks. It’s true that if your app can work with a key value store, there are a number of libraries that abstract the differences between WebSQL and IndexedDB.
    
    Perhaps my most serious problem with IndexedDB itself: we have put a lot of work into ActivityInfo (www.activityinfo.org), an HTML5 app for use in humanitarian relief operations where connections are unreliable or just bad. We originally developed against WebSQL/Gears and take advantage of sqlite to do join and aggregations on user’s datasets, in the browser, offline. Reimplementing all of this with indexedb means that we now have to do alot of work that sqlite used to be doing for us. It’s a huge burden and for the moment we don’t support FireFox offline. To make matters worse, we will have to move the joining and aggregation to a worker thread to avoid bogging down the UI event loop, which adds another order of magnitude of complexity.
    
    Maybe our use case is not so common, but judging from the vitriol here: https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/#comments, I don’t think we’re alone.
    
    I think that there are many who would have appreciated Mozilla being more clear about the decision to throw WebSQL under the bus, and many developers who would like to see Firefox reconsider it. I will be the first to submit a pull request with a WebSql implementation for FireFox if there is an openness to incorporating it !
    
    November 2nd, 2012 at 09:34
Neil Carpenter

Really good article Chris, enjoyed that.

Pity about these negative comments though! I guess it goes with the subject territory here…

November 2nd, 2012 at 07:18
Willian Carvalho

First of all, I loved the article.
I can see the point of everybody`s comments and I do respect them.

Despite all of that, I believe that “HTML5” will become successful enough for everyone’s benefits, among other techs.
Not long ago (considering the whole history of mankind) we couldn’t think we could fly, drive vehicles, talk on phones, etc. Thanks to people whiling to believe and try to make things happen, these things are as trivial as breathing!

My point is, no matter how hard you think HTML5 can become reliable because of performance issues or whatever, it couldn’t hurt us to believe it can be true and good :)
A bunch of very exceptional people are working to make this happen, and I do support them!

November 2nd, 2012 at 09:35
Shawn

You raised the question, what is the best choice for developers, to bet on a closed platform, or the open web.

I would argue the best choice for developers is to make whatever money you can, while you can make it, and to not worry about 3-5years down the road and what the future holds.

Right now, 98% of the cash flows through the App Store. So as a developer, you need to be there, anything else is foolish.

In 3+ years we can re-evaluate the marketplace and see if HTML is now a respectable middleware with a reliable display layer and performance characteristics, but right now there’s little point in using it at all.

And if we’re being realistic, HTML’s warts will not heal in 3 years. A developer would be better served to try and find a middleware platform like Unity or Adobe AIR, to solve the App Store lockin “problem”, rather than to keep faith in Apple, MS and the W3.

November 2nd, 2012 at 10:03
Shawn

Also, I would argue that the real problem with performance is not hardware access, it’s the DOM.

If HTML wants to get serious about developing Apps, it needs to create an alternative to the bloated clugdy document object model, and create something that makes sense for applications, like an Application Object Model. This would use absolute positioning, and would focus on performance simplicaity, and consistency.

A reference implementation must exist, that all vendor’s must adhere to. This would finally give HTML developers what every other developer in the world has: A reliable and consistent display layer. Performance could be fixed much easier by shedding all the dead weight and cruft of the DOM.

November 2nd, 2012 at 11:06
1. Antoine Bapst
  
  @Shawn, you might be (very) interested by this :
  “All DOM manipulation occurs while the HTML fragment is not attached to the live DOM. This allows DOM manipulation to occur VERY, VERY, FAST and it does not incur any WebView layout computation until the entire fragment is inserted into the DOM. Layout computation during JavaScript DOM manipulation is one of the single most expensive operations that can slow down a Web based UI.
  
  Each screen you create is an HTML fragment that gets loaded into the application via AJAX to keep the size of the DOM small and memory usage to a minimum”
  https://github.com/blackberry/bbUI.js
  
  November 5th, 2012 at 07:55
mpmedia

Very interesting comments so far.
At the end , whatever the solution one choses , is how many customers you can reach on the plateformyou are developping on. And how much ROI you can get from that.
HTML5 is here to stay no matter what we think about it. By the way i did not see the link to your video on youtube “broken promises …” :
http://www.youtube.com/watch?v=Pi7PBR7SMqM&feature=g-user-u
awesome video

November 2nd, 2012 at 11:16
thinsoldier

My 2 cents.

90% of the non-google apps I’ve installed on my Nexus 7 do not do anything so graphically intense that performance would be an issue if they were built with web technologies.

80% of the non-google apps I’ve tried (and a few of the google apps!) are almost completely useless if I don’t have wifi access. They might as well have been web pages.

I’m new to android (and smart phone/touch screen devices in general) so a friend of mine gave me the names of a lot of apps he considered “must-have”. At least 30% of the apps in the list he gave me I could not find or could not be certain that what I installed was actually what he was talking about. That was the case when searching for them through the play store app.

I eventually got him to visit the play.google.com website and send me accurate urls to the exact apps he’s been talking about. This was initially quite difficult since he’s one of those people who still doesn’t comprehend the idea of the web address box.

The google play store app is $#!++¢. I haven’t used an iphone since the very first one but if itunes is any indication I expect the apple app store is just as horrible.

Long live the web.

November 2nd, 2012 at 17:52
Joe Y

I hate reading comments and seeing the pissing contest. Great article, really enjoyed the read.

November 2nd, 2012 at 21:24
Rob

Great post! You got one part wrong though, iOS 6 does allow HTML5 access to the camera for taking photos and video.

November 2nd, 2012 at 21:50
Paul

You can write flash stage3d hardware accelerated apps for all desktop browsers(including ie where there is no support for webgl) and compile same code as native application for desktop,iOs Android and even smart tv(lg support air 3.0 on 2012 models and samsung soon will do the same). Check new stage3d games like farmville 2 , Kings Road or incoming titles from ubisoft and many many others. Flash games are reaching next level and with new version oh flash virtual machine and actionscript 4, next year difference will be even bigger.
Flash is or will be dead as tool for making websites but for game development it is just much much better than html5.

November 3rd, 2012 at 06:12
ian

Call a spade a spade and string replace mostly all the “html5” with “javascript” in this article

November 3rd, 2012 at 07:20
1. Chris Heilmann
  
  HTML5 without JavaScript will not get you very far when it comes to building apps. They are a symbiosis.
  
  November 3rd, 2012 at 12:29
Guest

Well, i see their point.. but in many aspects these comments are out of proportion, for example this is not true at all:
“Native applications need to be written for every single device and every new platform from scratch whereas an HTML5 App allows you to support mobiles, tablets and desktops with the same product.”

I like web technologies, but like the article said, you can compare an apple with a pear, the above comment is a complete fallacy, lie, etc. And YES you could a built a native application for multi platforms and still be cheaper or same in terms of $$ to a webapp.

So PLEASE, don’t try to misguide the people!!!

November 3rd, 2012 at 12:18
notzed

Starting the response to your first myth by saying ‘yes it is slower’ is hardly a way to start a convincing argument. Who cares if it ‘could’ be faster, it simply isn’t, and it’s pretty easy to argue that the platform itself cannot be accelerated as much as alternatives because of some core ‘slow’ features like the document object model, and the dynamic nature of javascript itself. If after all the time and money wasted on trying to make it fast has failed so far, it might be time to employ Occam’s Razor and suggest it will just never be able to compete.

There are good reasons any old web page isn’t granted access to camera’s and the like – and they revolve around security. If ever there came a time that web pages were indistinguishable from installed applications it would make the web too dangerous to use.

This whole ‘write once run anywhere’ nonsense is simply garbage. Only if you’re running the latest browsers from a limited number of suppliers, on a very limited number of platforms, is this even close to true for complex applications – and even then one must deal with incompatibilities between each browser. It is harder to write a portable application for html5 than just re-writing it a few times (and/or recompiling the code) for each platform. And all you end up with after all that effort is a clunky and slow ‘web app’. One only has to compare some of the more complex applications like google maps or youtube to see how some of the most experienced and skilled developers still manage to fall well well short.

Please just stick to what the web is good at – delivering text and video with a few limited animations (don’t want the battery running out just reading text). Any more than that is just an impedance mismatch and will only lead to frustrated users and bald developers.

November 3rd, 2012 at 15:59
1. Chris Heilmann
  
  If we had applied that attitude towards the web platform in the past we would neither have images nor CSS. Judging a platform by its current state rather than trying to remove the barriers to make it better is giving up – or being someone who really doesn’t want something to succeed pretend to even think about it.
  
  When CSS transitions were only supported in Safari I considered them a toy. Now, a few months later they are a very simple way to enhance a feature to be smoother and safe to use in newer browsers whilst not overloading older environments and to replace a lot of JS that does not need to run. If you don’t want to be part of this then don’t stand in the way, we can happily co-exist.
  
  November 3rd, 2012 at 16:10
  1. notzed
    
    Strange thing to say – images were in the first version of HTML and pretty much why it took off in the first place.
    
    And since when is making a considered observation active obstruction?
    
    November 3rd, 2012 at 16:30
notzed

And just to elaborate on the point of portability – it would be ok if firefox was the only browser, and Mozilla could force users to upgrade to the latest version on every platform against their wish. But they aren’t and they can’t – there are other browsers from other vendors who also have their own business interests which are orthogonal to those of Mozilla. And there are platforms for which Mozilla will never create a firefox even if they could.

Without that control, Mozilla are at the whim of the other big three who don’t have any reason not to shut Mozilla out of the “app” pie.

Here’s a solution that Mozilla COULD control:

a) Develop a high level, high performance API which can be called easily and cleanly from Javascript which implements a lot of the functionality now scattered around in a bunch of terrible and incompatible libraries.

c) provide a COMPLETE and SUPPORTED and good quality javascript implementation that works on a wide variety of the competitors browsers.

b) optionally, implement this natively in firefox for better performance (and particularly on mobile: better resource use).

I’m talking core application support here: a consistent htmlrequest, a consistent json / xml parser, widgets and animation, graphics, etc. i.e. a proper application development toolkit.

Currently all an application developer has is a language, a crude presentation layer, and a bunch of disparate and random api’s which are incompatible between vendors. And then they need to resort to a bunch of random and disparate libraries to implement missing functionality and to try to hide those incompatibilities.

This extra stuff is simply not needed on any other competing `platform’ in order to just get a working application written.

November 3rd, 2012 at 16:25
Jeff Hammel

Comparing “native” apps with HTML5 apps via the tailored vs off-the-rack suit analogy I find misleading. While you support the contentions of my objection with subsequent arguments, HTML5 is a platform, just as the existing operating systems are a platform. You could, in theory, tailor HTML5 performance in the same way to existing HTML5 interpreters in the same way that “native” apps are tailored to the host OS. In practice no one does this, as the real point of HTML5 is interoperability. Perhaps my feelings about custom clothing bias my feelings about this, but I don’t think the analogy is quite apt. Rather, HTML5 is a different, and as it stands, more constrains in many respects, toolbox to how to build a suit.

November 3rd, 2012 at 18:22
Abe

“A great example of this is the current switch from Apple to their own maps on iOS. Many end users are unhappy and would prefer to keep using Google Maps but can not.”

Yes, I’m one of them. I want my Native Google Maps Back!
Chris,
Now I’m forced to use the HTML 5 Google Maps on my iPhone 4S, and it’s slow and the UI is terrible compared to the native version. Even the most basic feature, zooming is FUBAR’d. I’m really looking forward to Firefox OS. You won’t be like Apple, and will let me keep my Native Apps, right? Oh, wait….

November 3rd, 2012 at 18:23
1. Chris Heilmann
  
  Thanks for playing, but on Firefox OS HTML5 apps _are_ the native apps. That is the whole idea of it.
  
  November 4th, 2012 at 03:42
  1. Abe
    
    Chris,
    From a performance standpoint or UI standpoint, under no circumstances can you call any HTML5 app “Native”
    PC mag’s Technical Encyclopedia defines a Native Application as:
    An application designed to run in the computer environment (machine language and OS) being referenced. The term is used to contrast a native application with an interpreted one such as a Java application that is not native to a single platform.
    
    Some examples of Native Apps are all iOS apps or NDK Android apps (Note the N in NDK stands for Native). JavaScript is an Interpreted language. Firefox OS does not magically solve all of the inherent performance issues with interpreting JavaScript. In a performance myth busting article, calling it Native is disingenuous.
    
    Now you could say you were referring to the Native UI toolkit of a platform. Well, unless you make a FF OS HMTL5 toolkit, there is no way you can call it native, since it is not natively targeting a single platform.
    
    The performance and user experience of the HTML5 Google Maps is much worse than its Native counterparts on Android and iOS. FF isn’t going to provide a better UI tootlkit. FF OS won’t solve JavaScript’s poor performance. It just takes away the option of running a custom Native App, just like Apple did to us with iOS6.
    
    November 4th, 2012 at 16:26
Max Polk

WebGL really is part of HTML5 the way new words are spoken between people before they find their way into the dictionary. There’s a little lag before it is an official word, likewise for the well specified OpenGL ES 2.0 API that is returned with canvas.getContext(“webgl”) on modern browsers.

Waiting around until things are chiseled out in stone in an official spec is more like W3C vs letting vendors build as it evolves which is more like WhatWG (http://www.whatwg.org/). Group consensus and feedback within the community works well as vendors crank out early versions of HTML5 functionality that mature.

By the time the specification waves its wand of blessing over WebGL we will already be moving on to the next big thing.

November 4th, 2012 at 13:59
Wlad

It’s people like you – evangelist for a yet non-existant platform (or was the standard finalised yet?) that supposedly is a dev panacea, who helped to sideline and probably also kill a mature and very, very dev-friendly technology – flex. By overhyping something, that does NOT have comparable tooling and debugging options, let alone feature set, you created myths that stuck. (Myths like the video tag, which only brought back the pre-flash incompatibility issues. Or do all the browsers support all the codecs? Did they back when Jobs axed Flash? ) Now you are tasting your own medicine. And I for one, am grabbing a bucket of popcorn.

November 4th, 2012 at 16:01
1. Chris Heilmann
  
  Ah yes, I remember it well – what a glorious day. We sat in the evil underground lair of the society of people who want to give developers choice and freedom, the chairman was petting his white fluffy cat and shouted “KILL FLEX”, pressing a button on his polished metal desk. What a day. The plan was easy – add a mind-altering drug to the drinking water supply that will make people go crazy and buy products that are incredibly beautiful and alter the way we interact with machines forever but don’t run Flex – at all.
  
  November 5th, 2012 at 01:03
  1. wlad
    
    So the html5 myths are a product of the same evil plan? Or how do they come about? html5 is immature today, it was even more so when Jobs axed flash on iOS devices. Granted, it was more a business decision than anything else, but html5 zealots provided him with ammo to shoot at dissenters with. And with a receptive audience. html5 zealots are the reason Adobe massively cut effort put into Flex development. Because supposedly there’s a better alternative at hand. There isn’t and won’t be for quite a while.
    
    I didn’t say you did it, I just said your religious frenzy helped to create a mindset that lead to it. Moreover, it is hurting the RIA world (js libraries re-inventing what Flex has had for years and presenting it as the hot new stuff is both sad and irritating, clients demanding re-writes that won’t work properly but they heard that ‘it’s the future’ is at this point a waste of resources) and in the end the users.
    
    If a device doesn’t allow access to its resources, it essentially doesn’t run html5 either, so what is your selling point? With Flex you at least have Air, with performance way above wrapped html5 apps, yet its future is uncertain. Because some people keep pushing the non-existent inferior technology over and over again.
    
    November 5th, 2012 at 02:48
    1. Chris Heilmann
      
      As a very outspoken Atheist I resent you calling me a religious zealot over and over again. For someone who allegedly is in popcorn mode you seem really angry. What you call inferior technology I call the web and it has been around longer than anything you really seem to be annoyed about that people don’t love the way you do. we could turn your argument around the same way – maybe the web isn’t as far as a platform as people tried to replace it with closed technologies with short-term “better experiences” over and over again? I am very excited about what Adobe is doing right now and I have been publicly very outspoken about not repeating half-heartedly with HTML5 what the Flash community had achieved years ago. Hardliner arguments like yours stop that from happening. We could very much benefit from sharing the learnings across different platforms, instead we succumb to childish bickering and whining about people just not understanding that our pet tools were perfect and nobody ever needed anything else. I am tired of this, really tired. I love that Adobe’s new message is that HTML5 is the platform to support and that it does not mean _at all_ that Flash developers need to change and everything they did is for the bin.
      
      November 5th, 2012 at 03:56
      1. Antoine Bapst
        
        Amen.
        
        November 5th, 2012 at 04:22
      2. wlad
        
        I’m in a popcorn mode for myths destroying html5. I’m not in a popcorn for evangelists for a platform plagued with problems and immaturity that present it as a viable alternative thereby creating myths destroying a platform that is ahead of it.
        
        Zeal is what html5 is all about. It does not exist, but you believe in it so much and preach it.
        
        And by the way, you dislike me using religious analogy, yet call yourself an evangelist? Ironic.
        
        I’m all for evolution of the web, I’m all for additions to what the browsers offer and even more so for them being consistent in it. But in the area they are good at – presenting simple pages with some simple eye candy on top of them. That’s the web that has been around for long. When you try to advocate html5 as a platform for development of complex apps, that’s where you lose me. And even that would probably annoy me less than presenting html5 as a viable alternative three years ago, when we don’t have the standard, let alone consistent implementations, even today. People like you created myths the platform wasn’t able to live up to.
        
        Closed technologies, flash in particular, are what helped the web survive and thrive. Just look at how long this praised open source standardization takes and how the platform is suffering because of it.
        
        November 5th, 2012 at 04:56
      3. Antoine Bapst
        
        @Wlad : “[web] presenting simple pages with some simple eye candy on top of them”. We are obviously not living under the same rock … Are you talking about running a nuclear ? This won’t append neither on the web than mobile world. For the rest of 90% useful apps (I mean excluding games) you’ll certainly notice you can access them on the web and the user experience is actually better than in an app.
        It’s not about bright or complexity; it’s about usage.
        
        P.S : I’m no blind and understand that specific needs will require forever use of native or dedicated platforms. But what we can see is that these specific needs are tending to a very low percentage of interactive environments. Thanks to HTML5 enhancements.
        
        November 5th, 2012 at 05:28
      4. Antoine Bapst
        
        @wlad the main advantage of apps in mobile environment was to adapt layouts and functionalities to devices limitations, generally resulting in functional limitations. For us – web developers – it was nothing but a nightmare to figure how to manage it. Now, being it via HTML browsers (web) and engines (apps) we have the power to unite both worlds.
        I believe we will even gain some capabilities (direct calls, touch, device sensors, …) that will invert this situation.
        HTML5 will bring many web developers to the mobile environment and that’s probably why HTML5 will emerge as a massive standard, due to the increasing part of mobile web browsing. We’re talking about a legion of devs … and companies.
        
        November 5th, 2012 at 07:49
    2. Antoine Bapst
      
      “If a device doesn’t allow access to its resources[…]”
      BB10 does. Won’t be/stay alone for long.
      
      November 5th, 2012 at 04:21
      1. wlad
        
        “Won’t be like that for long”, “It’ll catch on very soon” is what html5 has been about for a few years. It’s the future. And always will be.
        
        November 5th, 2012 at 05:05
      2. wlad
        
        “and the user experience is actually better than in an app” – only if the app is a wrapped html5 one. Native apps have always better user experience than web pages, no matter the complexity of the data they work with. Because as long as you have native apps, the experience will not be consistent across them and webpages.
        
        November 5th, 2012 at 06:22
      3. Antoine Bapst
        
        @Wlad: it’s the present (or the very near future Q1 2013 for the general audience). BB10 actually allows you to access devices resources; the camera, being one “this_will_never_append” myth busted.
        
        November 5th, 2012 at 06:26
      4. Antoine Bapst
        
        [sorry posted in wrong post above]
        @wlad the main advantage of apps in mobile environment was to adapt layouts and functionalities to devices limitations, generally resulting in functional limitations. For us – web developers – it was nothing but a nightmare to figure how to manage it. Now, being it via HTML browsers (web) and engines (apps) we have the power to unite both worlds.
        I believe we will even gain some capabilities (direct calls, touch, device sensors, …) that will invert this situation.
        HTML5 will bring many web developers to the mobile environment and that’s probably why HTML5 will emerge as a massive standard, due to the increasing part of mobile web browsing. We’re talking about a legion of devs … and companies.
        
        November 5th, 2012 at 08:00
Antoine Bapst (

@Chris
Thaks for this insightful article.

While HTML5 is pending final specifications – and I understand we are on a Mozzilla website – it seems you omit one competitor in the race here.

RIM’s BB10 is massively HTML5 oriented: the stock browser/runtime is built using HTML5/JS/CSS and is one of the greatest HTML5 compliant browser ever. The WebWorks framework (forked from phoneGap) is a very significant track to follow when talking about native/web unification.

I belive it’s a live example of how HTML5 will reach the mobile world as a “F1 running on highway” (I mean access to full hardware acceleration, for example), and should deserve at least some kudos for pushing that hard HTML5 developers adoption.

November 5th, 2012 at 02:33
1. Antoine Bapst (
  
  Some resources :
  
  The browser is HTML5 :
  http://www.berryreview.com/2012/09/25/blackberry-10-browser-built-using-web-technology-html5cssjavascript/
  
  Webworks: the “whole story”:
  https://developer.blackberry.com/html5/
  
  WebWorks is open sourced and you can build your own :
  http://devblog.blackberry.com/2012/10/blackberry-10-webworks-framework/
  
  Debugging BlackBerry web applications using Web Inspector :
  http://devblog.blackberry.com/2011/06/debugging-blackberry-web-apps/
  
  Let’s unite to promote our favorite language !!!
  
  November 5th, 2012 at 02:40
underhill

Will Firefox OS allow other browser engines or is this a lockout of a new variety, like Chrome OS on a mobile.

November 5th, 2012 at 07:04
1. Robert Nyman [Mozilla]
  
  To my knowledge, there won’t be any direct support for other web browser engines. The entire operating system is Gecko, the rendering engine of Firefox, and having another rendering engine within an existing engine doesn’t sound optimal.
  
  Firefox OS offers JavaScript APIs for the web layer to basically control everything on the phone through open technologies. Hopefully other engine makers will support these APIs on respective devices as well.
  
  November 5th, 2012 at 08:13
  1. Luke
    
    Underhill, You are correct. With Firefox OS you will be “locked into a fixed environment governed by a single company.” The only difference between FF OS and iOS is that instead of high performance Native apps, you will be stuck with slow HTML5 interpreted Apps with generic HTML5 based UIs.
    
    Mozilla’s excuse for locking out 3rd party browsers is that “Gecko is the Operating System”, which is completely misleading. It is similar to how Microsoft claimed that IE was part of Windows OS as an excuse to bundle it. Mozilla is just taking this one step further. They are creating a custom Linux distribution that only runs one application, Firefox.
    
    Mozilla’s problem is they have a fat browser that they want to run on resource limited mobile devices. Instead of attacking the problem at its core by streamlining their browser, they are trying to run their bloated browser on a stripped down OS.
    
    November 5th, 2012 at 16:49
    1. underhill
      
      This is exactly why I can’t get too excited about Firefox OS. However as an experiment to get telephony and other device APIs implemented I find it great, but as it is a locked device/os, I feel it goes against two of the three main points of Mozilla’s mission: “openness and opportunity on the web”. I suppose it could be argued that it does provide opportunity for developers, though I see fear that opportunity could lead to having an “open” web app that only truly functions on one platform.
      
      November 6th, 2012 at 06:52
Kyosuke Kawate

We had a go at aquoria.com.
It’s very exciting and worthwhile to tackle HTML5. Surroundings are evolving rapidly, we benefit from them. We are now under a beta-test phase focusing on mobile, it’s very easy to iterate updating HTML5 app.

Would you like to have a go at it?

November 6th, 2012 at 00:28
Kent

While I didn’t get a chance to read every comment I noticed a lot of negativity. It’s sad because the article makes really great points and understanding that HTML5 is still becoming adopted and that the build-once mentality and device agnostic nature of H5 is what makes it so powerful was really well stated.

I’ve been preaching HTML vs. device-native (where applicable) as long as I can remember. It’s better for the end user, the developer, and anyone that has to fund, support, or enhance the application.

Great article!

November 6th, 2012 at 16:20
1. mpmedia
  
  There is a lot of negativity not because of the tech, but we got sold that tech.
  and i’m sorry but neither the build-once deploy ev. and the device agnostic nature of HTML5 are true , at least for now. browsers dont implement the same api , and when they do , they sometime dont do it the same way.
  
  November 7th, 2012 at 10:43
  1. mpmedia
    
    I meant “how we got sold the tech…”
    
    November 7th, 2012 at 10:44
Ghaladen

The YouTube politics app (http://www.youtube.com/politics) on the iPad is proof that HTML5 is not ready to be the dominate standard for mobile. Whenever the video is playing, tabs take seconds to move over, the scroll views are sluggish, this is totally unacceptable for ANY application. And Google is no slouch as far as mobile web dev is concerned.

Don’t get me wrong, I want HTML5 to surpass native, whether it’s every app being a web app, or via a hybrid solution like PhoneGap. I’m tired of having to know C#, Objective-C and Java just to build apps for all platforms. Luckily I can develop most of my desktop native apps using HTML5 solutions like node-webkit (https://github.com/rogerwang/node-webkit, it’s badass). But honestly, until mobile webkit can handle what native apps can do or at least come close, for anything more than simple forms, HTML5 on mobile unfortunately just can’t topple native yet.

November 7th, 2012 at 09:59
Marco

The biggest problem I have heard with HTML5, and I do not know if it is a myth or not, is that since HTML5 does not support DRM, there is no way to prevent the downloading of video such as from Netflix and Hulu. I’ve also heard with HTML5 there is no way for Netflix and Hulu to prevent ads from being skipped. Because of this, Netflix and Hulu won’t switch to HTML5. Even many Youtube videos do not work if Flash is disabled, I think because of the ad skipping issue.

Is this true? Is there any way to fix this- some platform neutral “broadcast flag” that even if only on the honor system allows certain content to be streamed only but not saved?
Is there any chance that Hollywood will allow Netflix and Hulu to switch to HTML5, and if so, is there any chance they will?

November 10th, 2012 at 13:14
Dave De Silva

Design by committee. Lowest common denominator. HTML5.

These are synonyms.

And unfortunately, one cannot develop for even this low standard with confidence. Rather, one has to do sophisticated browser testing for even the most trivial features.

Wake me up in 2020. Sorry to be a troll. I’m just a real developer contemplating the walled garden with all seriousness. We have to weigh pros and cons in the real world, not an ideal one.

November 13th, 2012 at 22:02
YABE Yuji

Mozilla is pushing HTML5 strongly just because it’s the only way for them to survive the mobile era. I can understand it but the problem is that there are many developers who don’t want to be bonded to HTML/CSS/JavaScript. Most of all, JavaScript is a disaster even when we treat it as an assembly language (I’ve tried CoffeeScript, Dart, TypeScript, Emscripten and many others!).

As a C++ game programmer, I’ve never believed the openness and other advantages of the web. This disappointing article doesn’t change anything. I’ll continue developing native apps for at least 10 years and simply ignore Firefox OS. Many native developers will do the same and the result will be the lack of applications on Firefox OS.

The interesting thing is that Microsoft did the opposite decision recently. They allowed us to develop native applications on Windows Phone. How open they are. Please do the same, Mozilla. The web might meet the needs of some (or many) developers but it’s not good at everything obviously. HTML5 people MUST accept it. Can you develop high-performance applications like Skyrim, Call of Duty, Photoshop, After Effects, 3DS Max, Blender, Cubase, SONAR on browsers? Note that we can’t do it even on the current fastest PCs. That means that mobile browsers also can’t do it within at least 10 (or 20!) years.

At least HTML5 lovers should play recent rich game titles on iPhone and see what is happening on the native world. Do it now, please.

November 22nd, 2012 at 15:31
Mandeep Singh

Hey great article. I wrote an article that dicusses the new elements introduced in HTML 5. If you are interested in learning more about HTML5, you can read it here: What is HTML5

November 24th, 2012 at 23:31
anatoliy Kuzmenko

Nice article, I was using Adobe PhoneGap to pack my HTML5 application and havent any troubles

November 28th, 2012 at 10:52
Blake Callens

Good article, but I think why the native code argument is used so much is because most evangelists say that HTML5 is ready to replace compiled or semi-compiled web applications when, as you rightly put, it never completely will be.

December 11th, 2012 at 14:52
Joe Pereira

I am currently retired(age 77), but I still like computer programming because I have been doing it for many years, even before the advent of the Personal Computer, i,e,machine-language programming the intel 8585 processor and the motorola 6800, assembly-language programming of other various processors,which most people didn’t know existed, and inclucing C and C++ programming.
I began learning, studying, and practicing, the html 4.0, xhtml, and HTML5 several months ago, and I am thoroughly enjoying the bliss of experiencing this modern age of advanced technology, regardless whether I should do this or that. All I want to do is indulge in what I am doing with HTML5.

January 3rd, 2013 at 22:34
steve porker

Wow – what a lot of political nonsense. Have you ever tried to use phonegap to build across multiple platforms? ugh… if its so great, why are 99.9 percent of applications for ios and android still native? Because html5 is not mature enough and is full of kludgey javascript hacks to get a half decent ux – even then its piss poor compared to native. Im not sure about the suit analogy either – the one I use is html5 is like prefabricated houses vs a standard hhouse. Yeah the prefab might in theory be cheaper – but its got paper thin walls and will blow away in a hurricane. If you are concerned about developing for multiple platforms – have a look at tools like monotouch, which target opening up native experience by sharing upto 90 percent of the code base. Roll on 2015 for html5 to start to make a dent – until then, if you’re serious about mobile application development – stick with native.

January 20th, 2013 at 15:03
Janet

Who needs it if it can’t be monetized?

January 29th, 2013 at 12:53

Comments are closed for this article.

Hacks

By Chris Heilmann

HTML5 doesn’t perform?

HTML5 can not be monetized?

HTML5 can not be offline?

HTML5 has no development environment?

Things HTML5 can do that native Apps can not

Breaking the hardware lockout and making monetization easier

How far is HTML5?

About Chris Heilmann

124 comments

HTML5 mythbusting

By Chris Heilmann

HTML5 doesn’t perform?

HTML5 can not be monetized?

HTML5 can not be offline?

HTML5 has no development environment?

Things HTML5 can do that native Apps can not

Breaking the hardware lockout and making monetization easier

How far is HTML5?

About Chris Heilmann

Discover great resources for web development

Thanks! Please check your inbox to confirm your subscription.