A TypeScript project incurs some overhead versus a plain JavaScript project. This is an unavoidable fact of TypeScript’s nature compiling to JavaScript. Investing in this overhead can pay off for larger projects, but how large is large enough to benefit? I expect I won’t have a good grasp of that payoff point until I get more experience, but I think I have a better idea after going through Codecademy’s “Learn Intermediate TypeScript” course.

Codecademy is very proud of their browser-based integrated learning environment where students can learn and put what they’ve learned into practice immediately. But this particular course is focused on how we can put TypeScript to use in our own projects outside of Codecademy’s environment. The hands-on portion of course consists of downloading ZIP files of partially complete TypeScript projects to our own computers, then following instructions to see what happens.

Under this system, we get experience running the TypeScript compiler tsc at the command line directly, and inside the context of a project managed via npm and its associated package.json file. This is also where we can keep our TypeScript configuration in a tsconfig.json file. This feels like a good way to use TypeScript. If we’re already incurring the overhead of setting up such a project, it doesn’t take that much additional effort to fold TypeScript into the works.

Amusingly, the most important lesson I learned from this course had nothing to do with TypeScript but was about setting up JavaScript projects with npm. Early on, we were instructed to run “npm run tsc -- --watch” and “npm start -- --watch” but without explaination what those two commands meant. I took a detour to try to figure out exactly what went on with those two lines.

The first part is easy: we’re running something via npm command line tool. That something is listed inside the “scripts” section of package.json. It can be a direct mapping: “tsc” mapped to the TypeScript compiler executable. Or it can be something more complex, as “start” mapped to “nodemon build/index.js” I’m still uncertain about the “run”, as it seems to be optional and/or the default action. Inferred from the fact it was present in one but not the other.

The next item was challenging: “–” What does the double-dash mean? Unfortunately, I found it impossible to perform a web search on “–” and get relevant results. A combination of the fact “–” isn’t a word we can search for and that it is used in many different contexts (C programmers know it as a value decrement) but I didn’t wasn’t sure what context to search within. It wasn’t until another page later on in this course that I learned “–” tells npm to stop interpreting command-line parameters and pass along everything afterwards to the script. So for example, “npm tsc — –init” means: Use “npm” to launch command “tsc” described in package.json. Then “–” meant there are no more parameters for npm, and “–init” should be given to “tsc”. Result: use the current Node.js environment to run command “tsc –init”

This all made sense once I figured it out, but I certainly couldn’t have guessed it from just looking at “–“. There will be more unknowns as I dive back into Angular framework documentation with “Understanding Angular”

I want to go back and take another look at Angular web application development framework, because I’ve learned a lot about web development since my earlier attempt. But before I do, I want to review TypeScript, which is what Angular uses to tame some of JavaScript’s wild nature. Conveniently, Codecademy has a “Learn TypeScript” course for me to do exactly that.

As its name implies, TypeScript imposes some of the benefits of data type enforcement to JavaScript’s default data type system, where anything can go anywhere. The downside of JavaScript’s flexibility is that it also allowed many bugs to hide until emerging at very inconvenient times. While it’s always possible to move to an entirely different language if type safety is desirable, the beauty of TypeScript is that it maintains full compatibility with JavaScript so we don’t have to leave that ecosystem (JS runtimes, libraries, tools, etc.) to gain benefits of compile-time type checks. TypeScript accomplishes this magic by performing its checks on TypeScript source files. Once everything has been verified to be satisfactory, that source code is translated to standard JavaScript for execution.

But before that compiler runs, TypeScript syntax gives us a lot of tools to organize our code to catch bugs at “compile” time. (More accurately TypeScript-to-JavaScript transpiling time.) There are static code analysis features to find problems. Starting with simple ones like a mistyped variable name would get caught because it has no declared type. We also get (illusions of) features like enum so we can constrain values within a defined valid set.

However, in order to stay compatible with JavaScript, TypeScript couldn’t offer all the rigorousness of a strictly typed language. There are various middle ground features sprinkled throughout so we don’t have to take all-or-nothing. The type guard of “[property] in [object]” aligns with “duck typing” patterns: checks for the method we care about instead of the exact object type or interface. It was also amusing to see support for generics, which is becoming a feature in strictly typed languages but now we have it in TypeScript as well compiling down to “do whatever you want” JavaScript. That leads to things like Index Signatures with no real counterpart in strictly typed languages, and I credit its existence to JavaScript for being weird. I wouldn’t blame everything on JavaScript, though. I sometimes stumble across TypeScript union types, which lets us support a limited set of types. In one practice exercise, we have an array that can be an array of one of two types. I typed TypeA[] | TypeB[] which made sense to my brain, but that was not acceptable. I had to use (TypeA | TypeB)[] and I still don’t understand why.

This course also exposed me to certain JavaScript things that were not specific to TypeScript. There was a brief mention of documentation comments: /** */ blocks that included markup like @param and @returns. I vaguely recall seeing this before but I no longer remember what this is called and the course didn’t give me a pointer. This course was also the first time I saw JavaScript rest parameters and its counterpart spread syntax. And finally, this is where I learned of number.toFixed() which I will definitely use in the future.

Like all Codecademy courses, this one gives us enough context for us to navigate product document on our own. In this case, the official reference is The TypeScript Handbook. Explanations in the handbook make a lot more sense to me after this Codecademy course than it did before, so I’d say “Learn TypeScript” was worth my time investment.

After going through Codecademy’s “Learn JavaScript” course, the obvious follow-up was their “Learn Intermediate JavaScript” course, so I did and I liked it. It had a lot of very useful information for actually using JavaScript for projects. The first course covered the fundamentals of JavaScript but such knowledge sort of floated in an abstract space. It wasn’t really applicable until this intermediate course covered the two most common JavaScript runtime environments: browser on the client end, and Node.js for the server end. Which, of course, added their own ways of doing things and their own problems.

Before we got into that, though, we expanded the first class’s information on objects in general to classes in particular. Now I’m getting into an objected-oriented world that’s more familiar to my brain. This was helped by the absence of multiple different shorthand for doing the same thing. I don’t know if the course just didn’t cover them (possible) or the language has matured enough we no longer have people dogpiling ridiculous ideas just to save a few characters (I hope so.)

Not that we’re completely freed from inscrutable shorthand, though. After the excitement of seeing how JavaScript can be deployed in actual settings, I got angry at the language again when I learned of ES6 “Default Exports and Imports”.

// This will work...
import resources from 'module.js'
const { valueA, valueB } = resources;
 
// This will not work...
import { valueA, valueB } from 'module.js'

This is so stupid. It makes sense in hindsight after they explained the shorthand and why it breaks down, but just looking at this example makes me grumpy. JavaScript modules is so messed up this course didn’t try to cover everything, just pointing us to Mozilla.org documentation to sort it out on our own.

After modules, we covered asynchronous programming. Another very valuable and useful aspect of actually using JavaScript on the web. Starting with JavaScript Promises, then async/await which is an ES8 syntax for writing more readable code but still using Promises under the hood. My criticism here is JavaScript’s lack of strong typing, making it easy to make mistakes that wouldn’t fall apart until runtime. This is so bad we even have an “Avoiding Common Mistakes” section in this course, which seems like a good idea in every lesson but apparently only important enough here.

Once async/await had been covered, we finally had enough background to build browser apps that interact with web APIs using browser’s fetch() API. The example project “Film Finder” felt a lot more relevant and realistic than every other Codecademy class project I’ve seen to date. It also introduces me to The Movie Database project, which at first glance looks like a great alternative to IMDB which has become overly commercialized.

After the Film Finder project, this course goes into errors and error handling mechanisms, along with debugging JavaScript. I can see why it’s placed here: none of this would make sense unless we knew something about JavaScript code, but a lot of these lessons would have been very helpful for people struggling with earlier exercises. I’m sad to think of the possibility that there might exist people who would benefit from this information, but never got this far because they got stuck in an earlier section because they needed help debugging.

The best part of this final section is a walkthrough of browser developer tools to profile memory and CPU usage. There are a lot of knobs and levers in these tools that would easily overwhelm a beginner. It is very useful to have a walkthrough that focused just on a few very common problems, and how to find them. Once we know a few places to start, it gives a starting point for exploring the rest of developer tools. This was fantastic, my only regret is that only applies to browser-side JavaScript. We’d have to learn an entirely different set of tools for server-side Node.js code.

But that’s enough JavaScript fun for now, onward to the third pillar of web development: CSS.

After reviewing HTML on Codecademy, I proceeded to review JavaScript with their Introduction to Javascript course (also titled Learn Javascript in some places, I’m using their URL as the definitive name.) I personally never cared for JavaScript but it is indisputably ubiquitous in the modern world. I must have a certain level of competency in order to execute many project ideas.

The history of JavaScript is far messier than other programming languages. It evolved organically, addressing the immediate need of the next new browser version from whoever believes they had some innovation to offer. It was the wild west until all major players agreed to standardize JavaScript in the form of ECMAScript 6. (ES6) While the language has continued to evolve, ES6 is the starting point for this course.

A standard is nice, but not as nice as it might look at first glance. In the interest of acceptance, it was not practical for ES6 to break from all the history that proceeded it. This, I felt, was the foundation of all of my dissatisfaction with JavaScript. Because it had to maintain compatibility, it has to accept all the different ways somebody thought to do something. I’m sure they thought they were being clever, but I see it as unnecessary confusion. Several instances came up in this course:

• Somebody thought it was a good idea for comparison to perform automatic type conversion before performing the comparison. It probably solved somebody’s immediate problem, but the long-term effect is that “==” operator became unpredictable. The situation is so broken that this course teaches beginners to use the “===” operator and never mentions “==”.
• The whole concept of “truthy” and “falsy” evaluations makes code hard to understand except for those who have memorized all of the rules involved. I don’t object a beginner course covering such material “this is a bad idea but it’s out there so you need to know.” However, this course makes it sound like a good thing “Truthy and falsy evaluations open a world of short-hand possibilities!” and I strongly object to this approach. Don’t teach beginners to write hard-to-understand code!
• JavaScript didn’t start with functions, but the concept was so useful different people each hacked their own ways to declare functions. Which means we now have function declaration (function say(text) {}) function expression (const say = function(text) {}) arrow function (const say = (text) => {}) and the concise body arrow function (const say = text => {}). I consider the latter inscrutable, sacrificing readability for the sake of saving a few characters. A curse inflicted upon everyone who had to learn JavaScript since. (An anger made worse when I learned arrow functions implicitly bind to global context. Gah!)

These were just the three that I thought worth ranting about. Did I mention I didn’t care for JavaScript? But it isn’t all bad. JavaScript did give the web a very useful tool in the form of the JavaScript Object Notation (JSON) which became a de facto standard for transmitting structured data in a much less verbose way than XML which originally promised to do exactly that.

JSON has the advantage it was the native way for JavaScript to represent objects, so it was easy to go from working with a JavaScript object to transmitting it over the network and back to working object. In fact, I originally thought JSON was the data transmission serialization format for JavaScript. It took a while for me to understand that no, JSON is not the serialization format, JSON is THE format. JSON looks like a data structure for key-value pairs because JavaScript objects are a structure for key-value pairs.

Once “every object is a collection of key-value pairs” got through my head, many other JavaScript traits made sense. It was wild to me that I can attach arbitrary properties to a JavaScript function, but once I understood functions to be objects in their own right + objects are key-value pairs = it made sense I could add a property (key) and its value to a function. Weird, but made sense in its own way. Object properties are reduced to a list of key-value pairs, and object methods are special cases where the value is a function object. Deleting an entry from the list of key-value pairs allows deleting properties and methods and accessing them via brackets seem no weirder than accessing a hash table entry. It also made sense why we don’t strictly need a class constructor for objects. Any code (“factory function”) that returns a chunk of JSON has constructed an object. That’s not too weird, but the property value shorthand made me grumpy at JavaScript again. As did destructuring assignment: at first glance I hated it, after reading some examples of how it can be useful, I merely dislike it.

In an attempt to end this on a positive note, I’ll say I look forward to exploring some of the built-in utilities for JavaScript classes. This Codecademy course introduced us to:

• Array methods .push() .pop() .shift() .unshift() .slice() .splice() etc.
• Iterators are not just limited to .forEach(). We have .map() .filter() .reduce() .every() and more.
• And of course stuff on object. Unlike other languages that need an entire feature area for runtime type information, JavaScript’s approach means listing everything on an object is as easy as .keys().

Following this introduction, we can proceed to Intermediate JavaScript.