Why a JavaScript hater thinks everyone needs to learn JavaScript in the next year

JavaScript is now a necessity.

I’ve long looked at JavaScript as a second-class citizen in the programming world. Early on, it was the source of numerous security problems; it was a nice bit of glue to patch together HTML applications with a bit of styling, but nobody would use it for serious code; and so forth. Java, Ruby, Python, they were the languages for doing real work.

But my attitude toward JavaScript has changed completely in the past few years. JavaScript has “grown up.” I’m sure there are many JavaScript developers who would take issue with that judgement, and argue that JavaScript has been a capable, mature, and under-appreciated language all along. They may be right, though you can write any program in any complete programming language, including awful things like BASIC. What makes a language useful is some combination of the language’s expressiveness and the libraries and tools available. JavaScript clearly passed the expressiveness barrier a long time ago, even if the ceremony required for creating objects is distasteful. But recently, we’ve seen some extremely important game-changers: jQuery, JSON, Node.js, and HTML5. JavaScript may have been a perfectly adequate language in the past, but these changes (and a few others that I’ll point out) have made JavaScript a language that is essential for every developer to know. If there’s one language you need to learn in the next year, it’s JavaScript.

The potential of Node.js

Node.js logoNode.js has the potential to revolutionize web development. It is a framework for building high performance web applications: applications that can respond very quickly and efficiently to a high volume of incoming requests. Although Node is a low-level framework that can build any kind of application, it’s particularly useful for building web servers. Its asynchronous event-driven paradigm is arguably more effective for web applications than the more familiar request-response paradigm.

Two things make Node particularly valuable, though. First, Google has started a revolution in JavaScript performance. This isn’t to say that at any given moment they have the best JavaScript engine available (though that’s a fairly good bet). But what’s certain is that Google took JavaScript performance seriously when other players didn’t, and in doing so drove Mozilla, Apple, Microsoft, Opera, and other vendors into a performance race. The result is that the JavaScript engines we have now are much, much faster than they were a few years ago, and are capable of running a serious web application.

Second, Node has benefitted from an enormous pool of JavaScript developers. Whatever language they use for the back end “server,” few developers don’t use JavaScript in the client. It may only be for bits and pieces of glue; it may be for sophisticated Ajaxian effects; it may even be to write full-fledged applications, such as Twitter or Gmail. But whatever the case, the number of JavaScript developers is huge. And authors like Doug Crockford have been pushing the idea that JavaScript, despite many warts, can and should be treated like a serious programming language.

At this point, writing Node applications is relatively crude: it’s a low-level library, about as close to the metal as you can get with JavaScript. It is not a full-fledged web framework, like Rails or Django. But that is certain to change. Lightweight frameworks like Express are starting to appear, and I have no doubt that we’ll see more full-featured frameworks built on top of Node.

I’ve mentioned the appearance of sophisticated web applications that run almost entirely in the browser. Those are hardly new — how old is Gmail? How old is Google Maps? But writing the client side of an application in JavaScript and running it on the browser is increasingly attractive. HTML5 takes this trend a step further.

HTML5 is about JavaScript

I’ve said many times that HTML5 isn’t really about HTML; it’s about JavaScript. What changes in HTML itself? There are a few new tags, which in and of themselves aren’t that difficult to understand. The power of HTML5 lies in what these tags allow you to create in JavaScript. A drawing canvas isn’t very useful without the code that lies behind it and creates an animation, a game, or a visualization tool. As soon as browsers supporting Canvas appeared, we saw hundreds of implementations of Asteroids as developers started playing with the new features. Some were crude, some were surprisingly rich. That work is entirely in JavaScript.

HTML5HTML5, then, isn’t really a major advance in angle-bracket-based tagging; it’s about enabling JavaScript to do more powerful things. The WebGL library (which is still bleeding edge) allows real-time 3D graphics inside an HTML5 canvas. HTML5 geolocation allows you to write location-aware applications in the browser (a basic capability for mobile phones). Persistent storage and offline functionality have enabled developers to write full-fledged applications, with the same functionality you’d expect on a desktop, that run in the browser. There have also been experimental libraries for adding multitouch capabilities. These are all really features of JavaScript. HTML5 just provides a structure for giving them meaning.

Furthermore, there have been significant advances in browser libraries that don’t require HTML5. JavaScript has long been the workhorse for implementing dynamic features in HTML. But there have always been two problems: browser incompatibilities, and the awkwardness of working directly with the DOM. The JQuery library has elegantly solved both problems, and is the basis for modern client-side browser development. But it’s not just JQuery. The Protovis and D3 libraries allow you to create complex interactive visualizations that run directly in the browser — for the first time, making the browser an important tool for data exploration.

JavaScript and databases, compilers and languages

The use of JavaScript has also exploded in databases. Three of the leading databases in the NoSQL movement, CouchDB, MongoDB, and Riak, are “document databases.” Rather than storing tables, they store documents. And for all three databases, a “document” means a JSON document, not a Word or Excel file. (Riak also supports XML documents and plain text.) While JSON has been widely adopted as a data exchange format (there are libraries for parsing JSON in almost all modern programming languages), it’s important to realize that JSON is really just a format for serializing JavaScript objects. So while you can use JSON with any language, it’s a natural fit for JavaScript development; and the fact that JSON has become a cross-language standard, rather than some Python, Ruby, or Java serialization format, says a lot about JavaScript’s readiness to take a role on a larger stage. But even more than that, all three of these databases have facilities for executing JavaScript as part of queries. In the coming years, I would not be the least surprised to see JavaScript and JSON embedded within other kinds of applications.

We’ve only seen the beginning of JavaScript development. At this year’s JSConf, javascript-to-javascript compilers were a big theme, and seen as a major trend for the future. Google has been the hotbed of compiled JavaScript. GWT is the first framework I’m aware of that used compiled JavaScript (compiled from Java). I have never taken GWT that seriously; a framework that exists just to save Java developers from having to use JavaScript just doesn’t seem worthwhile. However, GWT does some amazing JavaScript optimization in the process. Closure is a JavaScript-to-JavaScript compiler that does the same kinds of optimization. Traceur, which first appeared a few weeks ago, was designed to allow experimentation with the language itself: it compiles JavaScript with experimental language features into JavaScript that can run on any modern platform.

Finally, we’re starting to see some languages compile to JavaScript, much as we’re seeing JVM languages in the Java space. Some of the more interesting languages, such as Coffeescript and Kaffeine, are similar to JavaScript in style, but focus on smoothing out JavaScript’s rough edges. Do you find the JavaScript object model interesting, but awkward, and are you put off by the ritual you need to go through to create a working object from a prototype? You may find Coffeescript a significant improvement. In addition to smoothing out the object model, Coffeescript adds features like list comprehensions, and does away with most of the curly braces. As in Python, indentation serves to delimit blocks.

Web servers, rich web client libraries, HTML5, databases, even JavaScript-based languages: I see JavaScript everywhere. If you have avoided JavaScript, this is the year to learn it. There’s no excuse — and if you don’t, you risk being left behind.

Related:

tags: , , , , ,

Get the O’Reilly Programming Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • hrbg

    I dont think you should learn javascript next year. I think you should learn it now

  • http://trueacu.com acupuncture

    Nice read. I never got that much into JavaScript till I started playing with gpEasy CMS as it uses jQuery. jQuery made it easy for a noob like myself to do things.

    However, from reading your article the one thing that really jumps out at me is, some standardization seems needed. . . and quick.

    Now that MS is pushing HTML5 & JavaScript for Win8 maybe we’ll start to see faster development on the web instead of it being held back, and just maybe more standards across browsers.

    Nonetheless, it’s a great time for web development.

  • http://www.morgancraft.com Morgan Craft

    Author said: Node.js has the potential to revolutionize web development.

    How about Nodejs has the potential to revolutionize application development and not just web development. We need to think bigger for nodejs and the evolution of web software will transcend into applications.

  • http://adamjsontag.com adam j. sontag

    What is an “Ajaxian” effect? Ajaxian is a blog.

  • http://tiffanybbrown.com/ tiffany

    Minor quibbles:

    HTML5 geolocation allows you to write location-aware applications in the browser.

    Geolocation isn’t actually in the HTML5 specification. It’s a “related technology.”

    “There are a few new tags, which in and of themselves aren’t that difficult to understand. The power of HTML5 lies in what these tags allow you to create in JavaScript.”

    Sort of. HTML5 is better described as an API. It introduces some new elements, but it redefines all elements as objects or classes. You can express these elements with tags, or you use DOM Scripting (what we commonly call JavaScript) to create elements.

    I agree with you however, that JavaScript is now mandatory for every web developer, possibly every programmer. There’s Node.js. Most “NoSQL” servers use a JSON-like notation for storing data and a JavaScript-like syntax for queries. It’s now entirely possible to create an application with a client-server model using HTML, CSS and JavaScript. And as you point out, this event-driven model that JavaScript / DOM Events / HTML5 / and Node.js uses is much more suited to the web. JavaScript is possibly the best programming language to learn right now.

  • http://danielfrost.dk Daniel

    Pick the right tool for the job. JavaScript is not the answer for everything, and you can easily get a long without learning it.

    Also, I wouldn’t even consider mentioning it in the same line with an OO language like Java or C#. It’s a client scripting language and should be treated as that. I like the jQuery/(framework) abscrations on top but it’s still dynamic-typed, generally lousy tooling and so forth.

    I am not saying I don’t like the language because I really do, I think it gives you a lot of good things, but I just think people are starting to focus “javascript is the silverbullet and we don’t need a server anymore”.

    Just my 2 cents

  • http://www.NodeBeginner.org Manuel Kiessling

    For those interested: I’ve written a comprehensive intro to Node.js and advanced JavaScript at http://www.NodeBeginner.org/

  • Baruch Atta

    I don’t mind rough edges in JavaScript, just make them the same rough edges in each version.

    Let’s hope for bigger, better and brighter for every girl and boy, and every programming language.
    Cynically, I would say that any and all predictions of the future of a programming language are like Mark Twain’s death report – “highly exaggerated”.

  • http://fiveholiday55.blogspot.com Helen Neely

    I just search Ajaxian online, but it showed me a blog. What other Ajaxian is there you’re referring?

  • Nicolas

    You are I think a litle too much amphatic.

    We have hype here. NoSQL, Node.js, asynchronous IO. The funiest thing, this is not even new. Asynchronous IO is part of C standard library (maybe for more than 20 years). Server side JS was already here 15 years ago. And the first database (before RDBMS) where just key/value and document store where you had to perform the querying yourself in a proprietary language (like old AS400 mainframes).

    JS is still imature on the server. Node.JS is still low level, still missing profesionnal libraries to perform most things. Still limited to a single thread making all IO to wait if you have a CPU bound event running.

    JS and HTML5 on the client is still full of inconsistencies between browser and debugging is pain even with firebug.

    JS is still imature as a language with subpar OOP support and lot of rough edge.

    JS is popular for only one thing. It is the standard for scripting and client side. And solution that bypath JS on the client are more more popular than solution that use JS on the server.

  • keithflo

    You make many fine points .. along with some with which reasonable people could differ .. but to say .. that in JavaScript “the ceremony required for creating objects is distasteful” .. is simply nonsense! … Every language you mentioned requires MORE ceremony to create an object than JavaScript! In JS the following is ALL that is needed to create an object ..

    var myObj = {};

    that’s it! .. a variable declaration and two curlys!! .. you call that a ‘distasteful’ amount of ceremony? Try creating a generic collection object in Java or CSharp .. that’s distasteful!

  • Raynos

    “subpar OOP support”

    “wouldn’t even consider mentioning it in the same line with an OO language like Java or C#”

    Do people realise that JavaScript is prototypically OO and not Classicaly OO.

    In EcmaScript 5 we have Object.create. You don’t need any more for prototyping OO.

  • Aquilegia

    To the people who queried ‘Ajaxian’; this means AJAX-like. Do your searching on the term ‘AJAX’ if you don’t get this.

  • Joel Webber

    Mike:

    Not to be overly pedantic, but the purpose of GWT has most emphatically *never* been to “save Java developers from having to use JavaScript”.

    We needed a statically-typed language so that it would actually be *tractable* to perform ahead-of-time optimizations and get decent tooling (this is essentially impossible in raw Javascript, as all but the most trivial programs are intractable to analyze statically). And Java was just a conveniently simple statically typed language that we could use for this purpose. Personally I would have preferred C#, but that was off the table for other reasons.

    The Closure compiler does essentially the same thing, but it’s taken the separate route of evolving a statically-typed variant of Javascript (most of its “advanced optimizations” won’t work unless you have correct type information).

    • http://radar.oreilly.com/mikel Mike Loukides

      Thanks for pointing that out. In my defense, I was at a number of the early GWT talks at JavaOne, and the main takeway was (mostly) “you don’t have to deal with yucky javascript anymore.” It’s possible misremembered it–and even at that time, I was uncomfortable with that aspect of GWT (but as a JavaScript hater, I was inclined to ignore my discomfort). And yes, those early presentations did (as you point out) mention GWT’s powerful optimization capabilities.

  • http://about.me/michaelangelo Mike

    Nice article, i was a web developer before and doing the back end stuff, sometimes with the front end and using web frameworks and no javascript at all(well my colleagues helped me with that) . I tried playing around with GWT to use my Java skills to generate javascript but after reading your article. seems interesting enough to give it a go, right now im doing Android Application development, and connecting with NodeJS to get JSON Services.

    interesting!

  • Marijn

    javascript is like going back to the middle ages. It is time for a ‘grown’ language to take over.

  • Tomas

    As a experienced programmer javascript is not hard to learn and quite useful when working with web interfaces. It’s no rocket science. Nowadays everything count in the hype HTML5 as the future and possibilities. But as always use the right tool for the job. Working with other technologies it isn’t amazing to see a bouncing ball or experiments that looks like Flash for 10 years ago. Why can’t new technologies be mindblowing or make the daily things a lot better. It’s too often there is crossbrowser problems, performance issues, and HTML5/javascript is so redicilous simple compared to Flash for example. Yeah you have a slow Canvas to draw on but there are like 10 functions to call instead of a complete Flash API that is very mature. Doing video/sound you need to have multiple formats. When you have flexibility/simplicity in javascript you loose speed. Understanding different technologies and solutions is important.

  • John

    Don’t forget mobile too (http://www.appcelerator.com). I definitely agree with the author that javascript is extremely important especially in the years to come. It’s very nice to have the option do almost all of your development in one language if not for prototyping. If you’re not happy with the underlying code base, just swap it out with another server-end language.

    If you want a traditional inheritance feel to your objects created in Javascript, you should check out MooTools (core+server) and use classes on both client and server, which saves you from duplicating business logic on both ends. For everyone else who uses jQuery check out moo4q on the net (google is your friend). Its MooTools classes with jQuery. I’m a LAMP Developer by day and used to write python code at night. Lately, its been nothing but javascript…

    Express – reminds me of django,
    Titanium – (native) Mobile Development (desktop as well),
    Expresso + should – used for unit testing(Node.js),
    Node-Inspector – much better than CLI Debugging ;)

    • http://radar.oreilly.com/mikel Mike Loukides

      Thanks. Should definitely have mentioned mobile; glad you pointed it out.

  • james

    This article gives Google far too much credit for igniting the JavaScript performance wars.

    The first Chrome release was in September 2008, a full two months after the Apple-led WebKit team had announced SquirrelFish, which was much faster than any other JS engine. The same team also created the SunSpider JavaScript benchmark, which has become the JavaScript performance measuring standard since.

    So it would be more correct to say that it was Apple, not Google, which ignited the JavaScript performance wars and which, through its creation and support of the WebKit project that also forms the core of Chrome, has probably done more than any other company to advance browser technology and the implementation of HTML 5 in the past few years. Credit must be given where it is due.

    • http://radar.oreilly.com/mikel Mike Loukides

      Frankly, I think credit is given where it is due. I didn’t want to go through the entire history of JavaScript, but gmail and Google Maps really ignited JavaScript as a language for application development. That is what really started the revolution; people looked at what Google did in those applications, started doing themselves (inventing the term Ajax along the way), and the rest is history. Google also invented GWT early on, at least in part to optimize JavaScript performance in ways that weren’t amenable to hand-coding. (Though I also agree that GWT has had little influence outside of Google.

      So, while Apple has certainly done great things with WebKit, and while I should have acknowledge it, Google is central to the changes in how JavaScript is used.

  • http://www.albertoconti.com Alberto

    Love the article. What about a nice, decent IDE for Javascript? Any suggestions?

  • Ryan

    I don’t know what’s worse. O’Reily being so slow to realise this or the hordes of idiot commenters here who STILL haven’t realised it.

  • http://www.thingworx.com Rick Bullotta

    Agree completely, Mike. It has really become the “lingua franca” of web applications, and we’ve decide to leverage Javascript as our default server-side scripting engine for ThingWorx, and JSON as the native and primary structure for compound data.

    The other key aspect (for us at least) was the dynamic nature of the language. In our platform, users and developers “model” their world and the domain objects (trucks, traffic lights, roads, transformers, generators, machines, database, feeds, web services, people) in it, and our entire runtime needs to be able to accomodate this with on-the-fly modifications and adaptability to the changing model.

    One reality, however, is that to do most useful things, you’ll need to extend Javascript to be able to consume other “stuff” – DOM, XMLHTTPREQUEST, CSS and such on the client side, and domain objects, data, events and services on the server side. The various JS engines accomplish this with varying degrees of success and utility.

    And of course JS isn’t an “either or” – it can nicely co-exist almost anywhere in the web app stack with almost anything else.

  • Steve Witham

    Another reason to start learning or paying more attention to JavaScript is that ECMAscript 5 in “use strict” mode is a lot safer and more secure language, not just compared to earlier JavaScript versions, but also compared to Java, Python, and obviously unsafe languages like C++ and objective C.

    ECMAscript 5 and “use strict” plug holes in js semantics that allowed pieces of code to have unintended powers. Besides curing some accidental mystery bugs this improved encapsulation allows better confidence writing large programs employing third party libraries, and allows cooperation between mutually-distrusting code that solves some of the underlying issues with cross-site scripting, mashups, and cloud computing.

    WebKit (but not yet Safari), FireFox 4 and the BESSEN engine are already there, IE 9, Chrome and Rhino are very close.

    More details on this aspect of ECMAscript 5 in this interview with Mark Miller. The Google Caja project, whose people intersect the ECMA committee, addresses similar goals through a sanitization server approach.

  • http://www.thinksmartdigital.com.au Michael

    coffeescript is awesome.

    He says “I’m sure there are many JavaScript developers who would take issue with that judgement, and argue that JavaScript has been a capable, mature, and under-appreciated language all along.”

    Well I’m not a javascript programmer and I’ve known about the power of javascript for many years, this article is about 3 years too late.

  • Stagl

    @Daniel: JavaScript is OO.
    @Alberto: Try Aptana. It’s a flavor of Eclipse that has built in JS support.

  • http://sozonov-alexey.ru Alexey

    ok, i’ll study javascript! =)

  • http://twitter.com/crabdude Adam Crabtree

    I know this is a touch out of date, but I’m slow to get to all the links in my Javascript Weekly, http://javascriptweekly.com/, email! ;)

    Firstly, in order to confuse EVERYONE while attempting to clarify, the term HTML5 may refer to ANY of the following:

    - W3C SPEC, http://dev.w3.org/html5/spec/Overview.html
    - WHATWG “living standard”, http://blog.whatwg.org/html-is-the-new-html5
    - New HTML tags (e.g., canvas, video, SVG, etc…)
    - New APIs (localStorage, postMessage, WebSocket, etc…)
    - Even more APIs not technically in the HTML5 spec (e.g., Geolocation, FileSystem, etc…)
    - New language features from ECMAScript 5 / ECMAScript Harmony / JavaScript [NextVersion]
    (ASIDE: Javascript and ActionScript are dialects of ECMAScript or can be thought of as implementations, SEE http://en.wikipedia.org/wiki/ECMAScript)
    - An umbrella term for all of the above

    Most commonly though, HTML5 is used as the tersest means to communicate the “All of the above” option. As always, see Wikipedia for an overview, http://en.wikipedia.org/wiki/HTML5.

    Secondly, see these solid HTML5 reference:

    http://diveintohtml5.org/detect.html
    https://developer.mozilla.org/en/html/html5

    @acupuncture

    Standardization is precisely what is occurring, see http://www.whatwg.org/specs/web-apps/current-work/multipage/ and http://dev.w3.org/html5/spec/Overview.html that is responsible for the myriad of rapidly evolving APIs and language features. IE9 was what many of us consider a symbolic step forward from MS toward cooperation. Though it should be pointed out we have much to thank from MS (e.g., XHR, innerHTML, etc…)

    @Daniel

    I fear you may have missed what the OP was attempting to convey. More and more business logic will transition to the client-side to provide fully featured applications with servers that share libraries and code. If you are a specialist or even a software engineer that doesn’t work on the web, I would still caution against ignoring Javascript as it will soon begin to encroach upon many other languages and realms outside of the browser and the web.

    To be certain, Javascript will never replace many languages. However, 4 years ago the idea of server-side Javascript seemed like a relic from bubble era, now we have nodejs, which makes more sense as a web application server than any other language/platform.

    Javascript controlled robots anyone? http://jsconf.eu/2010/speaker/livingroombindmotion_function.html

    @Nicolas

    You’re right in that async IO is not new, but Nodejs is different and important for several reasons:

    - In other languages, differentiating b/w blocking libraries and non, leads to a murky implementation requiring library knowledge to avoid land mines. In Nodejs, you cannot accidentally block and the very few synchronous calls are marked accordingly with the exception of require. The net affect is that very few implement async IO in other languages by default. In node, async IO IS the default.
    - Javascript client-side and server-side means code reuse and skill set convergence in the form of not having to employ [PHP, Ruby, Python, etc…] developers AND Javascript developers.
    - I would venture to propose that more developers and software engineers know Javascript (albeit not well) than any other language as most [PHP, Ruby, Python, etc…] devs also know Javascript, but the converse is not always true.

    @keithflo

    I believe he’s referring to inheritance, either classical, https://developer.mozilla.org/en/JavaScript/Guide/Inheritance_Revisited:

    function A(a){
    this.varA = a;
    }
    A.prototype = {
    varA : null,
    doSomething : function(){
    // …
    }
    }
    function B(a, b){
    A.call(this, a);
    this.varB = b;
    }
    B.prototype = Object.create(A, {
    varB : { value: null, enumerable: true, configurable: true, writable: true },
    doSomething : { value: function(){ // override
    A.prototype.doSomething.apply(this, arguments); // call super
    // …
    }, enumerable: true, configurable: true, writable: true }
    })

    var b = new B();
    b.doSomething();

    or prototypical, http://javascript.crockford.com/prototypal.html:

    if (typeof Object.create !== ‘function’) {
    Object.create = function (o) {
    function F() {}
    F.prototype = o;
    return new F();
    };
    }
    newObject = Object.create(oldObject);

    Also, SEE Raynos comment.

    @Marijn

    I believe the point of the article was to say that Javascript HAS grown or IS growing up in the form of HTML5 and Nodejs.

    @Tomas

    Agreed, for now. I would anticipate though that as Javascript becomes more dominant, the performance of everything you mentioned will eclipse competitors like Flash. IE9 alone is almost 20x faster than IE8!

    @Alberto

    Checkout Aptana Studio 3 recently bought by Appcelerator, makers of Titanium, http://aptana.com/products/studio3, or new newer Nodejs Javascript built Ace Editor, http://ace.ajax.org/, also known as Cloud9 IDE, http://cloud9ide.com/.

  • http://wuenschenswert.net Axel Wienberg

    Another project from the “cleaner-JavaScript-to-browser-JavaScript compiler” class that could be mentioned is Jangaroo, which translates ActionScript3 to JavaScript. (Full disclosure: I work at the company supporting the jangaroo open source project.)

    As a typed and modular language, ActionScript3 offers a number of advantages for programming in the large, compared to pure JavaScript, and jangaroo provides the necessary tools (an Idea plug-in and a maven mojo).

    In addition, ActionScript3 is the language of Flex, and Jangaroo comes with a small but growing Flash emulation library, allowing you to run Flex code directly in a HTML5 capable browser without a Flash plug-in.

    Since ActionScript3 is quite close to JavaScript, the compilation result is still line number equivalent to the source (no byte code or so), and is interoperable with native JavaScript libraries such as ExtJS.

  • http://www.daylyn.org daylyn

    plan to learn js

  • Ben Hayat

    Hi;

    Very nice article and informative. I was surprise the article did not mention Wakanda.Org as a complete Application Framework that uses purely JS language for writing Client & Server, which also has a build in Object Oriented Database as well.

    It would be to explore it for future articles.
    Thanks!
    ..Ben

  • http://www.scn.org/~mentifex/AiMind.html A.T. Murray

    JavaScript has even become a serious language for artificial intelligence.

  • http://codeavengers.com Andrew Gale

    The best way to learn Javascript is at http://codeavengers.com