The evolution of client-side scripting

In the past years browser makers have been working very hard to improve their scripting engines and add new DOM APIs. There are currently so many projects going on that it sometimes starts dazzling me and I have a hard time to keep track of which feature belongs to what project or has been included in which browser. This article attempts to give an overview of all the major innovations that have recently arrived or will hopefully come our way soon.

Improving the core language

JavaScript was originally created by Brendan Eich and was introduced in December 1995 in Netscape Navigator 2 as a client-side scripting language to add interactivity and dynamic behavior to web pages. Due to the success of JavaScript Microsoft developed a similar scripting language named JScript and released it with Internet Explorer 3 in August 1996.

Netscape submitted JavaScript to Ecma International resulting in the standardization of the language under the name ECMA-262 a.k.a. ECMAScript. Both JavaScript and the JScript dialect aim to be ECMAScript compliant, while providing additional features not defined in the specification. ECMA-262 edition 1 was published in 1997, edition 2 in 1998 and edition 3 in 1999.

Today ECMAScript 3 is the de facto standard for client-side scripting, because it is supported by all modern browsers. Opera, Safari and Chrome include their own implementations of JavaScript, while even ActionScript - the scripting language of Flash - and the JavaScript API included in Silverlight are based on the specification.

After the completion of ECMA-262 edition 3, significant work was done to develop edition 4. However, ECMAScript's technical committee was split, with some members favoring ECMAScript 4 and others advocating ECMAScript 3.1, which is more modest in both semantic and syntactic innovation. After the 'Oslo meeting' in July 2008 both groups were reunited and agreed upon a new direction and roadmap:

  • ECMAScript 4 was abandonded, due to political differences concerning language complexity. Because currently only ActionScript 3 is based on ECMAScript 4, the impact of this decision is that ActionScript will no longer be compliant with new versions of ECMAScript.
  • ECMAScript 5 (previously: ECMAScript 3.1) was published as a final draft, planned to become a specification in December 2009.
  • ECMAScript Harmony (likely to be renamed to ECMAScript 6) will be the next-generation version of ECMAScript.

The goal of EcmaScript 5 is to add improvements to make the language more robust, remove some inconsistencies and establish a foundation for future versions of the specification. To achieve this it includes new features as accessor properties, reflective creation and inspection of objects, program control of property attributes, additional Array manipulation functions, native JSON and a strict mode that provides enhanced scoping, error checking and program security. More info [1] [2] [3].

Furthermore, two new specifications to extend ECMAScript were published:

Despite the slow development of the ECMAScript specification in the past decade, the Mozilla Foundation has been constantly developing JavaScript:

  • JavaScript 1.5 (Netscape 6/Mozilla, 2000) is ECMAScript 3 compliant.
  • JavaScript 1.6 (Firefox 1.5/Mozilla 1.8, 2005) includes Array extras, Array and String generics and E4X.
  • JavaScript 1.7 (Firefox 2, 2006) introduces generators, iterators, Array comprehensions and block scope with let.
  • JavaScript 1.8 (Firefox 3, 2008) includes generator expressions and expression closures.
  • JavaScript 1.8.1 (Firefox 3.5, 2009) introduces native JSON, Object.getPrototypeOf() and new trim methods on the String object.

The decision to kill off ECMAScript 4 did fortunately not have a big impact on JavaScript's current state. Today some ECMAScript 5 features are already supported, while JavaScript 1.9 will likely introduce full ECMAScript 5 compliancy. Many of JavaScript's latest additions have already been implemented in several modern browsers.

JScript has also gone through various revisions:

  • JScript 5.5 (Internet Explorer 5.5, 2000) aims to be ECMAScript 3 compliant.
  • JScript 5.6 (Internet Explorer 6, 2001) includes a series of minor updates.
  • JScript 5.7 (Internet Explorer 7, 2006) introduces ECMAScript CP.
  • JScript 5.8 (Internet Explorer 8, 2009) introduces native JSON and and accessor methods for enabling DOM prototypes [1][2]. Microsoft also published where JScript doesn't comply with ECMAScript 3 [1][2].

The next version of JScript will likely aim for ECMAScript 5 compliancy. We may also conclude that in the past years browser makers paved the way for future versions of ECMAScript.

Introducing new DOM APIs

While it is important to improve the core scripting language to create more robust functions and applications, it is of equal importance to add new functionality to browsers and expose this via the DOM. Unfortunately the latest HTML recommendations date from 1999 (HTML 4) and 2000 (XHTML 1). This slow development can partially be subscribed to the failure of XHTML:

  • Limited cross-browser support, especially because Internet Explorer still doesn't support the proper application/xhtml+xml MIME type.
  • XML parsing appeared to be unpractical for Web pages, because it makes them break very easily.
  • XHTML2 is not backwards compatible and is still under heavy debate. UPDATE July 3, 2009: The W3C has stopped working on XHTML 2 and will increase its effort on HTML 5, also to clarify W3C's position regarding the future of HTML.

After almost a decade of XHTML we can conclude that an entire XML based Web is an utopia. On the client-side both the adoption and innovation process has halted, so it has become time to move on.

Enter HTML 5. Although still an editor's draft HTML 5 already looks promising, because it is practical, innovative and real:

  • It is backwards compatible with HTML 4.
  • It's DOCTYPE can already be used cross-browser today.
  • It standardizes existing proprietary features.
  • It introduces practical new parsing rules and flexible error handling.
  • It is heavily backed by Mozilla, Apple, Opera and Google.
  • It introduces a heap of new browser features of which some are already suppored by the latest Web browsers.

An overview of new APIs introduced by HTML5:

Although most of HTML 5's new features are not ready for prime time yet on the desktop, some of them can already be very interesting for developers that build applications for the mobile Web, where Webkit based browsing on iPhone and Adroid currently dominates the market. A good example of this is Gmail for iPhone/Android, which already uses HTML 5 functionality [1][2].

Besides HTML 5 there are a couple of other very interesting new standardization projects.

The W3C Geolocation API Specification (editor's draft) defines a simple API that provides scripted access to geographical location information associated with the hosting device. The specification is scheduled to become a recommendation in Q4 2009. It is already included in Firefox 3.5, Mobile Safari on iPhone 3.0 and Opera nightlies. My previous article gives a good overview of location aware browsing.

The W3C Selectors API (working draft) gives JavaScript developers the ability to find DOM elements on a page using CSS selectors. The API simplifies the process of traversing and selecting elements from the DOM and offers a highly improved lookup speed performance. It is already included in Internet Explorer 8 [1][2], Firefox 3.5 [1][2], Safari 3.1 and Chrome 2.

The W3C Accessible Rich Internet Applications (WAI-ARIA) specification (working draft) defines a series of methods to make dynamic Web content and Web applications more accessible to people with disabilities by defining how certain functionality can be provided to assistive technologies. WAI-ARIA is already supported by Internet Explorer 8, Firefox 3, Safari 4, Chrome 2 and Opera 9.6. More info [1][2].

The WHATWG Web Workers draft recommendation specifies an API that allows JavaScript developers to spawn background workers running scripts in parallel to their main page. This allows for multi-thread-like operations with messaging as a coordination mechanism. Web workers are already included in Firefox 3.5, Safari 4 and Chrome 2.

When it comes to the DOM we can conclude that there is a whole lot of innovation going on. Although time will tell when certain features will become available cross-browser, it's great to see that browser makers are both collaborating and competing to develop new browser functionality and Web standards.

Improving the performance of JavaScript engines

Faster engines are key for JavaScript to mature as a language. It enables developers to create more complex and better performing applications that can better compete with their OS and plug-in counterparts.

In the past year browser makers have been in a constant race to improve scripting performance. As a result a new generation of JavaScript engines has arisen that gained an incredible performance boost, by implementing techniques like just-in-time compilation (JIT), inline caching and trace trees. These new engines are:

Conclusion

Although the past decade may have been influenced by processes of political stagnation and consolidation, it also contained a lot of innovation and a return to practical Web development. Is this the silence before the storm? I hope so.

I also hope that this article has given you a good overview of what is going on in the client-side scripting world and has shed some light on what the status of things are today. Are you excited about all of these new developments? I am!

Comments

None