JavaScript 2.0: A Sneak Preview | 2 | WebReference

JavaScript 2.0: A Sneak Preview | 2


[prev]

JavaScript 2.0: A Sneak Preview [con't]

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!

Original: July 20, 2009


[prev]