Part 3a. Our Deep Dive into JavaScript

The Slow Descent

OK, I hope you had fun playing in the sandbox, but it's time to get serious and dive deep into the subject of JavaScript. However, if you ask any scuba diver, they will tell you that you need to descend slowly if you are planning to dive deep, so we will take their advice. There is a lot to know about JavaScript. In the first two sections we barely skimmed the surface, but we learned about data types and several different operators which will help us out immensely as we descend deeper into this subject. In the sandbox, we really did not write any JavaScript code. And while prompts and alerts offered us quick-and-dirty ways to get input from the user, and to send output to  the user, we really did not write any JavaScript code that interacts with the DOM, which is the static web document we create using HTML and CSS, but JavaScript makes our web pages dynamic. So let's begin.

Comments

Let's begin first with a quick discussion about comments. You've probably already noticed that well-commented code is generally helpful to yourself and to some other web developer who may be looking at your code weeks, months, or even years from now, long after you've forgotten what each specific block of code was intended to accomplish.

In HTML, comments use this format:   <!-- This comment was intentionally left blank. -->
And these comments can cover multiple lines as long as the comments are between the opening <!-- and the closing -->

In CSS, we use this commenting format:   /* This comment was intentionally left blank. */
And these comments can cover multiple lines as long as the comments are between the opening /* and the closing */

In JavaScript, we can use this format:   /* This comment was intentionally left blank. */
And these comments can cover multiple lines as long as the comments are between the opening /* and the closing */
But we can also use // This comment was intentionally left blank.
As long as this // comment does not exceed the length of one line.

Symbolic Syntax

Before we begin writing JS Code in VS Code, we should talk a little bit about syntax and convention. JavaScript is a language that uses lots of symbols and punctuation marks to define its structure. As you learned in the lessons about operators, it seems like each and every little piece of punctuation has some meaning in the JavaScript language. That includes periods, commas, question marks, exclamation marks, single quotation marks, double quotation marks, equal signs, colons, semicolons, asterisks, back-slashes, forward-slashes, and even backticks. Yes, the list seems endless, but good JavaScript programmers learn what each one means, and that specific knowledge makes this language much easier to understand.

In this course, we will also talk about four different kinds of brackets:

1.   Parentheses → ()
2.   Curly brackets → {} also known as braces
3.   Angle brackets → <> also known as chevrons
4.   Square brackets → []

Once again, each one of these symbols has a special meaning, as you will soon learn. And in some instances, they can have different meanings depending on their usage and syntax. Traditionally in JavaScript, semicolons were used as delimiters, which means that they were placed at the end of each line of code to clearly separate them. These days, you might hear that ending each line of JavaScript code with a semicolon is completely optional. But there are times when that simply is not true.

Of course you will remember that in CSS, semicolons are required at the end of every single CSS rule, except for the very last CSS rule in each block before the closing curly bracket. Nevertheless, we recommend that you always end even that last line of CSS with a semicolon, so that you can add more lines of CSS to each block without getting errors. And we recommend the same with each line of JavaScript as well. It's just a good habit to get into.

We also recommend using single-quotes in JavaScript more often than double-quotes. This is mostly a matter of personal preference, but since HTML seems to be made up of mostly angle brackets and double-quotes, we believe that the syntax of JavaScript should be different. And you will find instances where you will need to use a different type of quotes inside an expression enclosed in single-quotes. And when that happens, we will use double-quotes to clarify the areas of separation.

However, JavaScript now has a way to use backticks to enclose an expression, and without getting too deep in that right now, you should know that these types of expressions are called template literals or simply template strings. And when it's time to learned about them, you will wonder how you lived so long without knowing about them. Anyway, that's enough said for the moment. Let us refocus.

Whitespace

The fact that JavaScript uses all of these various pieces of punctuation means that whitespace is mostly unimportant. By definition, whitespace is all the areas in a page of code where there is no code. And that includes the tabs, extra spaces, blank lines, and indentations in our code that might make it look pretty and easier to read. But other than for the purposes of readability and aesthetics, whitespace has no meaning to the rest of the code. And if you use a code autoformatter like Beautify or Prettier, it makes your code look nicer, but you could remove almost all of the whitespace by using a minifier that crams all of the code together into fewer lines of code, and then the file sizes would be smaller and the code would supposedly run faster.

But you simply cannot do that in a language like Python, which was designed to work without  a lot of punctuation. Instead, Python relies on indentation and whitespace to work correctly. We JavaScript programmers generally dislike using Python because whitespace is invisible, and that makes Python code harder to debug because you can't easily find errors that are invisible. On the other hand, Python programmers sometimes think that JavaScript programmers are punctuation nuts. But JavaScript errors are seldom invisible. So we say, "Choose your poisons carefully!"

And before we move on, we wanted to mention that whitespace is mostly unimportant to all three of the web development languages: HTML, CSS, and JavaScript. And to prove this, we offer two new projects that use all three languages. And we don't expect you to understand all of the JavaScript code used here. But please notice that all three languages are separated into three separate files of pure HTML (index.html), pure CSS (style.css), and pure JavaScript (script.js).

Go Fish!

We simply cannot do a deep dive without seeing any fish! And we apologize to Dr. Seuss for stealing from the title of one of his best-loved books. By now, you know the drill. Go ahead and download this Dr. Seuss project, and also this Dr. Seuss Minified project. Then you can unzip the two projects, and open them one at a time in VS Code and run the project code using Live Server.

The JavaScript code in this project changes the image and the heading with each mouseover and mouseout event. Yes, it's silly. But it's also fun. But the reason why we wanted you to look at this code is to see that whitespace does not matter. After you've looked at all three files in the Dr. Seuss project, close that project, and then open the Dr. Seuss Minified project and look at the same three files. Both of these projects are identical in function, but the Dr. Seuss Minified project code was compressed using this website: Minifier.org. There are several different free websites that allow you to minify your web project code, but we used this one because it is the simplest to use. Anyway, the bottom line here is that whitespace does not matter in HTML, CSS, and JavaScript. This is your proof. So Go Fish! ... but watch out for the Python.

Case Matters

Another important thing to know about JavaScript is that it is indeed case-sensitive. For example, a variable named mybutton and a variable named myButton are considered to be two different variable names by JavaScript. For the most part, we tend to use lowercase letters wherever possible, but sometimes we mix uppercase and lowercase letters together, especially when naming identifiers like the names of variables and the names of functions. So always be mindful about the case of any naming convention you use in JavaScript.

One oddity that sometimes confuses people is that CSS properties like background-color and margin-top cannot be manipulated by JavaScript using that name. CSS requires these property names to use kebab-case, but JavaScript cannot use these same names. Instead, it requires that CSS property names be converted from kebab-case to camelCase. And in that case (pun intended), background-color becomes backgroundColor, and margin-top become marginTop. See the difference?

Case In Point

OK, as much as we'd like to avoid this discussion, it is necessary for anyone who wants to become a programmer. So without further ado, let's discuss case. You probably already know the meanings of case-sensitive, uppercase, and lowercase, so we will not discuss those terms here. But we will discuss:

1.   kebab-case → words separated by hyphens after the spaces between them have been removed.
2.   snake_case → words separated by underscores after the spaces between them have been removed.
3.   camelCase  → words separated by capital letters after the spaces between them have been removed.
4.   PascalCase → words separated by capital letters after the spaces between them have been removed.

And what obviously distinguishes camelCase from PascalCase is whether the first letter of the identifier is capitalized or not. These four naming conventions listed above are used in various programming languages. For instance, PascalCase originated in the programming language called Pascal. And does it seem like a coincidence (or an irony) that Python prefers snake_case when naming identifiers like variables and functions?

In JavaScript specifically, camelCase is typically favored as the prevailing convention for the names of variables and functions, but PascalCase is often used to name classes. JavaScript does allow snake_case, but it is not commonly used.

But JavaScript does not support kebab-case, even though HTML and CSS does! In HTML, class and id names are often named using the kebab-case naming convention. And in CSS, properties are almost always named using the kebab-case naming convention. But the sole reason why JavaScript cannot support kebab-case is because the hyphens used between the words can be interpreted as subtraction operators by JavaScript, and that can cause some real problems. Think about this for a moment. If you were JavaScript, and you saw a hyphen between two words, would you think that the programmer wanted you to subtract one variable from another variable? So for that reason alone, you should always refrain from using the kebab-case naming convention in JavaScript. But don't worry about this too much because JavaScript will not allow you to use kebab-case, even if you unwittingly try.

And although you might find instances of the word Javascript spelled with a lowercase  s, its proper name is written in PascalCase and spelled with an uppercase  S as JavaScript. So if you intend to become a professional, then you should call your chosen programming language by its proper name. And there must be a nut🌰case joke in here somewhere, but we will avoid telling it.

Space Case

One final warning: Don't be a Space Case! Oh yes, it's true that we just assume that you know better than to allow spaces in your file names. For instance, a file name like "space case.jpg" will be handled by your chosen web browser, but this is considered to be unprofessional and bad practice. A camelCased file name like "spaceCase.jpg", or a kebab-cased file name like "space-case.jpg" is considered to be much more acceptable and professional. And of course you already know better than to put spaces in the names of elements, tags, classes and ids, right? If you were silly enough to write code like this: <div class="space case">, then your browser will interpret that as two classes for the same div. And CSS will not like it of you define a rule with .space case { }. But you already knew this, so let's unapologetically move on.

Version Numbers

It was decided long ago by the the World Wide Web Consortium (W3C) that the current version of HTML would be called HTML5, and that constant revisions to its version number would be avoided. And even though they relinquished the responsibility for maintaining and regulating the standards of HTML and the DOM to the Web Hypertext Application Technology Working Group (WHATWG), the World Wide Web Consortium (W3C) still maintains and oversees the standardization of CSS through the CSS Working Group (CSSWG) of the W3C. But similar to the way that all future HTML development will not have actual version number and will be henceforth known as HTML5, CSS is similarly now called CSS3 to avoid similar version number nightmares, even though something called CSS4 appears to be in the works (and some people actually whisper CSS5). Nevertheless, web stability is their goal. And so far, this policy in practice seems to be the best version number control system.

JavaScript is a little harder to nail down as far as their version number controls go. But the organization responsible for maintaining the JavaScript standard, Ecma International has decided that one version upgrade per year is sufficient, so currently the version of the JavaScript standard (which is also known as ECMAScript) is the 16th Edition, ECMAScript 2025. And the 17th Edition, ECMAScript 2026 is currently in the works, and could be releassed as soon as June 2026.

And to be perfectly fair and honest, there have been many changes to the JavaScript language since its invention in 1997. And so there are actually two different schemes for maintaining version number controls. There is the Edition system, and by that system, we are now on the 16th Edition. But there is also the ECMAScript system, and by that system we are now on ECMAScript 2025. Put them together and the current version is now the 16th edition, ECMAScript 2025.

"Why is this important?" you ask. It is important because in 2009, the release of ES5 offered many new improvements. And in 2015, the release of ES6 was also a major change to the JavaScript language. When reading about JavaScript, you will sometimes see ES5 and ES6 mentioned because the changes to JavaScript in 2009 and 2015 were so massive. And also because there was a war brewing between the various web browser manufacturers at the time. ES6, later named 6th Edition, ECMAScript 2015 was basically the truce that ended that war. Here is a link to the complete listing of the ECMAScript version history. However, W3Schools also has a comprehensive listing of JavaScript Versions with more details on the many changes offered by ES5 and ES6.

Other software version control systems are much more chaotic and ever-changing. This week, our version of Chrome is 148.0.7778.168, but that version number will certainly change in the next week or so. This week's version of Firefox is 150.0.3 and that is also bound to change again soon. This week's version of Opera is 131.0.5877.55, but it is running on Chromium version 147.0.7727.138. Regardless of the current dominant web browser market share statistics, it almost seems as if web browser manufacturers intend to win the "Browser War" by having the highest version number. For this reason alone, it seems fitting that web standards are now being maintained by neutral parties rather than by corporations.

And if this seems to you like TMI, that is because is probably is too much information. There will not be a test on this material later, but it is sometimes helpful to know a little bit of JavaScript history when reading an article that mentions something like ES6.

Buried Treasure

The main goal for many deepsea divers is to locate and salvage buried treasure. So we are providing this little treasure map to help you along the way, if that is indeed one of your goals. There are lots of books out there written on the subject of JavaScript, and having just one authoritative and definite guidebook is often the best way to go. So for you, we strongly recommend this book: JavaScript: The Definitive Guide. As previously discussed, computer technology books in print often have the serious disadvantage of being outdated and obsolete, sometimes even before they ever make it to the bookshelves of your local bookstore. This book is in its 7th Edition which was released in publication way back in 2020. And as previously mentioned, the current version of JavaScript is the 16th edition, ECMAScript 2025. But don't let that discourage you from buying this book because only incremental additions to the language have been incorporated in the past five or six years. Please remember that the most massive amount of improvements happened with 6th Edition, ECMAScript 2015, often called ES6 for short. And the author, David Flanagan, had another five years to make certain that all of the ES6 changes were well-documented before this edition of the book was published.

Of course there are times when you don't need Encyclopædia Britannica. Sometimes you simply need a quick reference. And for those moments, we recommend these handy online reference sources from W3Schools: First of all, there is this W3Schools JavaScript Tutorial. We believe that this source of information is best used as a quick online guide. And if we thought that their JavaScript Tutorial was superior to ours, then we certainly wouldn't have invested our time in writing this one. Their tutorial is certainly less verbose than ours, but our tutorial offers in-depth explanations and comprehensive coverage rather than quick code snippets. But sometimes, snippets of code are all you really need to make continued progress. And to that end, they also offer these W3Schools JavaScript Examples which are a nice collection of code snippets that you can quickly learn from. But best of all, they off this W3Schools JavaScript Reference that has an alphabetized index of topics for your convenience. All three of these links offer something different, so please take the time to explore all three of them on you own.

Another excellent source of online JavaScript information is MDN Web Docs JavaScript Reference. MDN was formerly known as the Mozilla Developer Network. And the author of the JS definitive guide mentioned above, David Flanagan, works for Mozilla. So it should be no big surprise that MDN Web Docs are very comprehensive and authoritative. The only real downside is that deep explanations can often be over our heads when we are just learning. Nevertheless, when W3schools fails to give us detailed explanations that solve our problems, we immediately try MDN Web Docs next.

We also like these excellent sources of JavaScript information as well:

•   JavaScript Info → The Modern JavaScript Tutorial
•   The JavaScript Handbook → written by Flavio Copes
•   The Valley of Code: JavaScript → written by Flavio Copes