The Five Biggest JavaScript Misconceptions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
One of the greatest attributes of JavaScript is also a negative: It’s an easy language to use. When you couple that fact with the demand for JavaScript, you end up with developers and designers using the language without a full comprehension of it in its own right. In time, most beginners do learn that JavaScript is not Java and that it’s not a “toy” language, but in this article I present five more important misconceptions. A couple of these should be obvious, but are worth being reminded of, particularly to those relatively new to JavaScript. A couple other misconceptions aren’t obvious, but have relatively simple resolutions.
Assuming Everyone Has JavaScript Enabled
When you’re just beginning with web development, there’s a tendency to assume that every user surfs the web just like you: with the same current browser, a large monitor, and a fast connection. Of course, that’s clearly not the case. In particular, most users will not have the same browser and version[md]no matter how many you regularly test on, and a small number of users will not be able to run JavaScript on your site at all. This could be because:
- They’re using a device that doesn’t support JavaScript.
- They’ve actively disabled JavaScript (for whatever reason).
- They’re using a JavaScript blocking extension, such as Firefox’s NoScript.
Whatever the reason, it’s important that you’re aware of this possibility when developing a site. This means that you adhere to progressive enhancement: Create the minimum functionality first, and then enhance that functionality using JavaScript. In the rare situations where a site would absolutely require JavaScript, make that obvious and indicate to users that JavaScript is required, should they not have JavaScript enabled.
Thinking that JavaScript Will Improve Your Site’s Security
On a similar note, some developers mistakenly think that JavaScript can improve a site’s security (this applies to client-side JavaScript; server-side JavaScript can be a security tool). Client-side JavaScript cannot be used as a security tool for a very simple reason: because JavaScript can be disabled. If your site attempts to use JavaScript for security purposes, such as the validation of form data, all a hacker has to do is disable JavaScript to circumvent your security (or create his or her own form that gets submitted to your system). Form validation with JavaScript is a convenience to the user, but server-side security measures are always necessary.
Using a Framework (like jQuery) Without Knowing JavaScript
The rise of frameworks has been instrumental to JavaScript’s standing in today’s web. The ease with which developers can create reliable cross-browser code with jQuery, in particular, has led to the misconception that you can use a framework without actually knowing JavaScript. This is unfortunate, as it has no doubt led to many quirky, poorly performing, potentially not secure web applications (which also wrongly reflect poorly on the framework itself).
Frameworks are merely a tool to expedite development. Frameworks are not a replacement for an actual language. In fact, without knowing the underlying language or development process, trying to use a framework will be harder, not easier.
Believing It Is Difficult to Write Reliable Cross-Browser JavaScript
Fifteen years ago, there were only a couple of browsers, with one or two common versions of each. Back then, it was easy for developers to know what browsers were capable of, in terms of features or bugs. For some reason, developers got into the unfortunate habit of writing code aimed at specific browsers. This involved an approach called browser detection or browser sniffing:
if (navigator.appName == "Netscape") { // It's Netscape!
if (parseInt(navigator.appVersion) >= 4) { // At least version 4!
} else { // It's an earlier version. Bah!
}
} else { // Let's assume it's IE?
}
This may have seemed like a good idea at the time, but with each new browser version, code can become outdated and useless. When entirely new browsers are created, they might not work at all with such code, even though the new browsers are presumably better than the older ones the code targeted.
Fifteen years later, the commonly used browsers include Chrome, Firefox, Internet Explorer, Opera, and Safari. That list doesn’t mention less common browsers or the browsers built into non-standard devices, such as electronic readers, mobile phones, and gaming systems. Further, these common browsers are readily found in multiple versions; IE alone currently exists in versions 6, 7, 8, and 9! This might lead developers to think that writing code in such a way that works reliably across all browsers and devices has become more difficult, if not impossible. The truth is that it’s become easier, due to an obvious, yet brilliant, change in approach: object detection.
As an example of this, let’s take a look at the String object’s trim() method, added in ECMAScript 5. Many modern browsers support this method, although Internet Explorer does not (at the time of this writing). Instead of checking the browser name to know whether it’s safe to use this method, just see if the method exists to be used:
if (typeof someStr.trim == 'function') { // Safe to use!
That’s all there is to it. If the property in question is a function, it can be used like a function! This approach is simple, safe, and reliable. (There’s an alternative syntax that checks if the property in question is defined in the object’s prototype, but that syntax requires a more advanced discussion.)
Not Knowing That You Can Create Your Own Custom Objects in JavaScript
JavaScript is an object-oriented programming language, but it’s unusual in that it’s prototype-based, not class-based. This means that every variable you create is based upon an object prototype, not a class definition. This also means that you cannot define your own classes as the basis for a variable. From this, some new to the language erroneously think that you cannot create your own custom objects in JavaScript. The truth is that you can, using a couple of approaches.
To create a single custom object, just define a generic Object with the properties and methods you need:
var me = {
firstName: 'Larry',
age: 54,
doSomething: function() {
// Method code.
}
};
In many situations, this solution is fine, but it does not allow you to create multiple instances of the same object type. To do that, you must use a constructor function. A constructor function is defined just like any other function in JavaScript, with two exceptions:
- Conventionally, a constructor function uses an initial capital letter for its name.
- The function should not have a return statement.
Normally, constructor functions take some arguments whose values will differentiate one instance from another. Within the function definition, the this keyword is used to store those values in the variables of the current instance:
function Person(firstName, age) {
this.firstName = firstName;
this.age = age;
doSomething: function() {
// Method code.
}
}
Finally, to create an object instance, use the new operator before the function call:
var me = new Person('Larry', 54);
Now, the me variable is an object of type Person. Here is another Person variable:
var you = new Person('Samantha', 45);
You can use these objects as you would any other, accessing their properties and methods as needed:
me.firstName; // Larry you.age; // 45
This is possible in JavaScript because functions in JavaScript are “first-class citizens,” meaning they are also objects. Each use of new creates a copy of the original function definition, this time with particular variable values, resulting in a custom object.
Conclusion
Despite the fact that JavaScript is one of the most widely used and important programming languages, there are many misconceptions about it, and about how best to use it. There are misconceptions and misuses with any language, of course, especially for those new to it, but JavaScript’s accessibility seems to magnify the problem. I hope that this article has helped to disabuse you of a misconception or two. If so, don’t be embarrassed: It’s never too late to learn!