Google Chrome Makes Web Developers Lazy

4 minutes - Aug 21, 2014
#jquery#javascript#rant#chrome

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.

Tags:

Mar 27, 2014

One minute

jQuery.hover Issues in Internet Explorer on Windows 7

When creating a new mega-dropdown menu for a site I was working on, I used jQuery’s .hover event to trigger which content the menu was displayed. This seemed to work as expected in most browsers that I tested in, except for one, Internet Explorer. Unfortunately, it wasn’t even in every instance of Internet Explorer.

Windows 7

After Windows Vista came out as one of the biggest duds that the world has ever seen, Windows 7 was a ringing success. Windows 7 is an extremely functional and useful Operating System in the vein of Windows XP, but during testing of this website, we found one troubling issue with every version of Internet Explorer we installed on it. When you hovered over the menu and triggered the jQuery.hover() event, Internet Explorer seemingly locked-up for a few seconds, making the entire browser unresponsive. In a stroke of strange luck, I was unable to reproduce this functionality in Internet Explorer on Windows 8 or 8.1, so this is something that only affects the older operating systems. The fix is to replace jQuery.hover() with jQuery(document).on(“mouseenter”) and call the appropriate function as well.

#internet-explorer #jquery #windows-7

Jun 2, 2014

2 minutes

Defensive Development - Fail Fast or Go Home

Defensive Development is a programming practice that is frequently misunderstood, but is nevertheless a critical practice to follow when working in many environments. I have seen articles written that argue that defensive development simply causes nonsensical null checks to be written, and as a result of seeing people writing bad code defensively, argues that no one should practice defensive development. There are other articles that, like many things in software development, argue that you should always use defensive development for everything.

#magento #javascript #design-patterns

Apr 16, 2014

2 minutes

Top 5 Ways to Make a Developer Your Enemy

Developers are known to be some of the most finicky employees you will encounter in the workplace. However, this is a list of things that will annoy or infuriate developers and non-developers alike.

Have the IT Manager send an email to all staff saying that all computers will have a keylogger installed. – This one is wrong on so many levels, the least of which is that it shows how little faith the company has in its employees and breeds mistrust of authority.
As a Manager or Team Lead, take ideas and suggestions from meetings with your team, and pass them off to upper management as your own. – This just reeks of someone that is only in it to gain more and more power.
As a Manager, don’t take the heat when things go wrong and blame the lowest-level employee instead. – I’ve seen senior management that is supposed to keep track of projects, ignore the project, and when it is the due date, blame those doing actual work on the project, throwing them under the bus.
As a new employee, on your second day of work, tell anyone that will listen or is within earshot that you are able to rewrite the entire codebase in three short months. Bear in mind, this codebase is over 7 years old and has a team of more than 20 developers working on it, but of course the newbie can rewrite the entire thing in no time flat.
As Management, when a developer hands in his/her resignation, schedule a meeting to try to first place a guilt trip on said employee to convince them to stay. If that doesn’t seem to work, then threaten to give the employee negative referrals if they don’t rescind the resignation and continue working for the company. Keep in mind that this occurred in a right to work state, meaning that there is no agreement in place that the employer would not wait a day or week or month and fire the employee without cause, just out of spite for wanting to work elsewhere.

These are just some of the things that will anger a software developer, so, be aware to avoid these if it matters at all to you.

#rant