HTML5’s “Dirty Little Secret”: It’s Already Everywhere, Even In Mobile


HTML5 has never really lived up to its potential. As VisionMobile posits, this is partly a problem with performance and partly a question of tooling. 

But it’s also a problem with marketing, as EmberJS co-founder and JavaScript evangelist Tom Dale (@tomdale) tells it. As he informed me in a far-ranging interview, “The dirty little secret of native [app] development is that huge swaths of the UIs we interact with every day are powered by Web technologies under the hood.”


JavaScript Hipster Tom Dale

So who is to blame for the HTML5 community twiddling its collective thumbs while native mobile development gets all the glory? I sat down with Dale to get the skinny on mobile development.

HTML5 Is Already In The App

ReadWriteBrowser development lags native development, perhaps in part because Apple and Google have invested so much in their SDKs. Why hasn’t the world rallied around the Web for mobile in the same way it has for Linux (OS), analytics (Hadoop), etc.? In fact, Firefox excepted, it seems that the Web breeds plenty of innovation, but not necessarily the concentrated innovation that’s needed right now to make HTML5 a real force in mobile. 

Tom Dale: I disagree with the premise that the Web lacks concentrated innovation. In fact, if you look at the majority of “native” mobile apps written in 2014, how many of them contain significant portions authored using HTML and JavaScript? The dirty little secret of native development is that huge swaths of the UIs we interact with every day are powered by Web technologies under the hood.

See also: Congrats, HTML5—You’re All Grown Up Now

When people say Web technology lags behind native development, what they’re really talking about is the distribution model. Let’s be clear about what the Web is: an open, standardized platform, accessible to everyone, that allows users to run completely untrusted code from multiple vendors, where applications are “installed” on demand just by visiting a URL. You’ll forgive me for thinking that app stores are an easy problem to solve in comparison. (This XKCD comic comes to mind.)

It’s not that the pace of innovation on the Web is slower, it’s just solving a problem that is an order of magnitude more challenging than how to build and distribute trusted apps for a single platform. As we saw on the desktop, it may take a few years to catch up to all of the capabilities of a native, proprietary platform, but in terms of the impact it will have on humanity, forgive me for not losing sleep if we have to wait a few years for it to arrive.

RW: Tim Bray recently said that JavaScript isn’t good enough; that it’s a crappy language. Are there viable alternatives out there that just need a touch of luck and corporate (or community) involvement to get them to a point that they can reasonably compete with the closed alternatives?

TD: Tim is just wrong. There’s no other language runtime as widely distributed as JavaScript’s. Getting a runtime installed pervasively is the high-order bit, and I don’t see anything on the horizon that will supplant JavaScript in that sense for at least the next decade.

See also: Google Needs To Double Down On HTML5—And Soon

Furthermore, the pioneering work by Mozilla Research on asm.js opens the door to JavaScript becoming not just a language but also a substrate for other languages to build upon. Already we see projects like Emscripten taking advantage of this work, allowing developers to compile any language with an LLVM frontend (and there are many!) to run with adequate performance inside the browser.

Again, adoption is the critical aspect. JavaScript is everywhere. Anyone who tries to replace JavaScript without treating adoption as priority #1 is fooling themselves. In my opinion, that’s why Mozilla’s let’s-improve-JavaScript strategy has been so much more successful than Google’s myriad efforts to replace it (both with Dart and NaCl).

Google, Apple And The Web

RW: Why hasn’t Google been a stronger advocate for HTML5? Yes, it has much to gain from Android, but it arguably has even more to gain from a common platform that makes the web the center of the mobile experience. And yet Apple has been a stronger advocate of HTML5 than Google has, at least in my estimation. 

TD: Google is a strong advocate for HTML5, or at least particular teams within Google are. But the Google of 2014 is an adolescent behemoth, with accompanying growing pains and identity crises. It’s not surprising the signals out of it have been so mixed.

See also: HTML5 Has A New Best Friend—And It’s Apple, Not Google

My theory is that there was an internal battle inside Google: Fight against Apple on its own turf, with an app store and a proprietary SDK, or go all in on the Web?

With Andy Rubin out and Sundar Pichai taking over both Chrome and Android, I think it’s obvious wiser heads have prevailed. Expect to see a much tighter integration of Chrome (and, therefore, Web technologies) into Android over the coming years.

Google’s only significant source of revenue continues to be search ads; anything that drives users away from the Web as the starting point of every interaction is the wrong decision, in my opinion. All indications are that, after some political battles, the executives at Google have realized the same thing. I’m excited for what the newly-rejuvenated Google can do for the mobile Web.

As for Apple, it’s definitely a different company under Tim Cook. I’m cautiously optimistic about the future of Safari on iOS. In particular, the work they’ve been doing on JavaScript performance is just stunning. Many people still think of V8 as the fastest JavaScript engine, but in our benchmarks, Apple’s JavaScript engine Nitro is smoking them.

Working with Apple can still be frustrating at times, as a culture of secrecy still pervades the work. We recently had a very difficult time tracking down a bug in iOS 8 that Apple engineers refused to work with us on. But hopefully the higher-ups will eventually realize that working closely with the Web community leads to a better experience for their users.

Making HTML5 A First-Class Citizen In Mobile

RW: What will make the Web a first-class citizen on mobile devices? What needs to happen, and who is most likely to make it happen?

TD: I think the competition between Google and Apple will make it happen. As I mentioned before, Google has a very strong incentive to keep users on the Web, as search ads continue to be their lifeblood. I expect to see Google integrate the Web more tightly into the Android experience, and Apple wants to remain competitive.

Of course, there are still huge missing gaps in the web platform before it can truly compete with native. Efforts like the Extensible Web Manifesto have been largely successful at overhauling the historically glacial pace of standardization. Instead of trying to standardize high-level features with large API surface areas, browser vendors and standards bodies have shifted their focus to small APIs that expose just the capability primitives.

See also: How HTML5 Crashed, Burned And Rose Again

These small primitives allow the larger community to build libraries and ecosystems on top, rapidly increasing the pace of innovation. The Service Workers API is the most recent success. Service Workers allow web apps to add functionality people assume are only possible in native apps—push notifications, offline support, background syncing, and more.

Perhaps surprisingly, Service Workers support is already starting to land in browsers. And because all modern browsers auto-update without user prompting, the era where you have to wait years to take advantage of new features in the Web platform is coming to an end.

Take these auto-updating “evergreen” browsers and pair them with newly reinvigorated and competent standards bodies, and new technologies like asm.js that squeeze every ounce of performance out of JavaScript, and it’s not hard to see that the future of the Web on mobile is a happy one.

What HTML5 Has Already Achieved

RW: What are the best app experiences you’ve seen built with HTML5/EmberJS? In other words, what is the state of the art?

TD: There are a ton of great examples. Vine is a great example of a modern JavaScript app. It’s lightning fast on desktop and on mobile, and shares the same codebase for ease of maintenance. It has great URL support and feels like a web app; users have no idea it’s pure JavaScript, it just feels really fast.

It’s a mistake to think the end game is Web apps that look and feel the same as native apps. While it will be possible, I think we’ll see a convergence: the interaction patterns of the Web, with a sprinkling of native where it makes sense.

For sheer impressiveness, there are few programs more demanding than games, and Mozilla is really pushing the envelope here. For example, Unity and Epic both recently announced that developers who build games on their platform will be able to export to the Web, thanks to asm.js and WebGL. Imagine a world where you never have to install games; you just visit a website and, boom, you’re playing a AAA first-person shooter.

Angry Bots is a game authored using Unity that you can play on the web. I’ve shown this demo to many people by now, and I still can’t get over how cool it is.

Lead image courtesy of Shutterstock

Facebook Comments

New

Rising

Popular