What JavaScript’s Object Prototypes Aren’t

I am so sick and tired of hearing JavaScript proponents go on and on about how wonderful object prototypes are, along with prototypal inheritance (whether it’s concatenation or delegation). Let’s set the record straight…

We’ll begin by remembering why JavaScript was created. Brendan Eich wanted a light, breezy, scripting language for the web browser that was flexible and forgiving. It was never intended for serious software engineering. The qualities that make it flexible (e.g, object prototypes and loose typing) are the same qualities that work against good engineering. For all of ECMA TC39’s efforts, this has not changed.

Think of prototypes as the basic building blocks for an object-oriented programming model. In and of themselves, they are not a particularly high-level abstraction. They are, indeed, light and flexible. This is what makes JavaScript fun and easy to use.

JavaScript experts like to tout object prototypes as a superior means of doing object-oriented programming (OOP), but the truth is, the IT industry has roundly ignored prototypes, and for good reason. No other notable language created in the past quarter century has adopted object prototypes, except for 23-year-old Lua. The industry has shown a clear preference for class-based OOP, because while classes do have their problems, there is (currently) no better way to organize large-scale application code (say, in the hundreds of thousands of lines). Object prototypes would fall flat on its face here.

Languages like Smalltalk and C++ are capable of writing programs as big as a million lines of code. JavaScript would be hopeless in these situations. Apparently, ECMA recognized this and tried to accommodate the popularity of classes.

However, the latest ES6 class feature is only a half-assed implementation of class-based OOP. It’s just syntactic sugar over object prototypes. It still doesn’t support private state (member variables) in the way we expect. Member variables must be “faked” through a variety of workarounds such as programming convention, capturing normal variables with closures, and employing WeakMaps. ES6 is not a proper class-based OOP language like Smalltalk, C++, C# and Java.

Conclusion

Object prototypes make JavaScript a fun and easy language to use. However, they are not congruent with the goals of software engineering, esp. at scale.

Leave object prototypes where they belong: as a means of experimenting with ideas and prototyping applications. But when you get down to the brass tacks of engineering, you must use higher level abstractions that help you organize your code better…such as classes.