Jquery

The Number 1 Cause of the Not Invented Here Syndrome

One of the quickest ways to get a new internal tool bootstrapped is to utilize an existing design, making slight adjustments to ensure the design matches the requirements of the current project. Instead of using another internal tool as the basis for the new design, I used a design that was purchased specifically for this project.

This particular design was unique in that there were multiple working examples using AJAX, pure HTML, and AngularJS. While it was nice having supposed working examples, when you start to look at the readme file for how to get this functionality working on your own hosting setup, thats when the niceties disappear. Specifically when lookng at the readme file for AngularJS, it effectively says: “Because this is a well-known JavaScript framework, we are not including any documentation for how it works or how to get started with our design”. Granted, the inner workings of AngularJS need not be covered in the readme, but a simple walkthrough of what to expect this design to do would make things much more user/developer friendly.

Write Bulletproof JavaScript

While display issues have long been the bane of a web developer’s existence, current web development projects tend to have much more client side interactivity, focusing ever more attention on the reliability and resilience of the JavaScript you write to deliver the complete interactive experience. Many things can cause unexpected errors in your carefully crafted code.

However, there are a few things that you can do to make sure that your site degrades gracefully and still provides a basic level of functionality when something in the browser goes wrong. The following snippet of code illustrates a few best-practices for defining your JavaScript namespaced modules.

Parallax Background Scrolling on Internet Explorer is Not Smooth

One of the pleasures of working on a website that is using some of the latest technologies is that you often run into strange compatability issues that only affect one browser or another, and many of the forums have little to no information about how to properly address the issues. Parallax scrolling is a technique that has been around for a while now, highlighted by Apple’s own iPhone 5s card-esque scrolling on their homepage, among others. While the site I am working on does not have as elaborate a parallax implementation, it does not work instantly across browsers by default either.

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.

== and === in JavaScript and HTML Input Elements

If you read any current information about best practices in JavaScript, you will typically find the following advice somewhere in the list of things to do.

Always use === and !== while avoiding == and !=

While I will never argue against this advice, there are a few things that a developer shoule realize when using === and !== instead of == and !=.

1. === and !== first do a check of the data type of the two objects you are comparing. JavaScript never forces you to explicitly define the datatype for an object you are creating as it will automatically assign one based on the contents of the object and how it was created.
2. The output of all of the Math functions produce integers or floats as the datatypes for the resultant numbers. For example, Math.floor(10.39438) will produce 10.
3. When retrieving the value of any select or input or textarea is always return as a string. This means that even though the value of the string may be a perfectly good number, it will never match a number data type. For example "10" is not equal to 10 when using the ===.

You should always use === and !== instead of == and !=, but you should make sure you understand the datatypes you are dealing with so that your comparison works as expected without any surprises at runtime.

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.

Avoid jQuery.bind()

When chasing down performance issues, you never know what kind of problems you will find. I was looking for something that would cause jitter when scrolling on the page. After looking at the custom code that runs on every scroll event, I still had not found a reason for the jitter. Looking at the JavaScript CPU profile when scrolling in Chrome showed that there was an overwhelming majority of the time spent in a function in the Prototype JS library.

Improve jQuery Performance With $().addClass()

When looking at things that make a website seem sluggish, you might assume that the most popular JavaScript framework out there always does things in the most efficient manner. However, as I have found, jQuery does not always produce the best performance due to it having to support many different browsers with version 1.x. As a general rule, instead of setting CSS attributes directly on the selected nodes, I prefer to instead add and remove classes on those nodes instead, as it seems to perform much better.

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.