Interview

What’s Next for HTML5?

Intel Visionary Discusses the Future HTML5

Edward J. Correia

Edward J. Correia has been a part of the computer industry since 1980, when he began selling (and occasionally hacking) Atari and Commodore computers. His first freelance writing gig was for Network Computing magazine in 1993 doing one-off reviews. In addition to writing for RH+M3, Correia currently serves as managing editor of the CRN Test Center, a computer and networking test lab that he helped establish in 1995. During a 10-year hiatus from CRN parent, The Channel Company (formerly part of UBM), Correia was editor of Software Test & Performance magazine and executive editor of SD Times.

Articles: 7

Computer programmers have been grappling with cross-platform issues since there was a second platform. Since then, the number of issues has rapidly increased. Today’s developers can target at least four operating systems (plus their fragments), running on devices with all shapes, sizes, resolutions, persistence levels, input methods, carrier networks, connection speeds and states, UI conventions, app stores, deployment and update mechanisms, and on and on.

Many of the world’s developers once looked to Java* as the shining knight of cross-platform development. Indeed, the structured language of Sun* (and now Oracle) continues to solve many cross-platform issues. But it also introduces obstacles, not the least of which is a class structure that heavily burdens even the tiniest of program functions. Java’s heft grew still more burdensome as developers turned to the browser for app delivery; Java applets are black boxes that are as opaque to the browser as the language is closed to the developer (with all due deference to the JCP).

Around the same time Java was fuelling the browser wars, a like-named interpreted language was beginning to emerge. First called Mocha, later LiveScript, and finally JavaScript*, the language proved more useful than Java in some ways because it could interact with the browser and control content display using HTML’s cascading style sheets (CSS). JavaScript support soon became standard in every browser. It is now the programming language of HTML5, which is currently being considered by the World Wide Web Consortium as the next markup-language standard.

To better understand HTML5—why it is where it is and where it’s going—Intel® Software Adrenaline turned to Moh Haghighat, a senior principal engineer in the Developer Products Division of Intel’s Software and Services Group. Moh was the technical lead from Intel’s side on the first JavaScript just-in-time compiler (JIT) in Firefox* browser. He also led the development of the first parallel JavaScript JIT and parallel browser layout-engine prototypes, both in the context of Firefox. He is currently leading Intel’s HTML5 technical strategy.

Intel Software Adrenaline: Why is HTML5 better than Java for cross-platform development?

Moh Haghighat: Starting a Java applet reminds me of the infamous “Loading Java” status bar. Seeing all those progress bars instead of the responsiveness of today’s web browsers would be annoying at best. That is a fundamental issue in the language, which [Adobe] Flash* solved to a certain extent. For a tiny piece of Java code to run, the whole JVM has to be loaded inside the browser, and a potentially large series of class initializers has to be executed before you can start executing it. For server-side code, where you are repeatedly running the same code for a large number of clients, this would be fine. But on the client, where the code you want to run is from many different applications, you can’t afford to be seeing that progress bar. Java's ultimate sweet spot turned out to be in the middleware on the server side, with great work done by WebLogic*, Java application server pioneer. This is one of the technical reasons why HTML5 is better than Java for client-side development. Having said that, Java played a major role in establishing the viability of managed programming languages and paving the road for even more productive higher-level languages such as JavaScript, PHP*, Python*, and Ruby*.

Java also has some really nice features that enable efficient code generation with very little need for expensive compiler analysis, such as type-based and offset-based disambiguation for registerization.

The other problem is how Sun did the execution. Java wasn’t initially open, and web technology evolved. I think the main reason Java did not succeed was that Sun ignored the web browser; you didn’t see much innovation around Java for the browser while JavaScript became more powerful. Asynchronous usage model of JavaScript (AJAX) made the browser an excellent interactive platform resulting in very popular web-based apps such as Google* Docs. Meanwhile, such apps keep growing in complexity. For example, Gmail* grew from almost ten thousand lines of JavaScript in 2004 to almost half a million lines of JavaScript code in 2010, a 50x growth in size over just six years (see Figure 1). With the web’s sudden growth around the world and millions of web pages using JavaScript, it is by far the largest language in terms of installed codebase. Java’s integration in the browser was nowhere close to that of JavaScript, which is the browser’s “native” language. Also, Java platform does not have the nice separation of UI and logic that the browser has with CSS and JavaScript

HTML5 offers a more attractive alternative. Just write your application and run it on any kind of computing device, whether it’s a phone, tablet, netbook, desktop, or TV. If the device supports HTML5, it will run there. You don’t even need to compile; you just write your program, and it gets distributed and executed.

Figure 1:  Adam de Boor, Google

ISA: JavaScript and HTML have been around for years. What has changed recently that makes HTML5 so effective across platforms?

MH:  First, over the course of the past five years, JavaScript became really fast, 100x faster (see Figure 2), largely thanks to the arrival of JavaScript JITs which became a necessity due to the major increase in web application complexity and sophistication. The latest Internet Explorer* version of 2011 is more than 100 times faster than Internet Explorer in 2001 in JavaScript performance. Second, a very large number of new capabilities are suddenly being introduced through HTML5. HTML probably has the biggest set of innovations since the introduction of the browser. The way we render HTML now is completely different than before. Once HTML5 started spreading, its performance also improved and new capabilities were added.

Figure 2:  Luke Hoban, Microsoft

On the adoption side, another interesting trend that I’ve seen recently is that IT departments are increasingly finding HTML5 extremely attractive because people bring different devices to work. Hundreds of different smartphones, tablets, and laptops are being used in business today. HTML5 is the only viable solution that enables IT apps to run on all devices. Otherwise, companies cannot afford to develop and support their applications on every device type. Responsive design patterns are emerging based on HTML5, where the content adapts to your device’s display size. These are all integral aspects of HTML because with CSS and JavaScript you can dynamically adapt to different devices.

ISA: Because it lacks static typing, JavaScript has been criticized for being limited to small applications. Is this a valid criticism?

MH: In the future, JavaScript will have class, modules, and typing capabilities. The ECMAScript* committee for the next version of JavaScript is working on classes, which are good for maintenance. Java had classes; C++ had classes. JavaScript has prototype-based inheritance, which allows you to implement classes, but it doesn’t impose a particular implementation of classes. Java had its own object model for the classes; today, JavaScript doesn’t impose a particular class model in the language. It gives the capability to implement your own version of class.

For software engineering reasons, people might want to have a particular class model if a very large number of developers will be involved. For a very large project, you want some restrictions; you want to define your sort of coding principles and so on. JavaScript’s flexibility may turn out to be a negative if everybody starts using it in his or her own way.

To make an analogy for old-timers, programming languages such as FORTRAN had the GOTO statement. But in the 1970s, Edsgar Dijkstra and others observed that unstructured use of GOTO was harmful. So, instead of arbitrarily using GOTO, programmers were urged to use structured programming principles that result in languages and applications that are much easier to understand and maintain. The same thing is happening as JavaScript becomes the lower-level language on top of which a lot of higher-level languages can be implemented. JavaScript has become the so-called “assembly language of the web.”

ISA: Can you give us an example of such a scenario?

MH: The most recent and exciting case of taking advantage of restriction and structure is a project that Mozilla has been developing, called “asm.js,” in conjunction with another one of their projects, named “Emscripten,” which is basically a compiler from LLVM bit-code to JavaScript and HTML5 APIs. (LLVM is an Apple*-sponsored project to develop a low-level virtual machine compiler infrastructure and language front-end for C/C++ and others). Emscripten essentially converts C++ to JavaScript.

Asm.js is an optional target of Emscripten that delivers near-native performance, with typically less than 2x overhead compared to optimized native code, as opposed to ~5x, which is where the full JavaScript is today. Although JavaScript is dynamically typed, asm.js requirements, such as type inference and annotations, are still completely in JavaScript specs. Using asm.js, you can write code that can be proven to be statically typed. So, at load time it can be verified that the code is actually statically typed. And the ahead-of-time compiler can generate highly efficient code without the need for the extra checks that you would need to do for dynamically typed languages; this gives you both flexibility and code efficiency.

These are all evolving as we speak and would make it possible to convert large bodies of compute-intensive code, such as performance libraries and game engines, to JavaScript and make it available to the entire world on every device. JavaScript is now becoming the target language of higher-level languages.

ISA: What other JavaScript-related language efforts are on the horizon?

MH: A language called CoffeeScript* now exists, and Microsoft is developing the TypeScript* language, which is a super set of JavaScript. Google’s Dart* is a new language with the concept of class that will also compile to JavaScript. I don’t think you can force the entire web to replace the web browser main language. However, I believe that the nice features of languages that are coming along will influence JavaScript specs and will find their way there. That way, you basically have evolution, backward compatibility, and incremental change.

ISA: Intel is directly involved in the advancement of HTML5 and JavaScript. What can you tell us about these efforts?

MH: Intel has been leading in the area of parallelism, and that is aligning HTML5 and multi-core. You need this parallelism for responsiveness and better power utilization. We parallelized the CSS rule matching of Firefox* layout engine to make it scalable. From the programming language point of view, HTML5 has a parallelism API called “Web Workers.” This is good for the coarse-grain background threads, but, if you want to do a large number of small parallel [tasks], then Web Workers is not suitable. Intel has been working with Mozilla on parallel arrays; our colleagues at Intel Labs prototyped it first. We are now trying to solve all the problems in the implementation to get that into ECMAScript, which is the official language spec of JavaScript.

We are also working with Mozilla and Google to ensure that the SIMD vector capabilities that are out there (Sandy Bridge, Ivy Bridge, and so forth) are actually programmable in JavaScript. That is, if you have JavaScript code that is operating on data in parallel, that code can actually be vectorized, and developers can have guaranteed execution that uses these capabilities. These will eventually find their way into the standard.

Conclusion

The proliferation of operating systems and devices has many of the world’s developers searching for a cost-effective way to create their applications. Developers once looked to Java as the cross-platform development solution. Java had many advantages over older languages, but Java hasn't kept up with the rapid pace of mobile platform innovation. Developers are now turning to HTML5 and its core technologies, JavaScript and CSS, to get the latest functionality and cross-platform operability needed to succeed in today's application marketplace.

According to Haghighat, Intel engineers continue to optimize HTML5 engines on Intel platforms and add new functionality to HTML5. Intel sees HTML5 as a major step forward toward the era of transparent computing. To further accelerate HTML5 adoption, Intel also now offers the Intel® XDK, a complete suite for developers to build, test, debug, package, and deploy their HTML5 apps to a variety of platforms including Android, Firefox* OS, and iOS.

Resources
 

Intel® Developer Zone: http://software.intel.com/en-us/html5