Holiday Wish List for Browser Makers – Requirements for an O

1. HOLIDAY WISH LIST FOR BROWSER MAKERS –REQUIREMENTS FOR AN OPEN WEB BY RAJARAM GAUNKER

2. 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 what’s 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.

3. 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

4. In this blog post, I’d like to share some of these with you and give the browser makers my wish list for the holidays. Here’s 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. I’ve 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 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 }

5. 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.

6. 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 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 JavaScript JIT compiler. Here’s a sample bit of code which caused the crash: • <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> 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.

7. 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 remove Attr.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.

8. WISH LIST #4: YET ANOTHER TYPEOF DIFFERENCE 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): HTMLObjectElementand HTMLEmbedElementprovide 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.

9. 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 developer’s 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 I’m not dreaming of an impossible utopian world.

10. www.instartlogic.com/blog/