A Minute with Brendan

Dude, just admit you’re wrong about what kinds of patterns are natural or common in JS and about what was “in mind” when it was created.

Here are some popular big JavaScript toolkits/frameworks: Closure Library, YUI, Dojo, Prototype, MooTools, ExtJS, Base2, JavaScriptMVC, Backbone.

http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.html

http://yuilibrary.com/yui/docs/api/classes/Base.html

http://livedocs.dojotoolkit.org/dojo/declare

http://api.prototypejs.org/language/Class/

http://mootools.net/docs/core/Class/Class

http://docs.sencha.com/ext-js/4-0/#!/api/Ext.Base

http://base2.googlecode.com/svn/version/1.0.2/doc/base2.html#/doc/!base2.Base

http://javascriptmvc.com/docs.html#!jQuery.Class

http://documentcloud.github.com/backbone/docs/backbone.html#section-135

* * *

And here are some other helpful resources:

http://www.aminutewithbrendan.com/pages/20110216

http://www.quora.com/How-was-classical-inheritance-*supposed*-to-be-done-in-ECMAScript-3

http://www.2ality.com/2011/06/prototypes-as-classes.html

http://ejohn.org/blog/simple-javascript-inheritance/

http://my.safaribooksonline.com/book/programming/javascript/9781449399115/code-reuse-patterns/klass

http://javascript.crockford.com/prototypal.html

http://bolinfest.com/javascript/inheritance.php

http://dmitrysoshnikov.com/ecmascript/chapter-7-2-oop-ecmascript-implementation/

It's a tradeoff between compatibility with existing JS versus perf/capability enhancements. The ECMAScript committee goes back and forth on this topic. The biggest stride in that direction was strict mode, which is intended to catch most of the low hanging fruit. I know Brendan Eich has mentioned a number of things that could change to get the language faster. I don't, however, know if I read it all in one place or I'm combining nultiple one-off examples.

I'm not confident enough in my memory to write out a probably incorrect list of things I remember. Here's a list of the various things I've read from Brendan in case you're interested in tracking it down:

http://lambda-the-ultimate.org/node/3851#comment-57671

This is the LtU thread my previous comment referred to. It's a large (and fantastic!) thread, but I believe that comment and children are the most direct comments back and forth between Mike and Brendan. Andreas Gal is also on the thread and from Mozilla.

http://www.aminutewithbrendan.com/

Brendan's weekly JS podcast. They're relatively accessible and generally cover a lot of area. A good way to get in the language zeitgeist.

http://brendaneich.com/

Brendan's blog, mostly focuses on ES Harmony stuff and Mozilla specific topics.

Brendan Eich has talked about why bytecode + VM is a bad idea for a browser: http://www.aminutewithbrendan.com/pages/20101122

If you really want a VM, it already exists. It's called JavaScript, assembly language of the web.

I would hate for sites to start saying, "Requires the PyJSVM v0.8 or better to function, download it now!"

EDIT: in hindsight, this post was careless. I was wrong about the "PyJSVM" point, and I posted the minutewithbrendan link to provide commentary, not "Eich said it, so it must be true."

What I should have said:

JavaScript is so widely used today, that anything that comes along purporting to be better (such as bytecode, Dart, whatever) must be so much better as to provide a clear reason for developers and users. If it's just "better", then JS will remain dominant because it's good enough. Therefore, it makes sense to target JS from other langs. It's definitely not getting slower, and we're on the cusp of some great APIs!

Actually I missed this before. Javascript runtimes are /not/ VMs- I don't think I've ever seen a javascript engine use a virtual machine. Ever. Do you have evidence of this? (unless you mean in the sense that asm.js is treating the javascript runtime, as though it were a VM)

as for arguments against bytecode VM's, how about

http://www.dartlang.org/articles/why-not-bytecode/

http://www.aminutewithbrendan.com/pages/20101122

http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebPart2MadnessOrJustInsanity.aspx

Basically it comes down to this: It's easier and way more efficient to secure an untrusted program using a language grammar rather than a "bytecode verifier"
and a few other things.

your comments about Java and the DOM are demonstrable untrue
http://docs.oracle.com/javase/tutorial/deployment/applet/manipulatingDOMFromApplet.html

As always, munificent is right on the money.

The "closure pattern" is one of the most serious JavaScript anti-patterns -- it doesn't make much of a difference in tiny scripts, but for any decent-size JavaScript application, it can hurt performance terribly, especially regarding memory use.

For example, benchmarking the creation of 1 million objects, each with 10 member functions, in both the prototypal style and the closure style (in Chrome):

1 million prototypal objects: Brief pause, 32.4 MB

1 million closure objects: Minutes wait, 368.1 MB

If you're doing object-oriented code in JS, please use the "prototype" property, like the language is designed to do.

For more info, here's Brendan Eich on the subject:

http://www.aminutewithbrendan.com/pages/20110216

http://news.ycombinator.com/item?id=1893686

Mentioned in http://www.aminutewithbrendan.com/pages/20101122.

JS is becoming the compiler target "bytecode", without needing verifiers or new and complex standards to be adopted by multiple browser vendors.

JS has gaps as a target language, for sure. We are working on filling them (e.g. 64-bit and other int types).

These are easy bugs to fix compared to creating a new, portable, and future-friendly bytecode standard in addition to keeping up with a competitive JS engine. Since JS is incumbent, it's hard for any browser vendor to justify a new thing with zero users at first, and too much risk of non-standardization or JVML-like albatross status.