PowerPoint Presentation

HOLIDAY WISH LIST FOR BROWSER MAKERS REQUIREMENTS FOR AN OPEN WEB

BY RAJARAM GAUNKER

Web applications are making quantum leaps in sophistication, complexity and functionality in many areas they are surpassing traditional desktop applications. Increasingly powerful devices, a wide variety of JavaScript libraries, and the growth of cloud-based services is transforming whats possible with web applications.

Browsers play an important role in this world. Browser inconsistencies have plagued the web since its early days. Microsoft tried to co-opt browser standards by leveraging Internet Explorer dominance violating the HTML spec left, right and center. Then, with the arrival of Firefox, Chrome and Safari, the browser landscape got even more interesting.

At the same time, websites were evolving. They began as simple, static web pages with little or no JavaScript. Then HTML5 created the possibility of complex web apps on browsers. To add to this, the appearance of mobile devices with full-featured browsers based onWebKitcreated hundreds of new possibilities.

Yet as we approach 2015, incompatibilities still create hurdles in the development of complex webapps. While DOM abstraction libraries like jQuery take care of most DOM-level inconsistencies, some are still left for the developer to struggle with. While browser vendors are focused on creating differentiation, users and developers are experiencing lock-in. This is a very serious hurdle to the Open Web. Vendors should adopt open standards and differentiate themselves with the Layout Engine and the Rendering Engine.

Let me get more specific now. During the development of our browser virtualization clientNanovisor.js, we saw several issues on browsers which were inconsistent and sometimes baffling. These issues forced us to have special-case handling for different browsers, which makes code complex and difficult to maintain.

Source: NY Times

In this blog post, Id like to share some of these with you and give the browser makers my wish list for the holidays. Heres to wishful thinking :-).

First, let me add a caveat to say that this is by no means an exhaustive list of the issues we have seen. Ive selected a handful here to make some key points. Let me start with Safari since it is the browser with the largest number of issues we faced, and is important from a customer deployment perspective.WISH LIST #1: LANGUAGE-LEVEL CONSISTENCYCombining two statements into oneis one of the most common and simple source-level optimization techniques. But sadly, it does not work as expected on Safari.Two simple statements are combined by the JavaScript code minimizer (Google closure compiler), and that triggered the bug in Safari. A simplified version of the code is as follows:var type = typeof document.all;if (type === function) {console.log(document.all is a function);// Above log is not printed on any browser}

But the closure compiler converted that code to:if (typeof document.all === function) { console.log(document.all is a function); //prints above log message on Safari only }The above two code blocks are equivalent in all browsers except Safari. All other browsers I tested on return typeof document.all === function as false; but Safari returns true, typeof document.all which actually returns a different value based on surrounding operator, and typeof document.all returns undefined on all the browsers.

This is a basic element of language consistency, and having a major JS engine that breaks this is scary.

WISH LIST #2: SAFARI CRASHESAnother big issue we faced with Safari was the JavaScript interpreter actually crashing on some piece of code. Such issues are very hard to debug, isolate and fix, especially for browsers that are not fully open-sourced. Execution of Javascript is done in a sandbox and there are several levels of abstraction between the executing code and the OS. Browsers should catch such errors and provide enough data to debug them.

Safari has been crashing deterministically on some simple JavaScript code while the same code runs well on other browsers. Many times, this looked on the surface like some bug in the JavaScriptJIT compiler.

Heres a sample bit of code which caused the crash:

function foo() {} window.addEventListener('DOMContentLoaded', function() { var lis = []; for(var i =0; i