I’ve set aside some time to take some online courses at FrontendMasters to deepen my understanding of various engineering principles as a personal continuing education goal. While taking courses I focus by taking notes, and figured I may as well share them with the world, so welcome to the Learning Series!
The first course is The Good Parts of Javascript and the Web, by Douglas Crockford. The course description is as follows: “In this course, you will learn the history of JavaScript, the details of the language, with particular attention to functions, which is where the power of the JavaScript language is hidden. There is also an overview of how browsers work, how servers work, and security.”
This writeup got a little long because I found so much of the course interesting, so here’s an outline – feel free to jump to the bits you find interesting:
Introduction and Background
Douglas Crockford is the author of the classic title from 2008 that many refer to as the go-to introduction to the JavaScript language: ‘JavaScript: The Good Parts‘. At the time, many classic developers complained about the backward ways of JS, but he wanted to point out the good parts. He’s also the author and maintainer of JSLint since 2002 (the first JavaScript syntax checker) ando behind JSON – he coined the acronym (though wishes now he thought of something better) and was involved in popularizing the data format.
For those that are excited about licenses and things, Crockford also famously used the MIT license in his tools but with a slight modification: He adds the line “The Software shall be used for Good, not Evil“. This is part of the licensing in JSLint as well as JSON. Yay for Good, is your JSON used for Good?
JSLint
JSLint is a static code analysis tool used for checking if JavaScript source code complies with certain coding rules. Douglas states that JSLint “will hurt your feelings”. As linting tools goes, it’s fairly opinionated but in his course he explains many of the reasons for these strong opinions which in his opinion are backed by data and a philosophy that:
Good use of coding style can reduce errors, so JSLint helps us to prefer forms of writing code that are error resistant. For example, the roman language initially was all caps and had no punctuation. Scribes would copy written statements and errors would creep in over time. Roman scribes invented punctuation and lowercase letters for legibility. It showed that they could copy with less errors by using these coding styles. In the same way, writing code today doesn’t need to be illegible. Let’s fix it by creating some punctuation rules that will help us and the computer read it better. Additionally, let’s have something that helps us avoid the time loss we tend to endure when finding and fixing bugs. We end up wasting so much time because our mental model of how JavaScript works, is not actually how it always works. Some of the coding issues are because of the discrepancies in how our brains understand the language and some of the issues are a result of badly designed features of the language itself. Some (opinionated) guidelines that come from JSLint for writing better JS include the following:
- Left or right curly braces? Right is better, some cases of using left will silently break your code and you could waste time diagnosing the simple fix. So consistently use curly braces on the right, because you will never have this problem.
- Always manually add semicolons – don’t rely on the computer to automatically add them because they sometimes get added in unintuitive ways which can dangerously break your code if you leave it up to the machine.
- Don’t use “with” statements in order to avoid confusion on how “with” loops work slightly differently than others.
- Always use triple equals
Not using some of these smart best practices is the equivalent of pointing a gun at your foot and saying “Watch this, I almost never miss!” You might miss, but you might not and the more times you do it, eventually you don’t miss. That would be a tad uncomfortable.
History Lessons
I am a big fan of history, so I really enjoyed the historical sections of this course. In the course, Crockford discussed the history of JavaScript, the history of HTML and even browsers and the internet. I feel like we can better understand the current situation of the web if we understand where it came from. In always keeping up and being focused on the most modern and latest updates, it’s easy to lose sight of where it all came from. It’s easy to curse those days since today we are still living with legacy issues. Anyone that’s been in the industry for a while can easily remember the frustrations involved with table based layouts and also the collective salvation we found in jQuery. In learning the history, though, I was constantly reminded that those involved were doing the best they could with the limited information, time and resources they had.
History lesson of JavaScript
Brendan Ike was tasked with creating a script language for Netscape and wrote the prototype in just 10 days! Talk about a tight deadline! Javascript was greatly inspired by hypercard from Apple. He also pulled in features from other languages: he used the inherited syntax from Java, brought in functions from Scheme, removed classes from Self/Smalltalk. It was first called Mocha, then Livescript and was built into the Netscape Navigator 2 browser. Soon after, Sun and Netscape teamed up to beat the giant Microsoft. Sun backed Java and wanted to replace JS with Java in the browsers. Netscape was supposed to remove LiveScript, but they forced it being kept to load the Java, slyly making it required rather than getting rid of it. This is why it started being called JavaScript – since it’s purpose was loading Java. Javascript was thought of and called Java’s stupid little brother.. but with hindsight, now we all know how well Java applets did.
In order to stay relevant, Microsoft created their own browser. To compete, they reverse engineered JavaScript for IE – along with all it’s odd behaviors and bugs. They called it Jscript, so as not to use the name of a competitor, which was a good call, since Sun went on to sue anyone who used the word Java, including coffee shops and even whole islands.
In the meantime, Netscape went to W3C to standardize the language but were actually denied because W3C was not interested. Eventually, they ended up at the European Computers Manufacturing Association (or ECMA), which is a long way to go for a California software company. They created a committee at ECMA and then Microsoft ended up joining and dominated said committee. They insisted that all the bugs and defects remain in the standard to keep backwards compatibility, and since they already had all the bugs documented, it was agreed. The sticky part was that the committee couldn’t agree on a name (JScript, Javascript and LiveScript), so they published the standard as ECMAScript. Which explains why we call it ES6 (etc) today.
JavaScript as a language is what we call it, but officially it’s ECMAScript. The standardization came about in 1997 and updated to ES3 in 1999. ES4 was abandoned due to political differences concerning the language and, so eventually in 2009, ES5 was released a full 10 years after ES3. Then, 6 years later, ES6 became official in 2015.
There are certainly bad parts in JavaScript These bad parts come from a combination of the haste in which it was first created and good intentions of the creators (trying to make the language easy – especially for beginners), and this complex legacy codebase to keep backwards compatible. The proof of concept, when created so quickly, was not intended to be so widespread, but has now become the most used programming language in the world!
History of HTML
HTML also has a long meandering history. There was a markup language used for print called Runoff. This led to another called ROFF. To standardize a few things they came up with Generalized Markup Language. Then Standard Generalized Markup Language (SGML) brought angled brackets and attributes from another markup called Scribe. Hypertext Markup Language was also influenced by apple’s hypercard. XML then came in to make a claim to standardizing the markup.
It’s very interesting to me to look at this example of GML and see how clearly it influenced HTML. I feel like a digital archeologist looking through old code to better understand current code.
Fun Fun Functions
There is an entertaining and educational part of the course where we are provided with a synopsis of a fairly simple function, given time to write our own, and then discuss the “best” solutions. It ended up being nearly 50 exercises and accompanying functions. They tended to build on each other as well, so it was a nice programming challenge and throughout I learned a good deal and through discussing them began to see the simplicity and even genius of functional programming even more. Below is a gist I created showcasing the functions I tried to write the requirements for each function in the comments. The function exercises I most enjoyed were the recursion and curry functions but they also touch on higher order functions, closure, generators, factories and factory factories.
https://gist.github.com/circlecube/3ead7d1a46f57842a8b7276698eb3ca4
A quick dive into scope and closures
The course had a nice section that was a helpful framing for closures. Which is a fairly complex and misunderstood concept in JavaScript that stumps many hopeful applicants interviewing for a web engineering role. To get to closures we first needed to look at function scope.
When a variable is defined in a function it is scoped to that function and can be used within. For example below, the variable a can be used within the green and the yellow functions. The variable b can only be used in yellow. The a variable will stick around in memory as long as there is a function with a reference to it.
If we return the inner function then the a value will be encapsulated in the scope, this is what we call a closure. The yellow function can be used and will have access to the a variable, even though it isn’t defined in the function. This is called a JavaScript closure. It makes it possible for a function to have “private” variables.
Web Security
The course pressed the point that “There is no security in obscurity” and that “Security must be factored into every decision”. In fact, having a false security is worse than no security at all, because it puts us at ease. We tend to have a false way of thinking when we say things like “We’ll make it secure later”. In reality if we understand JavaScript, we can use it to enhance our security, since it should be built in rather than tacked on last.
Many principles of security come from cryptology and ciphers. Auguste Kerckhoffs, author of a military cryptology book in the 19th century, states that a cryptosystem should be secure even if everything about the system, except the key, is public knowledge. Today we still follow this principle.
The web does get an important security issue right that much other software does not. It doesn’t blame the victims. In other platforms we see a lot of “blame the victim” security models. It’s where we’ll ask the user a question that the user cannot possibly understand or answer correctly. And then when things go wrong it’s the user’s fault for having agreed to this. That’s not a security model, that’s just…stupid! It’s similar to signing every right to privacy away in a legal document before using a product. The browser doesn’t do that (by default). Now the price of that is that the browser is limited in some ways. It’s up to us, the builders of the web, to be smart about how we reduce those limitations in responsible and secure ways. For the sake of security, we must think “Whose interest does the program/website represent?” The user, the site owners, the third-party ads?
We need to alter the way we understand security. We need to better understand the mechanics of the JavaScript language because the most dangerous flaws are the ones we see as a result of misconceptions in how the language works. Our mental model may not reflect what actually happens in the language. Douglas then leads the course through a couple interesting security discussions where attendees work to understand and find security loopholes.
Conclusion
In the end, we as engineers are emotionally connected to our code and as irrational as any other human. We like to think we are smarter than average, but really we’re all human. We should use things like JSLint (or the 10up eslint code styles) to help us write better and more secure, cleaner code.
I found the course entertaining, educational. It helped me understand the ecosystem of the web by seeing a little more clearly the history of the technologies. The top points of the course for me were the history lessons and the function exercises. I recommend taking this course if this subject matter sounds interesting to you, be aware though that Douglas is as opinionated as JSLint and at times projects a smarter-than-thou attitude which some may find off-putting.
Have you taken the course? Read his book? What were your highlights?
