Google Chrome Makes Web Developers Lazy

This post may make me sound ancient in the world of web development, but here it comes anyway.

Like Microsoft, Google has decided to implement functionality in their dominant browser that is incompatible with the other major competing browsers.

When I first started developing websites professionally, ensuring a website worked for 99% of the site’s visitors was easy, relatively, as you only needed to make sure the site worked in Internet Explorer 6. Obviously, there were a ton of random hacks and tricks required to deal with the quirks of this browser, but you were fairly safe knowing you had developed your site to be tailored to the browser of choice for your visitors. However, the dominance of Internet Explorer 6 was bound to come to an end and it ushered in an era of multiple popular browsers including Firefox and Chrome. With no single browser having a massive advantage in terms of users in all areas, web developers had to make sure that thorough testing of their sites was completed in each of the major browsers.

It works in Chrome, so it’s good enough.

Fast forward to 2014, and depending on the website, but we are almost in the same position we were in with a dominant browser we were years ago, but this time that dominant browser is Google’s Chrome browser. Granted, the Chrome browser of 2014 brings with it a much more powerful set of developer tools than we could dream of with Internet Explorer 6, but, like Microsoft, Google has decided to implement functionality in their dominant browser that is incompatible with the other major competing browsers. Now that Chrome is so popular, especially among web developers, I will often run across websites that make it obvious they were developed to the point of “it works in Chrome, so it’s good enough”.

Many web developers don’t know how to properly test their own websites.

One such area that I have seen this occur is with jQuery’s event handlers and JavaScript that assumes global variables exist. Here is one such example:

$(".link").click(function() {
    event.preventDefault();
});

Most experienced JavaScript and jQuery developers would quickly notice that this code will cause an exception when anyone clicks on an element with the link class. Unfortunately, in order to know the complete answer, you would have to know the exact quirks and ‘features’ that have been added to the browser to make things a bit easier for developers. The answer here is that in Google Chrome, the above click handler will function normally without any unintended side effects as Chrome has implemented a global event property that keeps this from throwing an exception.

Web developers should thoroughly test their sites in all the major browsers that their users use, fixing issues before they come to the attention of QA and end users.

If you were to test this code in Firefox, you would get the result that would be expected behavior, which is to get an error saying that Cannot read property 'preventDefault' of undefined. Keep in mind that I ran across this beauty in a website that was in its final testing stages before going live. Whenever I see issues like this it reinforces a long held opinion that many web developers don’t know how to properly test their own websites. The correct version of the above code is below:

$(".link").click(function(event) {
    event.preventDefault();
});

The excellent functionality that the Chrome devTools provide web developers and the ‘mostly’ standards-complaint functionality of the Chrome rendering engine have made it so that many web developers simply develop their website for Chrome, and then wait for QA and the public testers of the site to report any cross-browser issues. Instead, web developers should thoroughly test their sites in all the major browsers that their users use, fixing issues before they come to the attention of QA and end users.

Related Posts

Mar 31, 2014
2 minutes

JavaScript Templating

Many times it becomes useful to be able to make an AJAX request for some data, insert it into some HTML that is already on the client, and then display it to the user. There are a few ways to implement this, each approach has its benefits and drawbacks.

String Concatenation

Possibly the simplest way to accomplish the templating in JavaScript is to use simple string concatenation with ‘+’. This is the approach that I see many newcomers to JavaScript use in their code, as it is the simplest to implement. However, it does have a major drawback in that this method has the worst performance of all, especially in older versions of Internet Explorer. This could be implemented as below:

Jun 23, 2014
One minute

Always URL Encode your Cookies

One of the things that you tend to forget about when dealing with websites that typically only cater to English-speaking visitors is how to properly deal with Unicode throughout the site. It turns out that some browsers handle Unicode support in different sections of the browser differently.

For instance, it turns out that when you want to store Unicode data as the value in a cookie, your success may vary across browsers. When I tested this with the Euro symbol, €, it worked without a hitch in Chrome, Safari, and Internet Explorer. However, in Firefox, it was stored as an empty string. In order to correct the issue, you can use encodeURI() on the Unicode character to get the ASCII version of the Unicode character, and then store that in the cookie. Fortunately, this seems to work without issue across all of the major browsers.

May 21, 2014
One minute

Window.Open Causes Browser Compatibilty Issues

One of the things that always annoys me as a web developer is when native browser functions that are accesible from JavaScript do not share the same function signature. One perfect example of this is the window.open function. When you are using non-Microsoft browsers such as Firefox and Chrome, you are able to make a call something like this window.open(url, 'window name', 'dimensions or other settings');. The window name parameter is important because it allows you to open multiple links in the same external window/tab. However, when using Internet Explorer, especially Internet Explorer 8 and older, you can only use window.open(url);. If you try to use the first type of function call, you get a very ambiguous error message in the browser that doesn’t tend to show exactly where the error occurred.