Crockford appears to object to the pseudoclassical pattern
because: "There is no privacy; all properties are public.
There is no access to super methods...Even worse, there is a
serious hazard with the use of constructor functions. If you forget to use the
new prefix when calling a constructor function, then
this will not be bound to a new object...There is no compile
warning, and there is no runtime warning."

This article discusses the advantages of the pseudoclassical pattern
over the functional pattern. I argue that the pattern used by the Closure
Library paired with the Closure Compiler removes existing hazards while I
also examine the hazards introduced by the functional pattern
(as defined in The Good Parts).
First let me demonstrate what I mean by the functional pattern.

Example of the functional pattern

The following is an example in the style of the functional pattern for
inheritance as explained
in Douglas Crockford's JavaScript: The Good Parts. It contains the
definition for a phone type as well as a subtype
smartPhone.

Drawbacks to the functional pattern

Instances of types take up more memory

Every time phone() is called, two new functions are created
(one per method of the type).
Each time, the functions are basically the same, but they are bound to
different values.

These functions are not cheap because each is a closure that maintains a
reference for every named variable in the enclosing function in which the
closure was defined. This may inadvertently prevent objects from being garbage collected,
causing a memory leak.
The Closure Library defines goog.bind() and goog.partial()
in base.js
to make it easier to create closures that only maintain the references they need,
making it possible for other references to be removed when the enclosing function
exits.

This is not a concern when Phone() is called because of how it takes
advantage of prototype-based inheritance. Each method is defined once on
Phone.prototype and is therefore available to every instance of
Phone. This limits the number of function objects that are created
and does not run the risk of leaking memory.

Methods cannot be inlined

When possible, the Compiler will inline methods, such as simple getters. This
can reduce code size as well as improve runtime performance. Because the methods
in the functional pattern are often bound to variables that cannot be
referenced externally, there is no way for the Compiler to rewrite method calls
in such a way that eliminates the method dispatch. By comparison, the following
code snippet:

Superclass methods cannot be renamed (or will be renamed incorrectly)

When the Closure Compiler is cranked up to 11, one of the heuristics it uses
for renaming is that any property that is not accessed via a quoted string
is allowed to be renamed, and the Compiler will do its best to rename it.
All quoted strings will be left alone. It is not required to use the Compiler
with this aggressive setting, but the potential reduction in code size is too
big to ignore.

From the phone example, getDescription is used both as
a property defined on that and as a string literal passed to
that.superior(). If aggressive renaming were turned on in the Compiler,
getDescription would have to be used as a quoted string throughout
the codebase so that it did not get renamed. (It could also be declared as an extern,
which is what prevents built-in method names, such as toString()
from being renamed, but because there is no function to associated the method
with, it would have to be declared as an extern on Object.prototype.)
Remembering to refer to it via a string literal throughout the codebase is a
bear and precludes the benefits of aggressive renaming.
(To be fair, some of the constructs in the candidate spec for EcmaScript 5,
such as Object.defineProperty(), have similar issues.
The solution will likely be to add logic to the Compiler to treat
Object.defineProperty() in a special way.
The same could be done for superior() if one were so motivated.)

Types cannot be tested using instanceof

Because there is no function to use as the constructor, there is no appropriate
argument to use with the right side of the instanceof operator to
test whether an object is a phone or a smartPhone.
Because it is common for a function to accept multiple types in JavaScript,
it is important to have some way to discern the type of the argument that was
passed in.

An alternative would be to test for properties that the desired type in question
may have, such as:

if (arg.sendEmail) {
// implies arg is a mobilePhone, do mobilePhone things
}

There are two problems with this solution. The first is that checking for
the sendEmail property is only a heuristic -- it does not guarantee
that arg is a mobilePhone. Perhaps there is also a
type called desktopComputer that also has a sendEmail
method that would also satisfy the above test. The second problem is that this
code is not self-documenting. If the conditional checked
if (arg instanceof MobilePhone), it would be much clearer what was being
tested.

In Chapter 4 of The Good Parts,
Crockford introduces Function.prototype.method
and uses it in Chapter 5 via Object.method to add a property
named superior to Object.prototype to aid in creating
superclass methods. Adding properties to fundamental prototypes makes it harder
for your code to play nicely with other JavaScript libraries on the page if
both libraries modify prototypes in conflicting ways.

The Google Maps team learned this the hard way when they decided to add
convenience methods to Array.prototype, such as insertAt
(incidentally, this is exactly what Crockford does in Chapter 6).
It turned out that many web developers were using for (var i in array)
to iterate over the elements of an array (as opposed to using
for (var i = 0; i < array.length; i++) as they should have been).
The for (var i in array) syntax includes properties added to
Array.prototype as values of i, so bringing in
the Google Maps library would break the code on those web pages. Rather than
trying to change web developers' habits, the Maps team changed their library.
It is for reasons such as these that
array.js
in Closure is a collection of array utility functions that take an array as their first
argument rather than a collection of modifications to Array.prototype.

For those of you who do not own Crockford's book, here is the code in question. Try
running the following and see what happens:

Instead of enumerating two properties in obj, three are listed:
one, two, and superior. Now every
object literal in your program will also have a property named superior.
Though it may be handy for objects that represent classes, it is inappropriate
for ordinary record types.

Makes it impossible to update all instances of a type

In the Closure model, it would be possible to add a field or method to all
instances of a type at any point in the program by adding a property to the
function constructor's prototype. This is simply not possible in the functional
model.

Although this may seem like a minor point, it can be extremely useful when
developing or debugging a system to redefine a method on the fly
(by using a REPL such as
Chickenfoot or the
Firebug console).
This makes it possible to put probes into
a running system rather than having to refresh the entire web page to load
changes.

Naming newly created objects is awkward

This may be more of a personal preference, but the "capitalize constructor
functions" convention makes it fairly intuitive to name a newly created object.
From the pseudoclassical example, we have:

var phone = new Phone('8675309');

where the name of the variable matches that of the constructor, but has a
lowercase letter. If the same thing were done in the functional case,
it could cause an error:

Here the local variable phone shadows the function phone(), so
callJenny() will throw an error when called because phone is
bound to undefined when it is applied to '8675209'.
Because of this, it is common to add an arbitrary prefix, such as my,
to the variable name for newly created objects when using the functional pattern.

Results in an extra level of indentation

Again, this may be more of a personal preference, but requiring the entire
class to be defined within a function means that everything ends up being
indented one level deeper than it would be when using the Closure paradigm.
I concede that this is how things are done in Java, and C# even suggests adding
an extra level of depth for good measure with its namespaces, so maybe there's some prize
for hitting the tab key a lot that no one told me about. Regardless, if you have ever worked
someplace (like Google) where 80-character line limits are enforced, it's nice
to avoid line-wrapping where you can.

Potential objections to the pesudoclassical pattern

Won't horrible things happen if I forget the new operator?

If a function with the @constructor annotation is called without
the new operator, the Closure Compiler will emit an error.
(Likewise, if the new operator is used with a function that does
not have the annotation, it will also throw an error.) Crockford's objection
that there is no compile-time warning no longer holds! (I find this odd
because Crockford could have created his own annotation with an identical check
in JSLint.)

Didn't Crockford also say I wouldn't have access to super methods?

Yes, but as the example above demonstrates, a super class's methods are accessible
via the superClass_ property added to a constructor function.
This property is added as a side-effect of calling
goog.inherits(SmartPhone, Phone). Unlike the functional example
with super_getDescription, super class accessors do not need to be
explicitly created in Closure.

Won't all of the object's properties be public?

It depends on what you mean by "public." All fields and methods of an object
marked with the @private annotation will be private in the sense
that the Compiler can be configured to reject the input if a private property is
being accessed outside of its class.
So long as all of the JavaScript in your page is compiled together, the
Compiler should preclude any code paths that would expose private data.

Won't declaring SomeClass.prototype for each method and field
of SomeClass waste bytes?

Not really. The Compiler will create a temporary variable for
SomeClass.prototype and reuse it. As the Compiler works today,
it is admittedly most compact to write things in the following style:

However this style has some drawbacks.
Doing the above introduces an extra level of indenting and makes reordering
methods more tedious because extra care is required to ensure that the last
property declared does not have a trailing comma and that all of the other properties do.
I think that it is reasonable to expect the Compiler to produce output more
similar to the above in the future, but that the recommended input will continue
to match the style exemplified in the
pseudoclassical example.

I don't need static checks -- my tests will catch all of my errors!

Let's be honest -- do you write tests? And if you are writing tests, how much
confidence are they giving you about your code's correctness? As
I've
discussed previously, existing tools for testing web applications make it
difficult to write thorough tests. So even if you have taken the time to
write tests, it is unlikely that they exercise all of your code.
(Lack of good tools for measuring code coverage by JavaScript tests contributes to the
problem.)

By comparision, the Closure Compiler examines your entire program and provides
many compile-time checks that can help
you find errors before running your code. If Douglas Crockford claims that
JSLint will hurt your feelings,
then the Closure Compiler will put you into therapy.

"I never knew how sloppy my JavaScript
was until I started using the Closure Compiler.
Good grief!"