This article is the author's thoughts and assessment about programming language JavaScript 2.0; maybe from this article, you will understand more information about JavaScript as history, specialized features,...

• Demo
• Enlarge
• Reload
• New window

As a developer and writer, part of my job is to stay informed of current trends in the web world, whether it be company mergers, online-shopping trends, or programming technologies. I'll admit that it's hard to keep up with everything that's going on in the industry these days, but one tidbit of news is making the rounds that is raising a lot of eyebrows: the drafting of the JavaScript 2.0 proposal. The new JavaScript 2.0 / EMCAScript 4.0, isn't due to be finalized until the end of the fall of 2009, but it's already garnering lots of strong reactions - both good and bad. Today, we'll be taking a look at some of the proposed specifications and you can decide for yourself whether they constitute improvements in the language or merely unnecessary standardization.

The JavaScript Story

To better understand how JavaScript standards are implemented, let's take a brief look at the language's history.

JavaScript is a dialect of the ECMAScript scripting language, which is standardized by Ecma International. The other two dialects are ActionScript (MacroMedia, Adobe) and JScript (Microsoft). JavaScript was originally developed by Brendan Eich of Netscape. It was originally called Mocha and then LiveScript, before finally being renamed to JavaScript. Sun Microsystems released Netscape Navigator 2.0 with support for JavaScript in March of 1996. Due to the widespread success of JavaScript as a client-side scripting language, Microsoft developed their own version of the language named JScript, which was included in Internet Explorer 3.0 release of August 1996. Netscape submitted JavaScript to Ecma International for standardization, in Geneva.

Ecma International is an international, membership-based, non-profit standards organization for information and communication systems. The organization was originally founded in 1961 to standardize computer systems in Europe. In the 40 odd years since its inception, Ecma has produced more than 370 Standards and 90 Technical Reports, including CD-ROM volume and file structure, C++ Language Specification, and their Open XML format. The first edition of ECMAScript (ECMA-262) was adopted by the ECMA General Assembly of June 1997. Both JavaScript and JScript aim to be compatible with ECMAScript, while providing additional features not described in the ECMA specification. Even today, the JavaScript and JScript dialects have as many differences as commonality. JavaScript was influenced by Object-Oriented languages like Java and C++, but was meant to be easier for non-programmers to work with.

Language Enhancements

More Object Oriented

Up until now, JavaScript used prototypical inheritance rather than the classical OOP kind for inheriting from parent classes. In fact, as the following code demonstrates, there currently exists no such thing as a "class" in JavaScript:

Functions double as object constructors along with their typical role. Prefixing a function call with new creates a new object and calls that function with its local this keyword bound to that object for that invocation. The function's prototype property determines the new object's prototype. Whatever is assigned to an object's prototype property is shared amongst all of its instances and children. Using the prototype property, it is possible to simulate many class-based features in JavaScript, albeit with some quirks! For instance, in the following code, myOtherDog attempts to override the getBreed() function of parent Dog "class". Although the myOtherDog's getBreed() function is indeed implemented, it does not hide the parent's, giving myOtherDog two breeds!

Strong Typing

Like most scripting languages, JavaScript is loosely typed. The interpreter determines which data type should be used at runtime based on its value. This looseness affords the developer a lot of leeway for variable reuse and comparisons. In the latter case, type coercion is what makes comparison of two different data types possible; JavaScript automatically makes them the same type before performing the check:

In contrast, JavaScript 2.0 will be strongly typed, meaning that type declarations will be enforced instead of being coerced by the scripting engine. A type can be assigned to properties, function parameters / return values, variables, or object / array initializers. If no type is defined, the variable or property defaults to a type of Object, which is the root of the data type hierarchy. The syntax for applying a given type will be a colon (:) followed by the type expression:

To perform comparisons like those above, you will need to cast the data type:

Program Units

Borrowing from popular JS Frameworks, programming units are reusable code modules that can be imported at runtime. These have become an essential component of web apps as the size of framework and custom libraries increases. Considering that some libraries contain thousands of lines of code, loading everything at once just doesn't make sense anymore. Here is the proposed code:

Compile Time Type Checking

You will have the ability to compile JavaScript 2.0 components in strict mode. This will test the integrity of several key aspects before execution, including:

• Static type checking
• Verification that referenced names are known
• Checks for illegal assignments to constants
• Insure that comparisons are only made between valid types

Constants

Previously JavaScript developers have had to either rely on naming conventions or elaborate workarounds to protect their constants, but come JavaScript 2.0, that'll be a thing of the past:

Real Namespaces

With the emergence of JS Frameworks, the use of namespaces has really become a necessity. The standard up until now has been to create a global object to house all of your functionality so that pre-existing global objects and functions don't get clobbered.

Conclusion

Some of the detractors to the 2.0 proposal take issue with the movement towards classical programming languages like C++ and Java. Tom Steinert-Threlkeld voiced his concerns in a recent blog

"...the dynamic and flexible nature of JavaScript's prototypal inheritance and object model...is a practical, fundamental advantage. Why someone would want to take something so elegant and flexible and turn it into Java - which essentially forces a programmer to use classical, class-based inheritance - is beyond me."

I personally have mixed feelings about the new proposal. While I welcome changes such as classes, namespaces, and constants, I don't like the idea of strongly typed scripting variables. Overall, the language is at risk of becoming too rigid, and by extension, serious, for the average amateur programmer. Then again, maybe I should be thankful that more owners of commercial websites will require the services of a professional like me to code their business processes! Whatever the outcome, there can be little doubt that the web development landscape is about to be drastically altered!

• Code
• Print

• Comment (0)
• Write

by Preview

Cancel reply

Write your comment

Comment's title

I assure 100% I am real human
I repeat I am not bot

• Sent (0)
• New