This post starts with an apology for taking too long to write a new post. When I did my thirty day challenge it started with a goal of being a writer, but ended with a goal of renewing my software development career. In the past couple of months all of my free time has been reinventing myself and preparing to be more advanced than when I left my career three years ago. The initial choice was Python, but then JavaScript became something I loved more.

When I first encountered JavaScript on Netscape back in the mid-nineties, it didn’t look like Java. At that time Java was of interest and JavaScript looked foreign to me. Also, Microsoft was trying to prioritize their own command set for their flagship Explorer browser. I couldn’t predict JavaScript’s future and avoided it. PHP seemed to me a better direction (It kept me focused on full-stack development). Today my view of JavaScript is different, and I’m not talking about its phenomenal path. The future really looks bright for this conceptually complex language and how it could end up a core language in an endless number of devices and applications.

I don’t know enough about Brendan Eich’s philosophy that led to JavaScript. Eich’s intention was to embed Schema into the browser. Schema is a purely functional programming language based on Lisp, and for C, C++ and Java developers, it would’ve required some time to change the whole thinking process when developing apps. But that’s as far as what I know about Eich’s intentions. What JavaScript became, opened a door for visionaries a dozen years later when Google needed a browser that could run their Google Maps and get rid of the need for a separate application. Google’s development of the V8 JavaScript engine, a feature of their Chrome browser, also led to Ryan Dahl’s Node.js allowing JavaScript to be used outside of a web browser.

One need that JavaScript filled was to get CPU processing away from the web server. As the World Wide Web grew in popularity, more back-end servers were needed to handle thousands upon thousands of concurrent HTTP requests at one time and process the responses concurrently as well. When one application, in this case Apache is running many parallel threads are created and the complexity of managing these threads without memory leaks, stack overflows and other probable bugs, created the art of the website crash. There was a time when a website would crash if an onslaught of surfers reacting to a “check this out” at another popular website would take down the server. Notice how that doesn’t seem to happen anymore. Facebook is the best example of today’s websites. It is JavaScript that came to the rescue.

This is because JavaScript is not running on the web server. If 50,000 users are on Facebook concurrently, 50,000 web browsers and iPad, iPhone, Android applications are sharing in the CPU processing. Facebook does need many many servers to handle their users, but each browser also becomes part of the server farm. It makes it harder for Facebook to crash.

This is an introduction to original JavaScript. A committee called ECMA oversees the handling of standards that all web browsers must comply to in order for websites to be viewed similarly. The different web browsers have different JavaScript engines. They do a good job of complying with JavaScript standards, but the connecting APIs that interact with HTML and CSS act differently and so nothing is perfect. ECMA has done a good job of making these standards, but they’ve also added to JavaScript’s command set in order to make JS more like Java and C++.

If these newer features were an issue, JavaScript would’ve died a long time ago. There are power-developers that were gurus before ES6 and beyond, when the new command sets were introduced. That is why the original JavaScript command set is still well-liked and used today. As I post subsequent articles, I’ll write about these features (and bugs) that made JavaScript an appealing language. I’ll write how a single-threaded just-in-time compiled, i/o-blocking engine could be programmed to time-manage many tasks to make it look like it’s doing many things at once. This series will also delve into JavaScript by itself and with the web browser APIs that provide the magic you see in the display.

What I didn’t understand about JavaScript in 1996, I love today. Hopefully understanding the core concepts of first-class functions and prototypal inheritance will help you understand how combining object-oriented concepts with a functional core works. I will go into how the execution context creation phase deals with var and function (but not with const or let) and its necessity with scope and closures (all cool JavaScript concepts). This will tie in with perhaps the most popular function library created for and in JavaScript called jQuery. All of this is before the newer “class” methods and other object-oriented features were added. I’m also writing these to help me get back into my career. I hope these will benefit others too.

The Photo at the top is looking west, to Sarasota from the Celery Fields, the highest elevation in the area.