Distilling market noise into market sense

VisionMobile is the leading research company in the app economy. Our Developer Economics research program tracks developer experiences across platforms, revenues, apps, tools, APIs, segments and regions, via the largest, most global developer surveys.

HTML5 performance is fine, what we are missing is tools

HTML5 is perceived as a lower quality platform, mainly because of performance. This comes both as a result of survey data, as well as developer interviews. Yet, industry experts claim the problem is lack of tools. So what is the HTML5 really missing, performance or tools? VisionMobile’s Web Technology Lead, and author of our acclaimed “Can HTML5 compete with native?” research report, debates the performance vs. tools issue.

HTML5-report

In April 2013 VisionMobile asked mobile app developers what stops them from using HTML5. 46% answered “Performance issues”, followed by 37% who said “Lack of APIs” (sample size: 1,518 developers).

WHAT STOPS MOBILE DEVELOPERS FROM USING HTML5?

We spoke to developers about their views on HTML5 performance. Apostolos Papadopoulos, author of 4sqwifi, a highly acclaimed public WiFi password app, noted “Quality and user experience is top priority for us. Therefore, we prefer going with a Native API”. It’s a common practice for developers to go native for better performance and user experience. But user experience, meaning following the behavioural conventions of the native platform, is a different story and HTML5 can’t help much. Developers can try to imitate but for a truly native UX they have to use Native SDKs; unless we are talking of Firefox OS or the long-awaited Tizen.

Ciprian Borodesku, CEO of Web Crumbz, added “From a business standpoint, there’s a lot of education needed for the acceptance of HTML5. There’s a gap between what we developers can provide and what the clients think we can provide”. The perception of HTML5 being a less capable platform is also common amongst people who commission apps.

Experts point to a tools gap

As part of our How can HTML5 compete with Native? report, VisionMobile conducted 32 interviews with industry experts, from Miško Hevery (author of Angular.js) to Max Firtman (author of “Programming the Mobile Web & jQuery Mobile” published by O’reilly) and Peter-Paul Koch (author of Quirksmode).

It came as a surprise when Robert Shilston, director of FT labs, champion of HTML5 apps, noted that “the biggest issue for HTML5 is the maturity of tools”. He emphasized not performance, but tools, as the key HTML5 gap.

Ran Ben Aharon, head of front-end development of Everything.me, explained it in more colour: “Hearing Mark Zuckerberg denounce HTML5 made me angry at first, but then I looked at some data and realized that the main reason was not performance or APIs but the lack of memory management and debugging tools”.

Even though developers identify performance as the #1 problem of HTML5, a number of experts claim the actual challenge is tools. There’s no contradiction here, performance and tools are related. How can you improve an app, if you can’t measure it? How can you fix a bug, if you can’t replicate it?

HTML5 is like a car without a dashboard

Tools are to HTML5 what a dashboard is to a car. You can’t run at high speed without knowing how fast the engine runs or you might end up totalling the engine. Likewise, you can’t produce fast HTML5 apps if you don’t have quality debugging and profiling tools.

With HTML5, coding and debugging are two separate processes. There is no self-contained IDE here. Developers code on the editor (e.g. vim or sublime) and debug on the browser, i.e. using Chrome developer tools. But debugging tools are difficult to master and they require a thorough knowledge of the underlying technology, e.g. what is a reflow, how does the garbage collector work, how is a memory leak created.

Louis Stowasser, author of CraftyJS noted “it would be great to have something like YSlow for game developers”. Why pick YSlow and not Chrome developer tools? Well, because the former offers insights on what to fix rather than data requiring interpretation.

Moreover, each browser has its own set of debugging tools. As a result, developers need to become familiar with at least 4 different environments to match the most popular browsers of the market. And though it’s generally true that these tools look alike, it’s the little bits and pieces that make the difference.

Patrick H. Lauke, former product manager at Opera Software, highlighted the fragmentation of the browser debugging tools by commenting on a W3C public discussion board about our research: “Opera Dragonfly was the first to offer remote debugging and proposed a unified protocol for debugging. Sadly, other browsers showed very little interest and instead went their own separate ways to build something similar but different”. This also touches on the browser politics issue, due to be the subject of another blog post.

Better tools are needed

HTML5, as far as performance is concerned, is adequate for most use cases. And tools like famo.us and Goo Engine provide a testament. The question is no longer *whether* HTML5 can produce quality apps, but *how* easy it is to create quality web apps. What the HTML5 platform desperately needs is easy-to-use debugging and profiling tools.

With the right tools we could see external debugging tools hooking to multiple browsers and even apps able to profile themselves via standard debug APIs.

Web development attracts millions of developers who are new to software engineering because of the learning curve; it’s very easy to get started. The complexity gap between building basic sites and single page web apps (SPAs) is too big of a leap for many to jump over. Improved tool usability is one of the best ways to bridge that gap while also increasing productivity for those already building complex web apps.

What other improvements do you think are needed in HTML5? Download our research and participate in the discussion.

  • Titanium seems to solve several of the issues people have with the HTML5/CSS/Javascript paradigm: IDE, performance (up to a point), phone features (up to a point) etc. Also PhoneGap tries to solve this, up to a (lower) point. That said, it doesn't beat native development if you want the whole feature set and max performance (for games, social etc). For corporate apps this should often be sufficient, that are almost always frontends to a service. Then phone compatibility and quick development/rollouts/updates are the most important factors. Even pure Web apps (via responsive design) might be sufficient there in many cases.

  • eortiz

    It is surprising that "monetization" is so low in the chart. That is one of the main/top issues.

    One of the things that have been very slow to take off are "hybrid app/webapp" stores, which would definitely help with the situation.

    The rest of the items described such as lack of APIs and native-lack capabilities etc — still the same issue for the last 10 years.

    But again to my point — monetization aspects is key — IMO. This translates yes to better/easier tools, better/easier ways to deploy e2e webapps and ways to better market (distribute) the webapps.

    /ceo

    /ceo

    • Agreed, yet if most developers answering this survey were employed, then monetization was not an issue to them. Neither is it an issue if the apps are made for paying customers that then take responsibility for monetization, if that's even the goal (not so for most apps that complement existing services with mobility). The latter is where I've made money on apps (at all).

      As you know, If you "wrap" a Web site in a native app, then it can be treated as any other native app, including have a price, so in practice that seems to be a good way to monetize Web apps without need to change the infrastructure. In-app purchases work too: http://googlecode.blogspot.se/2011/07/make-money-
      Admittedly I haven't tried it. Nice cut though!

  • HTML5 is fine?! HTML5 is based on a bogus programming language that's not even one, but an interpreted script. It takes rocket scientists to hack HTML5 and make it work, rocket scientists most companies cannot afford and most of the time cannot find even when they can afford them. #FAIL

    Facebook dumped HTML5 saying it is the "biggest mistake" in the company's history. LinkedIn dumped HTML5 saying it was a mistake to adopt it. Google said HTML5 is a failure and JavaScript simply cannot be fixed.

    HTML5 consists in putting band-aid on a chicken dead in the egg, to make it work across browsers on life support. Forget mobile, desktop, TV. Each new destination is more hacking, discrepancies & failures. #FAIL

    HTML5 is a failure because of its nature: implementation left to the browser, with vendors free to implement it how, when & if they want. Features might work in 1 browser but not the other, or not work & look the same, or not at all. #FAIL

    That is when vendors don't cripple it on purpose, such as Apple executives marking HTML5 bugs not to be fixed by executive order. That is Apple execs ordering Safari mobile engineers not to fix bugs that refrain HTML5 from competing with AppStore & iTunes. #FAIL https://twitter.com/flexengineer/status/151438556

    That is why you see mind blowing facts such as iOS7 plagued with HTML5 bugs, don't tell me Apple does not have the money & talents to avoid that. #FAIL http://www.infoworld.com/t/html5/bad-news-ios-7s-

    HTML5 is the biggest corporate bullying scam in the entire history of the Internet & is costing enterprises hundreds of millions. Most HTML5 web "developers" are costing enterprises 2x to 5x more money than Flash/Flex/AIR experts because they spend more time, by multiple folds, to develop apps that fail at the end, versus Flash/AIR apps that work the same everywhere from 1 single code base, with 1 team instead of 2 to 4, & all based on a rock solid enterprise class object oriented programming called AS3, not to be confused with AS2 which is as bad as JavaScript.

    In 2010 I told Sheryl Sandberg, COO of Facebook that they will fail by adopting HTML5. A few years later Zuckerberg went on the record to apologize to his shareholders & called it "the biggest mistake" in the company's history, after spending millions in a project codename "Spartan", an HTML5 platform with which they try to take on the AppStore, which failed miserably, failed the company's entry to the mobile market, therefore failing their IPO. They should have read my blog more attentively instead of listening to a bunch of developer kids straight from school.

    It is because HTML5 / JS are a failure that Jobs, smarter than anyone else, pushed it as a decoy to distract the attention from the abusive ban of Flash. The mobile browser is the only 1 destination where HTML5 makes sense, not because it is good, but because it is a failure, that is how Jobs wanted it.

    Jobs wanted everyone to fail with it in the browser, left with no alternative since Apple banned not just Flash but also Silverlight & Java, every single serious app technology allowing to compete with native apps from the browser, making everyone fall back to native app & self enroll for a racketeering 30% tax. He was a genius, I give you that much & he is laughing & finger pointing at HTML5 developers & adopters from the other side all the way to Hell Bank.

  • H

    Maybe HTML5 isn’t great but I don’t see why you have to blame Javascript. Javascript is a great language. Just because you like your class based languages does not mean javascript is bad. (you can do pretty much anything a class-based language can do in a prototyping language) If it’s so bad it wouldn’t have the biggest community of developers and also be the most popular programming language in the world.
    you said, “HTML5 is based on a bogus programming language that&#039s not even one, but an interpreted script.”
    Are you sure you know what a PROGRAMMING LANGUAGE is?? because an interpreted language IS a programming language; a scripting language IS a programming language.
    So I guess you also do not consider Python, Ruby, PHP, Perl, etc to be languages??
    I don’t understand how people like you can become so opinionated about computer languages. People like and NEED different languages in different situations.

VISIONMOBILE BLOG

Distilling market noise into market sense

What gets desktop developers out of bed in the morning?

desktop developer segmentation

Despite all the hype around the death of the PC and the enormous amount of media attention focused on mobile,…

Continue reading ...

A proven model for targeting IoT developers

IoT-segments-infographic-Visionmobile

  What if you could identify a handful of developer personas, or segments, each with a very distinct set of…

Continue reading ...

1000 skills: Amazon Alexa as a metaphor for the IoT developer community

IoT_segmentation_Cover_HD

Alexa is a centerpiece of Amazon’s Smart Home push, and quickly growing to become one of the most promising attempts…

Continue reading ...

VISIONMOBILE RESEARCH

Research on the app economy and developer ecosystems

Developer Segmentation 2014

WF-Developer-Segmentation-Q3-2014

The Developer Segmentation Q3 2014 report is the most sophisticated study of developer segments to date. The report delivers a…

Continue reading ...

App Profits and Costs

AppProfits

This research report examines the critical success factors for a profitable app, and how business and technology choices, such as…

Continue reading ...

Developer Segmentation 2013

Developer Segmentation 2013

The Developer Segmentation 2013 report delivers a needs-based segmentation model that actually works, with extensive profiling of the eight principle…

Continue reading ...