Client-Side Javascript Notes

Client-Side Compatibility

The author of JavaScript: The Definitive Guide discusses client-side compatibility and comments that "Compatibility issues are simply an unpleasant fact of life for client-side JavaScript programmers." (JS:TDG 5th ed., page 257). Because of those compatibility issues, some web developers target only a certain browser and ignore others. For purposes of this class, however, you should assume that the user is using any of the "current" browsers and write your code accordingly. There are a number of JavaScript libraries and resources that can help you write code that will run in many browsers.

Two ways of addressing browser incompatibility are using the Can I Use web site and doing feature testing.

Can I use...

The Can I use..." website is very helpful for seeing which browsesrs support which features. You can find that web site at Knowing which browsers have implemented which features is extremely useful. I encourage you to take a look at the site, especially the HTML5 and JS API categories.

Here's the Can I use... ECMAScript 6 compatibility table:

Feature testing

Feature testing is the idea of using JS code to see if a particular feature is available in a browser. For example, a web site might use an HTML5 canvas to draw graphics on a page if it's available. The feature-testing code can attempt to create a canvas element and then set a flag based on the result. You can see some examples of feature testing code at

Here's a link to an MDN (Mozilla Developer Network) article about feature testing:

If you wonder what people mean when they talk about browser sniffing (and you want a good laugh), read this: History of the browser user-agent string

Same-origin policy and JavaScript security issues

The same-origin policy states that JavaScript code is not allowed access to HTML documents that were not loaded from the same origin as the document that contained the JavaScript code.

For example, suppose that a web browser loads an HTML document, A.html, from Server A. Also suppose that A.html contains a script tag for a JavaScript file, A.js. Then the browser loads another document, B.html, from Server B. The code in A.js has full access to A.html but has no access to B.html or documents from any server other than Server A.

Note that an HTML document can contain script tags that load JS from a different server than the server from which the HTML document was loaded. No matter what server the JS code is actually loaded from, for purposes of the same-origin policy the JS code is associated with the server from which the HTML document was loaded.

An origin (or server) is defined as the combination of the protocol (like http or https), the host name, and the port number.

You can read about the same-origin policy in this Wikipedia article:

Another important JavaScript security issue is cross-site scripting, where JavaScript is embedded in user input. It's best to remove HTML tags from user input to avoid problems with cross-site scripting.

Model View Controller (MVC)

Model View Controller (MVC) is a design pattern that is used in many different kinds of programs. The basic idea is to separate the model from the view so that they only communicate indirectly through a controller.

The model contains application-specific objects (or functions and data) and does not contain any information about how that information will be displayed to the user. For our purposes, that means that the model does not contain or generate any HTML, CSS, or images. You can think of the model as representing the rules of the game and the current state of a game being played. For example, the model for chess could include functions that determine what is a legal move, along with the positions of the pieces on the board. That model can be used with any chess set (view).

The view displays the model to the user. In our case, the view will generate HTML that the player sees in a browser window.

The controller acts as a go-between for the model and view.

Some advantages of MVC are:

Here are some slides that I made about the MVC design pattern, along with a video presentation of the slides:
slides (PDF)      video      video script

You can read about MVC in Chapter 10 of the book Learning JavaScript Design Patterns. The book is available at That chapter goes into a lot more detail than we need for this class. The chapter mentions several JavaScript libraries, like Backbone.js. Although we aren't using those kinds of libraries for our assignments in this class, they are very important in web programming and it's good to know what libraries are available.

There are many different interpretations and variations of the MVC pattern, but for this class the most important concept is to separate the model from the rest of the application. That gives many of the advantages of MVC without getting into the complexity and details of some descriptions of MVC.

Unobtrusive JavaScript and progressive enhancement

The idea of unobtrusive JavaScript is that the JavaScript code on a web page makes the web page better for users that have JavaScript enabled but does not cause problems for users who have disabled JavaScript or who use browsers with no JavaScript capability. You can read about unobtrusive JavaScript here:

A related idea is the idea of progressive enhancement, which means that a web site is functional and useful even for a limited browser, such as the browser on a flip phone, but provides more features for browsers that can support them. You can read about progressive enhancement here:

Threads and web workers

There is no threading mechanism in core JavaScript, so it's single-threaded. However, in a browser, you can use timers to handle some situations that you might otherwise handle with threads. You can read about that in this sitepoint article:

More importantly, there is a feature called web workers that provide a way to run scripts in the background. It's well supported by current browsers, as you can see on this page at You can read about web workers here: