|
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!
|