You are on page 1of 10

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 onWebKit created 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 client Nanovisor.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 CONSISTENCY


Combining two statements into one is 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 CRASHES


Another 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 opensourced. 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 JavaScript JIT compiler.
Heres a sample bit of code which caused the crash:

Crashing of the browser has very serious impact as it cuts off


a set of customers (OS X, iOS users in this case) for webapp
developers.

<html>
<head></head>
<script>
function foo() {}
window.addEventListener('DOMContentLoaded',
function() {
var lis = [];
for(var i =0; i <200; i++) {
lis[i] = i;
}
Lisnew = Object.create(lis);
for(var i=0; i < lis.length; i++) {
Object.defineProperty(Lisnew, i, {
get: function() { return lis[i]},
set: function(val) { lis[i] = val}
})
}
var obj = {};
foo.apply(obj, Lisnew);
});
</script>
<body>
</body>
</html>

WISH LIST #3: DEPRECATING FEATURES FLIP-FLOP OF


CHROME, W3C AND FIREFOX
Deprecation is part of spec development and needs to be done with extra caution, clear communication, wider consultations
and experimental analytics.
Earlier this year the W3C changed the DOM spec to removeAttr.ownerElement. Chrome followed the spec, and released
Chrome 34 with it removed and then added it back in Chrome 37.
Meanwhile Firefox removed it in 29 (Aurora) and reverted the change when the final version came out.
This bug created much confusion, as different people were testing on different browsers.
The full story of this flip-flop can be seen in
W3C ticket 25086
Chrome ticket 353104
Firefox ticket 957431
The W3C, along with Mozilla, Apple and Google, drives the specifications. The occurrence of this bug showed a lack of
coordination between them.

WISH LIST #4: YET ANOTHERTYPEOFDIFFERENCE ON


FIREFOX
Deprecation is part of spec development and needs to be done with extra caution, clear communication, wider consultations
and experimental analytics.
There are several old problems for which no consensus has been reached for many years now.
The following inconsistency, for example, has been there since 2004 (the early days of Firefox):
HTMLObjectElement and HTMLEmbedElement provide interfaces to external content like Flash and Java applets in browsers.
If you do
typeof embedElement

it returns function when running on Firefox and object when running on the rest of the other browsers.
According to the ECMAScript spec (11.4.3), the typeof operator on a native or host Object that is callable should
return function. Not all plug-ins are callable, but Flash SWF plugins are callable. Other browsers return object for even
callable plugins.

CONCLUSION
So there you have it. These are some of the top of mind issues that we encountered during the Nanovisor development
process that reinforce that writing cross-browser software is difficult, frustrating, expensive, and thereby likely to drive lots of
developers away from the web rather than encourage them to embrace it.
It is high time that browser vendors come together and clear out these long-pending, annoying inconsistencies. Thankfully
Internet Explorer has been doing this starting with IE10. They are not finished yet, but they have made a welcome start.
Consistent browser behavior is important and a requirement for the success of an Open Web. Browsers riddled with
inconsistencies will keep on eating away at developers time and money (not to mention their sanity). Browser makers need to
come together to remove older inconsistencies with a mechanism that provides enough time for developers to eliminate
dependencies in their code that exist due to these.
Safari is the most inconsistent, crash-prone and buggy browser, well on its way to becoming the IE6 of the HTML5 world.
Chrome is trying to push the native platform PNaCl. Perhaps their intent is to create stickiness and trap developers to their
app platform for their obvious benefit. Yet, I would like encourage them this holiday season to take some decisive action on
this front and help create a world with consistent browser behaviors for developers and thereby, for everyone that uses the
Internet. I hope Im not dreaming of an impossible utopian world.

www.instartlogic.com/blog/