JavaScript

From Organic Design wiki
Revision as of 09:57, 27 April 2015 by Nad (talk | contribs) (→‎Closures)

JavaScript is most commonly used as the scripting language in the browser, but is increasingly being seen on the server-side mainly in the form of Node.js, and on the desktop such as in GNOME's desktop extension system.

Technically JavaScript is classified as a prototype-based scripting language with dynamic typing and first-class functions. This mix of features makes it a multi-paradigm language, supporting object-oriented, imperative, and functional programming styles. JavaScript has been standardised in the ECMAScript language specification.

Despite some naming, syntactic, and standard library similarities, JavaScript and Java are unrelated and have very different semantics. The syntax of JavaScript is actually derived from C, while the semantics and design are influenced by the Self and Scheme programming languages.

Objects

JavaScript is a prototype-based which means that there is no explicit support for classes, it's only how instances are used within a program that determines which objects are treated as classes and which as instances. Basic objects can be created simply by using braces to collect together some named properties and methods.

<js>var foo = { 
   prop: "myProp",
   func: function() { return "myMethod"; }

};

console.log( foo.prop ); console.log( foo.func() ); </js>


For more complex objects requiring initialisation and other more advanced object-oriented features, a constructor function (having its name start with a capital letter by convention) can be used to instantiate an object using the new keyword.

{{{1}}}


All objects have a prototype property which is the name of the object it was based on, and that one has a prototype property too and so on. All the prototypes form an inheritance hierarchy back to Object.prototype, the root object.

A new instance can be created using a specific object as its prototype using Object.create(). This is how JavaScript implements inheritance, for example object B can be created using object A as a prototype, then add, override or extend its methods and properties, then other objects can be created based on object B using the new keyword as usual. See Chapter 6 of "Eloquent JavaScript" for a detailed introduction to JavaScript objects.

Scope

One of the main sources of confusion with scoping in JavaScript is that most programmers are used to the way scoping works in C-like languages such as PHP or Java. These language use block-based scoping, where every new block automatically forms a new scope in which new variables can be defined locally, and functions form a kind of scope-bubble where only the locally defined names are available (usually access is allowed to the global scope via the global keyword).

JavaScript on the other hand, uses lexical scoping which is unaffected by blocks such as for-loops or if-statements and is purely determined by the currently executing function. Functions can be defined inside other functions, which creates a scope hierarchy all the way up to the global scope. Names defined within any scope are available to all scopes within it, but not to scopes outside of it.

Another important thing to remember is that items defined by the var keyword or by function declarations are brought into the scope at the beginning of execution of that scope regardless of their position within that scope (the actual assignment takes place at the location of the definition for variables, or at the beginning for function declarations). For this reason it has become a common practice to include only one var statement at the beginning of each function which declares all variables that are used throughout it, this avoids confusion and ensures that the code reflects the reality of what's happening.

These are the most important points, but for more subtle details see this excellent short article about it, Scoping and hoisting by Ben Cherry.

Closures

An interesting aspect of JavaScript's scoping mechanism is that if the return value of a function (lets call it function A) is another function (function B), then the scope that function B was created in (i.e. the private scope that was created when function A was executed) continues to exist as long as any variable references function B. This persistent private scope is called a closure.

Closures can have both a private and public aspect, they're in the form of a function rather than an object, and are brought into existence by calling them, what's returned is the public interface. The content of the scope within the closures definition is private and exists for as long as the returned public interface exists. Usually closures are executed at the same time they're created by following the function definition immediately with the function-execution operator (round-brackets).

The following example illustrates a simple closure. The variable foo is private and can only be accessed by functions in the same private scope, or by the functions returned in the public interface. An instance of the closure is created in the variable closure by being assigned the value returned by anonymously executing the declared function.

<js>var closure = function() { 
   var foo = 1;
   return {
       bar: 100,
       baz: function() {
           console.log( foo );
           console.log( this.bar );
       }
   }

}();

console.log( closure.bar ); closure.baz();</js>


In the example above, the public function baz can access the private foo variable from it's local scope. The public interface also includes a variable bar which can be accessed publicly or via this from within the executing public interface functions. All of the items in both the private and the public scopes of the closure exist for the lifetime of the closure object.

In this next example, a single private variable is defined, and there are two public functions which are called one after the other. The first stores a secret message in the private variable which the second displays. This shows that the private local scope of the functions remains intact after the function exits and is available to all the functions. It is not available outside the scope of the functions though, any data which needs to be available outside the private scope of the closure needs to be prefixed with this. Note that if the private variable were not defined in the private scope, then the function that writes to it would create the variable in the global public scope because it's not using the var keyword.

{{{1}}}

The Module Pattern

The "module pattern" has become the industry standard for packaging up JavaScript applications and libraries designed to be used alongside other JavaScript programs. Most people are quite familiar with the form of the module pattern these days, but how it works and what it's doing remain a mystery to most. Here's an example you've most likely seen many times before.

<js>( function($, document, window, undefined) { 
   ...

}(jQuery, document, window) );</js>

Now that you know what a closure looks like, you can see that this is one. The main difference is that it doesn't return a public interface and so doesn't need to be assigned to a variable to be re-used later, it's just used once when it's created. Instead of returning an interface its purpose is to modify the environment directly, for example by extending other libraries or adding a widget to the page. Notice that the entire statement is surrounded in brackets too, this is because JavaScript treats a statement that starts with the function keyword as a named function declaration, so the brackets are required to make the interpreter see it as a statement.

Another difference with this format compared to the closure examples above is that it's passing arguments into the closure. These arguments are a useful way to pass globals into your closure such as jQuery as $. But passing globals with the names are unchanged, such as is the case here with window and document, is commonly seen nowadays and is done for three main reasons:

  • The interpreter doesn't need to walk the scope tree to find the value
  • The names can be compressed along with other normal variables when the code is minimised
  • The code can be sure that the names haven't been hijacked or modified by some other badly written code

For the third reason, you'll often see nowadays the undefined variable being added to the inner argument list but not the outer - this ensure that undefined has not been over-written with something else and really is undefined by not having an equivalent value assigned to it from the outer function's argument list.

For more in-depth information about closures, see Understanding closures, The Module pattern in-depth and Snook.ca Why I don't love the JavaScript module pattern.

Single-page applications

A single-page application (SPA), also known as single-page interface (SPI), is a web application that fits on a single web page. In an SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or partial changes are performed loading new code on demand from web servers, usually driven by user actions.

The page does not automatically reload during user interaction with the application, nor does control transfer to another page. Necessary updates to the page display may or may not involve interaction with a server. The term single-page application was coined by Steve Yen in 2005, though the concept was discussed at least as early as 2003.

Hash fragments

A central concept making single-page applications possible is the idea of "hash fragments" which is the part of the URL appearing after the first hash character. Everything after the hash represents addressing within the document, whereas everything before the hash is outside the page and requires a server to fetch the document. This allows applications to have their current state fully reflected within the URL so it can be bookmarked - this is one of the foundation principles of the web, that any state the application is in, for example a report or query result, can be bookmarked or sent to others as a URL. So the Single Page Application model is the best of both worlds - it has the dynamic feel of a desktop application having instant responsiveness without page reloads, but also has the important URL reflection quality of the web.

The most natural way of mapping application interface elements to functionality in the system model is to make the URL portion after the hash continue on in the form of path elements separated by slashes - hence the name "hash fragments".

For example:

http://localhost/#/path/into/unified/ontology/

This could also start with a normal domain name if the peer instance is running on a server connected to the web, in that case an optional exclamation mark could also be included which indicates that the paths should be crawlable by search engines, for example:

http://foobar.com/#!/path/into/unified/ontology/

pushState

pushState is an HTML5 API that offers a different way to change the current URL, and thereby insert new back/forward history entries, without triggering a page load. This differs from hash-based navigation in that you're not limited to updating the hash fragment — you can update the entire URL. Most modern framemworks that offer Single Page Application support can determine if the browser supports pushState and use it, but fall back to hash fragment URL format otherwise.

Existing SPAs

JavaScript frameworks

Graphics libraries

Tools

See also

Retrieved from "https://organicdesign.nz/wiki/index.php?title=JavaScript&oldid=119620"