The final code - compare with John's port:

A couple points to note:

• .liveUpdate() no longer takes an element ID - it now accepts any jQuery selector (this is the only notable API change that I made).
• All state is stored in simple variables and accessed via closures, as opposed to as properties of an instance object.
• Only one function is used - and that's stored away within the function itself (greatly simplifying the resulting code).
• DOM queries are only done once and cached up front.
• .map() is used to simplify the creation of new arrays of information.

HOWEVER - I will contend that such a thing as plugins exist and are logically distinct from "random JavaScript code that manipulates other JavaScript code" as long as the following points are met:

1. There have to be explicit points upon which a plugin can attach. James notes the most common one in jQuery (jQuery.fn) but we have tons more - events, animations, selectors - all over the board for developers to snap in to.
2. Even more importantly: Those points have to be documented or, at the very least, be under some sort of agreement that they will be treated like a normal piece of the user-facing API. In jQuery we treat all plugin extension points as "user-facing API" and only ever change them in major releases (if at all) and always provide an alternative for authors to use.
3. Finally, there has to be some sort of repository for navigating these plugins. This is a huge differentiator. Simply referring to "code in the wild" as plugins doesn't really cut it if there's no commitment to hosting them and keeping their documentation and examples alive.

We take our plugin architecture very seriously in the jQuery project and are constantly looking for ways to improve (looking at plugins, reading their code, seeing what we can provide to make their lives easier).

Alex Russell of Dojo recently built a sleek 6kb version of Dojo - presumably for use on mobile platforms. He states in his post that:

Even so-called “lightweight” libraries like jQuery are far too heavy for some environments…not because they (like Dojo) pull in all the code needed to use them, but because they do it all up-front. Often the best time to pay the expense of loading, parsing, and executing JavaScript code is when the user takes an action that needs the enhancement to run.

The way it's worded you would assume that you were paying a large, up-front, cost to using jQuery when, in fact, there is very little overhead. jQuery has been shown to be the fastest loading JavaScript library for non-cached code and considerably fast for cached code.

Arguably a mini-Dojo would be able to provide an extra edge in this respect - however any gains that you would make up-front (which would be minimal - mini-Dojo is only about half the size of jQuery, as it stands) would have to contend with any future overhead incurred by loading additional components at a later time.

I frequently queue up long pages to read on my iPhone while I travel the subway system here in Boston and I think I'd be quite upset if I got halfway through a page, clicked a hide/show link, and found out that the action wasn't able to work since the requisite functionality hadn't been loaded yet.

There is a cost to loading "all" of jQuery up front, absolutely - however there are numerous benefits: It's highly cacheable, you never have to worry about what you do/don't have loaded, the API, documentation, tutorials, and examples are all dramatically simpler since you never have to worry about having extra components or making sure that they're being included correctly.

And, as always, if you're particularly excited about breaking jQuery down into little chunks you can grab the individual pieces from SVN and build a custom copy.

I was out of town when it happened but the release of the Google Ajax Library CDN (which includes the current release of jQuery) was incredibly cool. I've had a few requests from users wondering how this release came about. While I can't speak for the other projects, I can, at least, speak for what happened with jQuery.

Dion and I had been discussing solutions for providing better hosting solutions to JavaScript libraries for a long time (at least a year or two). Progress kept getting stalled at different points but persevered and got the release up at Google. I'm really glad to see this come about and I'm sure that jQuery users will certainly appreciate this release.

I have a couple points of concern with the release, namely:

• How do we push a new release out? Currently we have to contact the guys at Google to get it pushed through - a way to automate this and do it programatically would be greatly appreciated (we could integrate it right into our release scripts).
• How do new pieces of code get added? There's no way for other projects to get added to the repository - some sort of process for joining would be ideal.
• SSL? Having an SSL-based CDN would be very useful, as well. However I suspect that if a site is going so far as to have SSL on their pages then they're probably not pulling their source code from an external site.

Other than that, though, I'm quite pleased with the release. The more that people pull from there the faster it'll be for everyone who uses JavaScript libraries (cutting away that initial download time).

I think the common response to seeing the above was something like: WUH!?!?

As can be seen in the ensuing discussions.

Perhaps more interestingly is the dig in to try and figure out how on earth this feature made it in to the language to being with. Brendan Eich provides some insight:

3.2 <fur> 1998-04-23 17:30: Initial checkin of JavaScript 1.3, migrated from JSFUN13_BRANCH in /m/ src repository

This eval extension, if memory serves (I was in mozilla.org at the time, not in the JS group at Netscape) originated in conversations with Microsoft's rep during ECMA-262 standardization, trying to reach agreement on a way to eval in other scopes.

At this point, however, it's pretty safe to say that since so few people know about it, and that (hopefully) there are no important sites relying upon its behavior, it can be stricken from the record.

Which it has been.

It's been a crazy ride but you can expect to see this feature gone in Firefox 3.1 (the next release of Firefox, set to debut this year).

Unsurprisingly, my personal development style mirrors much of the general web dev public. But what I find most interesting is to try and track trends in web development that Firebug has single-handedly revolutionized.

Firebug Advances

Performance Profiling

Prior to Firebug there was only rudimentary analysis of JavaScript performance (using tricks like injecting timers and computing the difference). Firebug brought us the ability to analyze all function calls during a period of execution, see how they each affected each other and, probably most important, see the difference in the sub-millisecond range.

Previously none of these techniques were possible with pure-JavaScript techniques - having the ability to tap into the JavaScript engine (which Firebug does) is fundamentally important to getting good analysis.

You can see an immediate interest, by JavaScript library authors, in the performance of their code bases around the time of Firebug's introduction of profiling.

Console logging with object introspection

Logging statements has always been possible with JavaScript (and, most infamously, with the alert() function) however Firebug gave us something significant: The ability to click and introspect into logged objects. This includes the ability to click DOM nodes (and see their properties and methods) and even normal objects (like Arrays or Object literals).

Firebug has to maintain a lot references to point to where these objects exist - and it wouldn't be possible in pure-JavaScript without introducing an excessive number of memory leaks.

Current Styles / CSS Rules

There had existed some tools for examining the current CSS style values of a DOM element (such as its dimensions and positioning) but Firebug brought a whole new level of inspection: The ability to see which stylesheet rules were introducing specific styling on an element. Not to mention the ability to edit the rules in-line (along with disabling them outright).

This level of inspection completely overhauled Web Design - and has been able to detach many web designers from their IDE-of-choice into a more agnostic view of CSS design. Absolutely the biggest short-coming of this feature is its inability to work cross-browser (although, that argument can certainly be used for most Firebug features).

Network Performance

Firebug's network tab gave developers the ability to see - in very real terms - two things: 1) How long a resource was taking to load and 2) How the loading of that resource was blocking the loading of other resources. #2 is especially important, seeing that the execution of JavaScript blocks other actions from occurring can be an eye-opening experience to most developers. Or even seeing how a slow-loading stat tracking script can prevent the further display of the page.

XMLHttpRequest Inspection

While XMLHttpRequest use existed prior to the existence of Firebug it was horribly hard to debug - it was rarely obvious where errors were occurring - on the client-side? on the server-side? in the transmission? The ability to see how the requests occurred - and very importantly - how long they took (and even how frequently they occurred!) has done much to improve the overall quality of Ajax use on web pages.

JavaScript Debugging

I would've said that JavaScript Debugging was a piece of that equation, as well, however Venkman definitely lead the way, in that respect (and has been a de-facto debugger for quite some time).

I'd argue that these trends wouldn't be where they are right now if it weren't for Firebug - and that tools are the primary reason for a development strategy's success. As a corollary look at the relative success of web standards - I'd argue that adherence to HTML or CSS wouldn't be where it is today without the tools to verify a page's compliance.

How to Improve

The question now becomes: What are the next set of tools that Firebug can introduce that will revolutionize its respective areas of development?

I'd like to propose a couple, possible, areas of interest:

JavaScript Library Analysis

As it stands Firebug's JavaScript function analysis is, perhaps, too finely-grained to provide help in many instances - especially when the use of JavaScript libraries is at play. For example, when using jQuery, you're generally more concerned with finding out how fast, or slow, a particular method is - or a selector - not the performance of all the individual internal methods of jQuery.

I began some of this analysis with my Deep Profiling jQuery Apps experiment but that's really only a test. Smart integration of JavaScript library knowledge into Firebug can provide significant details about how your code should be performing.

Visual Performance Profiling

Application performance profiling is rather clumsy right now, we have a number of disparate resources (network performance, rendering performance, script performance) that we need to mentally merge to create a full picture of what's happening. To counter this I'd like to propose a way of visually viewing how components of a site affect its overall performance. Perhaps a way to break things down like this:

• Header: 300ms: 20ms Transmission + 20ms Parsing + 60ms CSS + 200ms JavaScript
• Google Ad: [BLOCKING RENDERING] 600ms: 20ms Transmission + 20ms Parsing + 20ms CSS + 240ms JavaScript + 300ms Frame Loading
• Sidebar: 400ms: 40ms Transmission + 40ms Parsing + 80ms CSS + 240ms JavaScript

The YSlow Firebug plugin already provides some level of analysis on your site - but it's much more holistic (giving you generic tips for files and pieces of code). Whereas a more specific approach would be greatly appreciated.

Ajax Improvements

We currently have the ability to view XMLHttpRequests as they occur, which is great, but some additions could be made that would serve to be quite helpful, such as:

• The ability to manipulate a request and re-submit it. If you're attempting to see how different inputs will affect your site, this would be a great way to play back requests or see how they can be best improved.
• Right now Firebug only lets you know the basic textual output that's coming from the server-side. Having it be able to tell you if incoming XML, JSON, or even HTML is syntactically correct (and even being able to navigate the resulting structures - as the browser would see them) would be a huge boon. As it stands it can be quite frustrating to receive a slightly-malformed response from a server and be stuck trying to figure out what's going wrong.
• Better JSON/JSONP integration is essential. There are a large number of Ajax requests being done through dynamic script tag injection - and those are completely unmonitored by Firebug's XMLHttpRequest tracking. Being able to see what requests and responses look like - and where errors may be occurring - would be immensely useful.

Rendering Performance Analysis

While we have fantastic tools for digging in to the performance of JavaScript - CSS is a complete unknown. How much overhead do our stylesheets provide? How many elements does this CSS rule affect? Does this rule cause a costly reflow to occur? and how many times? How long does it take to render a particular portion of a page? Would changing the structure of my page help to improved perceived rendering speed?

Virtually all of these questions are un-answered and we need a tool to help provide a solid response.

Security Analysis

Security is one area that has seen virtually no attention in the respect of user tools. Most developers have no idea how secure their web site is or how vulnerable it may be to attacks. There needs to be easily-accessible tools for testing:

• SQL Injection attacks
• XSS Injection
• Susceptibility to Spoofing (Data Encryption)

At the very least. The problem here is that while these tools will be incredibly useful for developers to improve their web sites - it'll also encourage malicious behavior. Although, arguably, those that wish to be malicious already have the tools to do so.

Standards Integration

Inline support for analyzing the standards-compliance of a page. Being able to see notes next to specific elements, attributes, CSS rules, etc. that show information on how they don't comply with particular standards - or even how they could be improved to match standards.

This includes inline strictness warnings for JavaScript (produced by the JavaScript engine).

I think that compliance should go a step further, as well, and look to provide information on Microformat and RDFa compliance - pointing out specific errors and helping sites to become better formatted.

Finally - RSS and Atom standards compliance. Notifying a developer that their site's RSS/Atom feed is malformed would allow them to immediately make a more compliant feed (a common area of mistakes).

Internet Explorer Support

The final, and perhaps most difficult, item that should occur would be a port of Firebug over to Internet Explorer. Both Safari and Opera have web developer tools integrated into their browsers - however Internet Explorer still consumes a majority market share and there's no good tools in sight. (I, personally, use CompanionJS but it's still a far cry from the full suite of utilities that Firebug provides - especially in the realm of DOM/CSS.)

This could probably be remedied if there was a really good pure-JavaScript Firebug (although the overhead associated with many of Firebug's features would lead to an astronomically-sized implementation). The current "Firebug Lite" is something of a joke - only vaguely functioning in modern browsers.

Not only do I want to see Firebug improve - it's imperative that Firebug continue to improve, for the sake of web developers everywhere. If it simply stalls and works into a stasis of bug fixes then web developers will be stuck with the current set of tools for quite some time. While other browsers are improving at a rapid pace, it'll still be quite some time before they are able to match the current feature-set of Firebug.

Since so much of web development ecosystem is currently linked to the health of a single tool advances have to be made now and they have to be made quickly in order for the web to flourish and survive as a development medium.

Chris has posted a ton of details concerning how the application works. I've had the opportunity to follow his development for a while now and heard about all the interesting issues that he's tackled - related to Python, databases, scaling, and jQuery. I love seeing "for fun" applications finally come to light - and this one is a keeper.

David Baron, a Mozilla developer, has a write-up on the new CSS features that are available in Firefox 3. There's a mix of additions - everything from CSS 2.0 and 2.1 features to new additions that are tracking CSS 3.

Some of my favorite additions include:

The CSS 3 Box Specification (in the form of -moz-max-content, -moz-min-content, -moz-fit-content, and -moz-available values to width, min-width, and max-width).

-moz-fit-content actually does let authors do some things that previously weren't possible without tables, such as putting a background on headings that doesn't fill the whole width of the container unless the heading does, but is a single rectangle if the heading breaks to multiple lines (see Demo).

Wrapped whitespace (white-space: pre-wrap). This allows you to have a <pre/> whose contents are wrapped nicely, while still maintaining its rigid structure.

rgba() values. You can now apply opacity directly to background colors (as opposed to having to create a shim div/span and styling that instead). Note that the below text is fully opaque.

inline-block and inline-table Such a powerful addition - and one that now brings Firefox in line with most other browsers. It'll allow you to create much-more-complicated layouts that were previously very trying to implement using normal CSS. Demo.

First, Drag this to your bookmark bar: Twitter Reply

Second, visit a tweet: http://twitter.com/jeresig/statuses/841204003

Then hit the bookmarklet and you should be taken to the reply screen with "@jeresig " (or whatever the appropriate username is) already pre-filled in. Enjoy!

P.S. As a bonus it maintains the http/https URL protocol, as well.

First 24 hours: 8.3 million downloads, 69 downloads/second, 20 Gb/s Peak Transfer

While I generally focus on issues tangential to JavaScript code, at Mozilla - like testing, performance analysis, specifications, standards, bug hunting, speaking, demos, and blogging - some of my code is live within the browser, and that makes me quite happy.

One of my first tasks at Mozilla was to, with Mark Finkle, develop a JavaScript API for performing common interactions typically desired by extension developers, called: FUEL. This is a pure-JavaScript implementation that sits as a proxy inbetween the developer and the various, traditional, XPCOM-style ways of performing actions.

If you're interested in learning more about FUEL I've collected a number of links and examples:

The Development of FUEL

FUEL was created over the course of a couple months, in early 2007, by Mark Finkle and I. Mark had much-better knowledge of Mozilla's APIs and I had good knowledge of JavaScript and API design - the match worked out nicely. I've written a couple blog posts on FUEL and so has Mark.

You can also see the features and code that went into FUEL 0.1 and FUEL 0.2 in Bugzilla.

FUEL, Today

Today FUEL lives in Firefox 3 (meaning that you can use it to develop Firefox extensions) and is part of the core Mozilla platform (meaning that portions of the API will be available in any Mozilla-based application that is built). For example you can even use a FUEL-like API in Thunderbird (called 'STEEL'). Here are some of the best resources for getting started with FUEL in Firefox 3:

• FUEL - Main Page (API, Examples)
• FUEL - Documentation (API)
• FUEL - Presentation (John Resig) - Given in Paris at a Mozilla DevDay, June 2007 - see below.
• FUEL - Presentation (Mark Finkle) - Given in Tokyo at a Mozilla DevDay, June 2007.
• STEEL - Example - If you're interested in extending Thunderbird Bryan Clark provides a good example.

Here are some of my favorite example of FUEL in action. It was very important to me that the most-common actions take no more than a single line of code to perform - with even complex actions keeping nice and trim.

Open, and activate, a new tab pointing to Google.com

Close the active browser tab

Close all tabs that mention Google

Add a new bookmark pointing to Mozilla

Remove all bookmarks pointing to Google.com

FUEL, Future

Development is still going strong on FUEL. There's a Google Summer of Code student working on extending the API and porting it to more parts of the platform (along with backwards support for Firefox 2!). We'll probably end up seeing this in Firefox 3.1 (the next version of Firefox, due out later this year).

If you have any questions concerning how to use FUEL, or to develop Firefox extensions in general, your best bet would probably be to join the #extdev IRC channel on irc.mozilla.org. Lots of knowledgeable people hang out there and will be more-than-capable of answering any questions that you might have.

Once again, I'm terribly excited by the final release of Firefox 3 - here's hoping to many more excellent releases to come!

I've come up with a plugin that you can inject into a jQuery site that you own and see how the performance breaks down method-by-method.

Here's how you can try this plugin on your own site:

Step 1: Copy site HTML, add base href, add plugin.

For example, Github.com uses jQuery for a few basic effects and pieces of interaction (they use considerably more on pages beyond the homepage).

I took a copy of their page, added a <base href> to the top and injected the profiling plugin giving a resulting test page.

Before:

After:

Step 2: Use the site normally.

Use the site as you normally would. Load it up, click around - perform normal interactions. In the case of the Github.com page I let it load, scrolled down, and clicked on one of the demo images - which caused an overlay to appear. I then closed the X on the overlay and let it hide.

Step 3: View data.

In your console type jQuery.displayProfile(); and scroll down to the bottom of the page. You should see something like the following:

and here's a sample data dump:

This quick table of data should be able to provide you with some interesting information about what's happening in your code. The result is still incredibly basic (really only providing the most basic level of jQuery method introspection) but it definitely shows some merit.

If you wish to create a different view for the data you can access the raw data structure by running jQuery.getProfile();.

The next stage of development for this plugin would be to reveal which methods are running inside other jQuery methods - in addition to monitoring other aspects of the application (such as timers, Ajax callbacks, etc.). I'm pleased with even this most-basic result - it gives me the ability to quickly, and easily, learn much more about a jQuery-using application.

Since JavaScript, alone, is so dumb (we've become spoiled by browsers which provide DOM, setTimeout/setInterval, and even a global object reference - none of which are necessarily required my an ECMAScript implementation) we must rely upon the spice of 'larger' languages to help it gain some taste.

We can start by taking a look at some of the most popular languages that are available today: Python, Perl, PHP, Ruby, and Java -- all of which have, at least, one embeddable JavaScript interpreter.

One thing is the same in all the interpreter implementations, as well, they all have the ability to introduce (at least) simple objects into interpreter (from the parent language) and extract values again. Sometimes this may be as simple as executing a JavaScript function and getting its return value (which is often translated from its internal JavaScript form back into the native language).

There's a couple points upon which I like to evaluate the embeddability of a JavaScript interpreter, specifically:

1. Object Translation: If objects/values are passed to/from the interpreter to/from the native language - is that translation handled automatically?
2. Simplicity: How hard is it to get up-and-running? (Is extra compilation required or is it written using native language code?)
3. Bleed-through: Can JavaScript communicate to the base language or is it a one-way-street?

The first point is the easiest one to find compatibility with - virtually all embeddable JavaScript interpreters do some form of object translation. Some do it better (like JE and Rhino) but it generally shouldn't be a problem for simple scripts.

PHP

» PHPJS

A flexible, pure-PHP, JavaScript interpreter that even accepts compiling to an intermediary bytecode. There is no bleed-through but good object translation.

» J2P5: Pure-PHP ECMAScript Engine

Probably the simplest of the available interpreters - there doesn't appear to be a clear way of communicating from JavaScript-to-PHP (or vice versa). Although, it is implemented in pure-PHP which allows for some nice cross-platform compatibility.

Perl

» JavaScript::SpiderMonkey

An embedding of Mozilla's Spidermonkey JavaScript engine into Perl. Since it uses Spidermonkey it'll require that extra source code and compilation. Object translation is good but there's no bleed-through (JavaScript calling native Perl functionality that isn't explicitly defined).

» JE: Pure-Perl ECMAScript Engine

A pure-Perl JavaScript engine - shows incredible promise (probably my favorite new engine in addition to Rhino). Has tremendous potential (including the ability to serialize the runtime environment!).

Note the extreme bleed-through that you can achieve with JE (in addition to excellent object translation).

Java

» Rhino

Probably one of the most famous embeddable JavaScript implementations. Implemented in pure Java has excellent object translation and perfect bleed-through. The bleeding can even be controlled explicitly at runtime (to create a more confined environment).

In the following code (using in some of the jQuery build system) two functions are defined which utilize a number of native Java packages - all without ever writing a single line of Java code.

Python

» Python-Spidermonkey

Previously this was one of the most depressing embedding efforts (and, really, the only one available for Python) but it has since had some new life blown into it - which is much appreciated. It supports decent object translation and bleed-through (including the ability to call native classes, much like in JE).

Ruby

While there was a previous effort to embed Spidermonkey in Ruby it is largely defunct now, superseded by the new (strangely named) Johnson project.

» Johnson

This is a, relatively, new project that's working to completely overhaul how communication is currently done in-between Ruby and JavaScript (using Spidermonkey to power the engine). There is complete bleed-through: Ruby can dig in and manipulate JavaScript objects at run-time and JavaScript can call back and access native Ruby functionality. Additionally they're examining the ability to provide native browser environments using the env.js script that I created last year. While the cross-platform ease-of-use isn't there yet the project absolutely has a ton of potential.

Update: Another example of Johnson in action from John Barnette:

There's a ton of potential in all of these projects - providing interesting features for blurring the lines in-between JavaScript and different host languages. For your next project it should be pretty easy to find a solution to embedding JavaScript as your quick-and-dirty scripting language of choice.

Renamed Algorithm Ink the result is a complete way to programmatically generate elegant pieces of artwork. Aza took the result a step further and built an in-browser IDE, gallery, and real-time result viewing. It appears to work best in Firefox 3, from my initial testing.

The result of one piece might look like this:

But that's the beauty since you'll likely never get the same piece of art twice. All works are seeded with a bit of randomness in order to create unique works. For example here is the CFA code that generated the above image:

startshape scale
	
rule scale{
	SPIKES{ s .03 }
}
	
rule SPIKES {
	SPIKE {}
	SPIKE { r 90 }
	SPIKE { r 180 }
	SPIKE { r 270 }
}
	
rule SPIKE {
	LSPIKE {}
}
rule SPIKE {
	LSPIKE { flip 90 }
}
	
rule LSPIKE {
	SQUARE {}
	LSPIKE { y 0.98 s 0.99 r 1}
}
rule LSPIKE 0.005 {
	SPIKE { r 90 }
	SPIKE { r -90 }
	LSPIKE { y 0.98 s 0.99  r 1}
}
	
rule MOUSECLICK{
  SPIKES{ s .025 }
}

The code is quite simple - just a set of rules that are initiated and seeded based upon a few parameters. More information can be found in the Context Free Art documentation.

Of course the entire Context Free port is open source: contextfree.js. Looking through the source you'll note that the result is much more math-heavy than Processing performing frequent matrix-based transformations to the display. The result, however, is that pieces written in CFA (as shown above) involve much less, obvious, mathematical calls and is a much-purer result.

I think this particular port shows a ton of promise: It shows that it's possible to create elegant works using JavaScript while doing it in a completely standards-based way. I'm excited to see people start to play around with this - I think it shows a lot of promise.

It seems like an especially hard question to answer - especially without using subjective terms.

For example I would say that the following are all trivial:

• Use of inline JavaScript/DOM 0-style code (ex. onclick="...").
• Use of unobtrusive scripting to layer on basic page behaviors (ex. Twitter).

Whereas the following are sufficiently complex as to be deemed not trivial:

• Applications that do Ajax requests to a server-side component (ex. GMail).
• Applications where the majority of the initial download is executable code (ex. 280 Slides).
• Applications that are unable to function without the use of JavaScript (ex. Google Maps).

But this brings up the question: What about poorly-designed pages that have a small amount of JavaScript but are unable to function without the use of JavaScript? I'd still deem it trivial.

And what about sites that are somewhere in-between? For example Netflix has a significant amount of unobtrusive JavaScript on their site but I would hardly consider it to be trivial (pop-ups, Ajax-loading, all sorts of unobtrusive interaction).

Is there a tangible line that is crossed on the road to complex JavaScript development? Is it an externality like storing script in a separate file (ex. <script src='...'></script>)? or is it inside the script itself like in using Function prototypes or closures? It feels like the measure should be put upon an external source (as to not make restrictions upon what someone could, or couldn't, write using the language) but what would the proper external measurement be?

Thoughts?

Using this utility you can begin writing ECMAScript 4 code today, receiving its full benefits (such as IDE integration and compile-time type-checking) while still being able to run the resulting code in all modern browsers.

A simple demonstration is up on the Mascara web site which provides a view into the translated source code, along with run-time (and inline) error messages.

A full break-down of the features currently supported are:

• Type verification
• Classes and inheritance, constructors, super initializers
• Static members
• Type inference from initialization
• Parameterized types, Map and Vector
• Union types
• Structural types
• Getters/setters
• Namespaces
• Nullable types

Definitely be aware, however, that while the above feature list is more than enough to get started there are still a a few items left to be implemented.

The most important question, when looking at the above code, should be: How do I begin using this today? Olav went ahead and made it easy to do IDE integration - even setting up instructions on how to integrate with Eclipse on Windows (he currently shows how to integrate using the JScript command-line interface, but it can easily be expanded). I'm quite excited by this prospect - having the ability to do compile-time type-checking and be able to succinctly write classes with inheritance will be a major boon to development.

Additionally, he provides information on how to do automatic CGI translation (naturally, you would want to do this only in a development environment).

He's continuing to provide frequent updates on the Mascara blog - be sure to follow along if you're interested in starting to use ECMAScript 4 sooner, rather than later.