This series is not for beginners of programming. Also, this series on writing about original JavaScript is not about taking sides. I do not have the knowledge to know the thoughts of Brendan Eich or Netscape, leading to the implementation and advancement of the JavaScript language. I’ve been learning the language from the perspectives of functional programming lovers, prototypal inheritance lovers, and Java/C++ lovers. All of them have things that they love and things they hate in JavaScript. Personally, I think the love/hate relationships make up the magic in JS. Don’t like doing it this way? Do it that way. With JavaScript, no one wins or loses arguments. It is what it is. If ECMA was to take away something from the language, it would die. On the other hand, the future of JavaScript is bright. No one wants to replace it. JavaScript tests the true nature of software developers. It is far away from being a perfect language, but it is probably closer than Java in many respects. If you read this and disagree with my opine, keep in mind that I’m only portraying JavaScript from a positive point-of-view. When I say original, I really mean JavaScript as of ES5, before ECMA added classes, a constant, and block-scoping.

Brendan Eich was a quite advanced developer when he demonstrated his prototype for a web browser programming language to Netscape ten days into development. So much so that Netscape implemented that prototype! Ten days is not enough time for a brand new programming language, but that was the first miracle in the life of JavaScript. The second miracle was Microsoft’s reverse engineering of that initial product. When Netscape approached ECMA (European Computer Manufacturers Association) to create a standard, Microsoft was on the board and because of their version of JS, wanted nothing to be taken away from what existed.

These two so-called miracles allowed for Eich’s vision to remain. Sun Microsystems, the creator of Java, wanted the world to adapt their Object-Oriented language to be the standard for everything. JavaScript was based on Scheme and Self, two diametrically-opposed types of language philosophy. This has created a tug-of-war between developers who love Scheme’s use of first-class functions (functions that can represent values) and inner functions (functions nested into other functions), and C++ developers who were adopting to Java and wanted JavaScript to deal with classes, inheritance and encapsulation.

JavaScript has always been object-oriented, but not in the C++/Java sense. Those languages are directly based on Smalltalk, for some, the best language ever. But the Self language, the other language mentioned in JavaScript’s birth, is also based on Smalltalk. The difference is that Self did away with classes and used prototype-based object construction. Self was initially developed by Xerox at their PARC facility where Smalltalk was created. Ironically, Randall B. Smith continued development at Sun Microsystems where Java was created. Here is a video about Self in a true object environment, Smalltalk-style. Self also is a two-compiler system like modern JavaScript engines. This video would have me calling JavaScript, LiveScript (JavaScript’s original name). Whatever happened to the dream of doing away with the classical approach of computer programming? (See the video.)

At first, inner functions weren’t available but when they became available, developers renewed interest in using enclosures of values (called “closures” to help confuse everyone). When outer functions were taken off the stack, the inner function values would remain available. These values don’t clutter the global environment; they are lexically-scoped. While Scheme developers had to deal with some problems with functional-scoping and stacked environments, JavaScript placed execution records, application records, code and references into heap memory instead of the stack. Change the variable that holds the closure and the garbage collector will erase them. Today, the other major programming languages are adopting closures. Not bad for a flawed language.

Up until ECMA’s ES6, JavaScript didn’t have classes and lacked constants and blocked-scoping. Variables created with var are function-scoped. In order for these variables to act like they’re block-scoped, outer and inner functions had to be used. Pure functional programming requires full immutability, so var was bad from the start. ES6’s let and const are block-scoped. Having constants available is an improvement. For Java programmers, classes and class-type inheritance became available. For lovers of prototypal inheritance, nothing was taken away.

Closure members can be public, private or privileged. For those who’ve been told that there are no private variables in JS, think about it. The outer function parameters are always available in an inner function, even when the outer function is taken off the stack. The new keyword has been around to construct objects in JavaScript. This allows what is called a constructor function to act as a class for creating objects that can share the same parent prototype. This is what allows for prototypal inheritance. I will have some examples next time. The danger in JS constructor functions is that if you invoke that type of function without new, that function will not act as a constructor.

More to come in this series, but before I end this don’t think of JavaScript (or PHP, Python and Perl) as just a scripting language. It is powerful enough for advanced computer scientists to love. Yes, if compiling the source code into executable code before running it is what is taught as true coding of applications, then JavaScript is not a application language. Unfortunately, there are developers who think that JS is a scripting language. When I think about scripts, I think of batch files. Coding in a shell language (cmd, bourne-shell, BASH, etc.) is a scripting language. JavaScript should be considered a hybrid language. I once wrote a special TFTP server in Perl. This is because I could take the RFC for TFTP and construct or deconstruct packets in Perl! I couldn’t sell the application as a product, but it served the purpose at the time and it required some advanced knowledge. JavaScript engines are virtual machines like Java’s JVM. Using two compilers and Just-In-Time compilation, JavaScript coding still requires knowledge of data structures and algorithms in order to trade off space complexity, time complexity and readability to make a scalable application.

More to come…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.