Show HN: Learn and practice modern JavaScript | Hacker News Reader

Show HN: Learn and practice modern JavaScript

learnjavascript.online

305 pointsjadjoubran105 comments

I wish there was a "learn modern Javascript for people who learned Javascript in 1998" - it seems like the only way to get up to speed is to slog through all the basics (yet again) and keep an eye out for the parts that seem to be unfamiliar/new.

As a fellow old-schooler who's been getting back into JS myself, I've come across a couple of these types of resources that I found particlarly helpful. Here's the links:

- "Modern JavaScript Explained for Dinosaurs," by Peter Jang: https://medium.com/the-node-js-collection/modern-javascript-...

- "Modern JavaScript for Ancient Web Developers," by Gina Trapani: https://postlight.com/trackchanges/modern-javascript-for-anc...

(Don't let the "ancient"/"dinosaur" stuff scare you off -- they kid because they love.)

Hope this helps!

Thanks, that is a big help!

I suggest reading the ExploringJS books [0]. If you already know ES5 then you can jump to Exploring ES6 [1], then you can work your way through Exploring ES2016 and ES2017, and finally Exploring ES2018 and ES2019. Each book explains what new features that were added to the language as part of that specific version. Don't feel daunted though! ES6 added the largest amount of features, and after that there haven't been nearly as many changes. If you find the book useful please consider buying a copy; I'm not associated with the author in any way, just a big fan of his writings.

[0] http://exploringjs.com/

[1] http://exploringjs.com/es6/index.html

I was in the same position a while back, and found Eloquent JavaScript [0] to be a really good read. It's quite well structured, which makes diving into the bits that sound unfamiliar a lot easier.

[0] https://eloquentjavascript.net/

I skimmed this (which looks good) and the Airbnb guide recommended (recommended in another comment) and I can't help noticing that one uses double quotes for strings and the other single quotes (Airbnb).

Is there actually any sensible argument one way or the other - that isn't just being consistent with your team/project/platform...?

For these sorts of style rules we've started using Prettier (https://prettier.io/) to auto-format code for style. We set VS Code to just run it every time you save a file. It's been a huge win for us so developers don't have to spend time on trivial stuff like double vs single quotes and the like. No more having to comment on style inconsistency in PRs, we can focus on actual code quality. And no more arguments about what's the right style rules.

Prettier doesn't resolve my primary issue with excessive linting rules.

The way I see it, there are three kinds of syntax linting rules:

1) Potential bugs. These are where a syntax will technically work, but makes it easy for an unintended bug to creep in. Most everyone agrees that these are bad. (There are a few arguments about what qualifies, but this is nonetheless a less-argued-about category.

2) Purely stylistic. This is where Prettier shines, because everyone wants the "more readable" option - where "readable" means "more familiar". Prettier allows you to write your preferred style, though of course anything you READ will be in the defined style (absent two-way conversion).

3) Expressiveness. This is where you're formatting your code to communicate. While Perl is notorious for this - the advocates love it because well-written code is easy to follow and maintain and the detractors hate it because just because you CAN write clearly in it, the skill to do so is rarely developed and the result is near-gibberish, even from skilled coders - like a story that has every sentence written by a different person. Java is the reverse - the advocates love it because the code tends to be very uniform and the detractors hate it because it's universally verbose and unclear.

That last category is why I'm leery of excessive linting. If I'm dealing with code that changes hands often, a Java style makes sense - newspapers written for a low but common reading level, even if the reader is capable of much more nuance. In this scenario nuance would risk being ignored, or worse, being mis-applied, which means the result would be misleading. If I'm dealing with code that is owned by a team that has routine staffing changes but no complete upsets, nuance has a real benefit - reading code is faster and more accurate/informative, with the result of fewer bugs (citation needed).

But saying "It's okay to use Prettier and stop arguing about linting" dismisses the nuanced case. It carries the assumption that linting rules - any rules - are automatically valuable regardless of the choices made, and if you don't like it than write what you like and just use Prettier.

Linting rules (and linting arguments) exist for a reason - these are LANGUAGES that we are using to communicate - and as much as I'm tired of the arguments too, until we honestly figure out how to communicate well, ignoring the arguments doesn't help.

I agree that nuance and discussion about style is incredibly important because, as you aptly point out, we're writing in a language used for communication. That being said, since we've introduced Prettier, I haven't encountered any changes it's made to code that are anything more than trivial formatting/purely-stylistic changes.

I think readability and expressiveness are more about larger scale patterns in code writing (writing self-documenting code with descriptive variable and function names, writing modular code, etc). These are things that should be continuously discussed and improved upon for clarity and alignment. The really granular formatting changes that Prettier chiefly concerns itself with don't seem to be a concern in this case. If you could point me at a more specific case where you think Prettier mucks things up I'd love to see more of what you're talking about.

I could be misunderstanding (I've not yet used Prettier), but I thought Prettier was agnostic to the linting rules used. I was arguing not that Prettier is bad, but the _excessive_ linting rules were bad (Prettier should be fine for reducing arguments over trivial rules that neither impact bugs nor expressiveness), and further, that arguing that excessive linting wasn't a problem because Prettier can let you ignore them is likewise bad.

None of which says that Prettier itself is bad, but that excessive linting rules, with or without Prettier, are bad.

If I'm wrong about what Prettier does, please let me know. If you're discussing a default set of linting rules Prettier uses, cool, but I can't really say if I think they impact expressiveness since I'm not familiar with that set of rules.

I think you are misunderstanding what Prettier does - Prettier is more in line with gofmt as it is a formatter not a linter. Prettier parses the JS code into an abstract syntax tree and then outputs that AST back into code using a defined set of rules, so you end up with one unified style. Prettier intentionally doesn't give you many configuration options for this style, with the goal of eliminating the discussion about which style to use.

If you are using Prettier, you can use the Prettier config with eslint or tslint, which fully disables the style rules for those two linters and lets them focus solely on linting for errors and structural issues.

Ah, I thought it consumed the style rules and rewrote to them, so you could pick your preferred styles and have everyone submit code that met them even if they didn't write in that way. Which sounds mostly correct, except for the "pick" part.

That whole issue is arguably old JavaScript. It was because HTML style preferred double quotes so using since quotes in JS made that easier.

Modern Javascript has template literals using backticks so arguably the new rule should be used double quote everywhere except use a template literals for HTML or whenever doing string manipulation.

The number one thing I hate about using single quotes it is matches almost no other languages so it ruins muscle memory if switching between languages.

JS itself prefers double quotes. See JSON.stringify or log anything to the console that gets auto quoted, always uses double quotes

The fact that JSON.stringify uses double quotes is slightly in favour of using single quotes in handwritten code

It matches SQL, that is the one language one is most likely to write at the same time as any other language.

The reason I’ve used (and stuck to) single over double is it’s easier to embed JavaScript within html (html convention being double).

It can get cluttered when with nested quotes, but most linters will allow you to use the other type to encapsulate.

IMO it doesn’t matter, as long as the team agrees and remains consistent throughout the codebase.

Thanks - that's a decent explanation for favouring one over the other.

I rather dislike "best practices" that don't provide any explanation of what they are recommending.

I mean, it's because it doesn't matter. Picking one is valuable for consistency (no odd diffs when refactoring). Which one you pick doesn't matter.

The behavior is slightly different. "\n" is a newline, '\n' is a backslash and an n.

Not in JavaScript. \n is treated as a newline in both cases. Try it out in the console.

... Unless you would prefer to skip the extra keypress required for ".

The sane argument is about avoiding escaping of nested quote characters.

It's easier to use double quotes if your text is english (or other language that uses apostrophes).

It's easier to use single quotes if your text is HTML (for double quotes)

I've seen an argument to use template literals (backticks) almost everywhere. I don't know if that involves any real performance hit, but I've also not adopted this convention, at least not yet.

Template literals also have the benefit of being able to embed variables without concating the string, ie: `My name is ${name}.`

An argument for " is you don't have to escape ' inside string's. In an argument about single vs double quote you can bring up `Template strings` and everyone will hate you ;)

For a slightly different reason than many I've seen here - double-quotes require the shift key to be depressed on standard keyboards. So programming with double-quotes doubles the number of keystrokes you need to type any time you quote something. Pretty sure the person that told me that was a Vim fanatic as well.

Not saying that it's a strong reason to use one over the other, but it is an objective reason that doesn't rely on style or preference.

I agree w/ other commenters that using a formatter like Prettier is a good idea. But to answer your question, single quotes don't require use of the Shift key so are a better choice for DX / ergonomics. RSIs are no joke.

I don’t ever want to work with someone who insists on one style of quote marks in a language where it doesn’t make any difference.

There’s a difference between promoting readable code and just being retentive.

Like most lint rules, it's mostly preference. The important part is being consistent within your team/project like you said.

(Wrote practically the same message at the same time, then deleted mine. Agreeing with the parent comment: Eloquent Javascript is really solid.)

Here is a language diff that shows when new language features added to Firefox. This might be helpful to get an exhaustive list of the changes: https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...

In practice the only thing you absolutely need to know is the spread syntax for arrays `blist=[...alist]` and objects `objb={...obja}` that will trick you up if you're never seen in before

   alist = [1,2,3]
   blist = [...alist, 4]   // == [ 1, 2, 3, 4 ]

   obj =  { a: 5, b: 6 }
   obj2 = { ...obj, c:7 }  // == { a: 5, b: 6, c: 7 }

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

There is also this weird shortcut for creating objects for which key and value use the same identifier:

   d=8
   e=9
   obj = { d, e }   // shorthand for {d:d, e:e}
   // == { d: 8, e: 9 }

I wouldn't say that latter thing is a "weird shortcut" - C# has had that for a while and I rather like it. :-)

I would read through AirBnB's JS style guide. Very well structured, and most rules have reasons specified in the guide. It should cover all the unfamiliar parts for you. After that, the next biggest thing is tooling so it'd be picking a framework and seeing how the development process has changed with npm & webpack. Start with Vue, Angular, or React and go through their hello world examples. Not that you need to be a "framework developer", but they are probably the best spots to see how the development process has changed.

https://github.com/airbnb/javascript

There is a yt video that I found very well done and explained very well. He goes very deep in the inner workings of javascript.

I think you will like it. It is "modern" but not a new video. It is probably about 3 years old. Still relevant. He has a udemy course for $10 bucks.

https://www.youtube.com/watch?v=Bv_5Zv5c-Ts

I'm sure a lot of people are in this same boat. It used to be that I was afraid to use any new JS features for many, many years due to the fact that so many people were using old browsers. Today, browsers update automatically, and the only outlier is the 5% of people still using Internet Explorer. So, recently I've changed my attitude to accept anything in ES8 (or at least async/await).

The problem now is that different sources of info will still use older methods. E.g. Promises were used to augment/replace the use of callbacks in many situations. And now async/await is augmenting and replacing promises in a lot of places. So you'll still run into a lot of sources saying promises are the new and better way to do some things, when async/await is actually a better choice.

I still code JS like it's 1999 :P Most new updates are syntax sugar. ES5 added a ton of stuff that are useful, for example binary buffers which is useful for optimization. When people say "modern" JS though, they mean the syntax sugar from ES6 and ES7. I actually prefer the "old school" style. I hate how the language has become more complex, but I guess it's an evil necessary in order to please everyone. If you for example are into functional programming you will love arrow functions. If you never liked async or functional programming you will like async/await. If you like meta programming you can use new tools like Babel to come up with your own syntax sugar. The tooling and ecosystem for JS has really exploded. If you haven't already, take a look at Node.JS.

While I agree some of that sugar does a lot to clean up a lot of boilerplate code that we used to have to write, such as arrow functions retaining this in scope without having to do binds or "self = this" stuff we used to have to do. as well as adding let which allows you to properly scope variables. It is sugar and the language was perfectly usable without them but they sure do tidy up the code we write.

For me, it's not really so much the JS syntax - I agree it's mostly syntactic sugar and if I really want to use something like, say, "map", I can always do something like:

    Array.prototype.map = Array.prototype.map || function(f) { var a = []; for (var i = 0; i < this.length; i++) {a[i] = f(this[i]);} return a;}

What I'm still trying to get my head around is this whole new ecosystem of bower, webpack, babel, eslint, npm, node, grunt, jQuery, angular, react, vue, yarn, parcel, browserify, gulp, etc... and apparently Javascript has modules now?

Around year 2000 "AJAX" started to get popular which allows you to make HTTP requests from JavaScript (JS). "AJAX" makes it possible to have upload progress bars, or have "new messages" badges without reloading the page. "AJAX" made it possible to move back-end code into front-end JavaScript. To make the transition easier, front-end JavaScript frameworks was invented. AJAX was initially implemented differently between browsers, and jQuery became popular, as it added abstractions that work on all major browsers.

In 2011 Websockets was made into a standard, which set the new direction on how you create web apps. Instead of having a back-end in Perl, PHP, CGI, etc, which renders the HTML on the server, the DOM is now rendered on the client, and the client communicate to the server via REST/HTTP or Websockets. This accelerated the growth of front-end frameworks as more and more started to port their back-end rendering to the front-end.

In 2008 Google's Chrome browser was released which had a very fast JS engine called v8. And about that time a mathematician named Ryan thought that in order to have a performant web server, it need to be async ... While JS on the server was already a thing, it was not async. Ryan took the v8 JS engine from Chrome. and made a fully async library/API for IO on the server. He called it Node.JS. And it become popular. The "CommonJS" module system became the standard module system in Node.JS. NPM was created to host modules/packages. Webpack makes it possible to convert Node.js modules to run in the browser. Grunt was picked as the "make" system for Node.JS modules, and I think Gulp is a competitor to Grunt. Bower and Yarn sprung up as competitors to NPM.

Then in 2015 the EcmaScript (ES) committee standardized JS modules, but incompatible with Node.JS module system, missing features such as lexical scoping, dynamic import and lazy loading available in the NodeJS module system. As a result Node.JS has still not implemented ES modules. But you can use Babel to transpile the code.

Personally I try to avoid transpilation and front-end framworks, and only use vanilla JS. Node.JS is a really good back-end JS framework. There's a module for everything you need. And all of them are free and open source!

https://es6cheatsheet.com aims to do exactly that. Old code on the left, modern alternative on the right.

I didn’t go quite as far back as 1998, but if you kinda know ES5 and older it’s just the right fit.

... or use Babel, learn to write in es6+, and read the es5 output.

Babel’s output is really really not meant for human consumption.

I find this MDN JS guide very helpful. Quickly scan the chapters/sections and pick ones you are not familiar with.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

How about this?

"Learn modern JavaScript, for people who learned JavaScript in 1998"

https://sephware.com/blog/2019-01-03-learn-modern-javascript...

LOL, well that's perfect, thank you.

Search for guides that specifically call out ES6 and above.

Got you fam. Just posted one.

I wanted to test this out but it appears the only way to do so is by signing in with GitHub. That won't necessarily deter me, but I imagine that will be the case for others.

If I were you, I would allow access to the course without signing in. Then, if the user wants to save their progress, they can connect their GH account.

Thanks for the feedback! I had that during the testing period but it was a bit confusing. You've also got flashcards linked to your progress which also requires an account. I'm also avoiding adding a 2nd method of sign in in order not to confuse returning visitors: "Which account did I use? "

Just so you know: I'm one of those guys who won't sign up until I know what I'm getting.

From the animated gifs it looks like you're just presenting an Anki deck online. Why not just share what you have to share as an Anki deck?

Yes, that would be nice. Anyone know of other good Anki decks for modern JS?

People have a preferred login method. If you gave me and combination of Google, Facebook, and GitHub, I know which I would use (and it depends on the service).

I don't use accounts with any of those companies, and I certainly wouldn't start just for a JS tutorial.

Why not just save progress as a cookie? (Why do websites have to have centralised corporate surveillance?)

A cookie wouldn’t let you continue from another computer (or browser) where you left off. If it stores scores from different “levels” or any significant amount of data local storage would be better than a cookie. Still, that wouldn’t let you continue where you left off on another machine/browser.

Which as a user just taking a quick look at it I don't need or want, and the audience for this isn't going to have difficulties with the concept that they'd need to log in to get that.

Yes, or local storage — they're essentially the same as cookies in terms of UX.

I don't want to continue where I left off on another machine — right now I just want to see the thing in the first place.

If you expect people to sign in before they can see your content, presumably you expect they already know that they want your content — enough to overcome the hurdle of giving access to the 3rd-party account that you assume they already have or are willing to create.

Progressive enhancement!

or local storage in the browser

Do actual users actually get confused? A password manager will easily deal with a new random @mailinator.com address and password, and that's much easier than creating yet another throwaway Github account.

especially since having multiple github accounts is a violation of github policy.

Really? That seems surprising and bad. Many people might want to have separate work and personal accounts.

I haven't heard of Github actually enforcing this, but the described limit is one free account per person. If you need a separate work account, you (or your employer) are supposed to pay for that.

they do enforce it. it's more a matter of their scanner detecting that two accounts belong to the same person. my account was locked until i removed the duplicate accounts i had. fortunately my extra accounts were no longer needed anyways, so i had no problem with that and got reinstated quickly.

i also had a lengthy constructive exchange with the person handling the case about the downside of this policy and why one might legitimately want multiple github accounts.

the response i got suggested that if someone could bring a legitimate case why they needed multiple unpaid accounts, then they would be willing to make an exception. which means, at least they are willing to listen to reason.

personally, i think that if you use github for work, then it's a fair argument to say that that should be a paid account.

In the struggle the Donkey fell over the bridge, and his fore-feet being tied together he was drowned. “That will teach you,” said an old man who had followed them: “PLEASE ALL, AND YOU WILL PLEASE NONE.” https://www.bartleby.com/17/1/62.html

This just goes to show that if someone publishes any learning resource, people will shower the author with praise regardless of the quality, or even trying the resource out.

We do not need yet another JavaScript learning resource, we have good ones. Mozilla Developer Network is the best one, but there's also Free Code Camp, Eloquent JavaScript and javascript.info among many others. Don't write a resource for the sake of doing so unless you can bring something new to the table.

This is totally scummy. There's no way I can see to go to the upgrade page. Instead, it forces you to complete the lessons up to it before asking you to pay $25 for continued access. So it requires time investment first. Doesn't tell you the price first either.

Asking for $25 just to learn about arrays is purely abysmal. This "course" also doesn't even seem to go over exceptions, but I can't know that for sure because I'm not paying $25 to see the expanded table of contents. Also don't like that you're charging $25 before I can even learn about the DOM because half of this is incomplete.

I like that this teaches you not to use the var keyword! Pleasant to see that for once. That's the best thing I have to say about this.

Can't skip any lessons at all, even to browse.

Back button does not do what it should on some pages. Hitting "Next" should not refresh the page if I cannot go to the next page. I was somehow able to trigger a bug where I didn't complete two challenges and it marked them as completed.

Automatically sending me emails when I don't use your application for three days without asking me first, I have to figure out it's what a mail icon in the menu toggles. Awesome UX.

Nice that I can't send a message to support without letting Drift send me emails about upcoming promotions.

Edit: The purchase page tells me $25, but the payment prompt says 25 euro. Seems awfully like trying to mislead customers purposefully to pay more. Easy to miss.

In the land of the blind, the one eyed man is king.

Throw The Emperor's New Clothes, Impostor Syndrome, and Late Stage Capitalism mentalities into the mix and it's little surprise that these things play out the way they do every single time.

Cool app! Well done.

I would maybe reconsider using Fira Code, or add a font preference option. It's an awesome font but this app is clearly for beginners, and having >=, === and the like turn into ligatures might be a bit confusing.

Thanks! During user testing, most beginners loved the Fira Code, and advanced developers complained about Ligatures! But it's quite easy to enable/disable

I have a student right now that has dyslexia and the ligatures help a lot. I'm glad this tool has it built-in! my student loves this already. Thanks mate!

That made me so happy! Please email me (you can find my email in the footer of the website), I'd like to give a paid account for free for your student. Cheers!

It's neat, but if a person is learning I think it's good to have that little extra verbosity. A new user may even get confused because its editor doesn't convert symbols.

Not sure why I thought this was going to be free, but for whatever reason I was surprised to see the prompt for payment after finishing the trial.

Woops, sorry about that. I'll make sure it's clearer. There's no mention that it's Free anywhere however around 35% of the course is free. It shows which content is free and which one is paid in the sidebar, but it could be that you haven't checked it out

There is also no point on the front page that it is paid, and I would assume that because there is no mention of pricing that it would be free. I'd definitely put something very early on stating pricing and that it is not a free program. To tell someone 35% through a lesson that they are expected to pay may be fine for conversion, it's a really scummy practice.

I know this may be a minority opinion among developers, but I'm ok with them trying to make money. And if the optimal way to do that is to ask 35% of the way through, then that's what they should do. I don't view that as a dark practice or bait and switch. I don't think there is an obligation to be super clear that there is a paid version.

It's something the owner should test, and see if it puts people off or if it converts better. Maybe it puts off 10% more people, but 30% more convert? Good on them for finding that out and optimizing accordingly.

We in the dev world expect way too much for free. Not that I complain when I find something for free, but people deserve to be compensated for their work also.

I never argued the effectiveness of misleading business practices towards generating revenue or conversions. I feel that design can be misleading and user-antagonistic while still being the most effective solution for monetization. It is up to the creator/organization to make that decision, and that decision can be both financially effective and amoral/"scummy" at the same time. I cannot make that decision for the creator/organization, but I also feel no need to default to defending user-antagonistic practices just because "they work".

Sounds like publicfig is saying that it's not optimal for them.

Frankly it kinda angers me a bit, because I would not have signed in with my github account if I had known it was just a trial.

I'd say to test what makes the most sense and works best financially for you. Test your conversions and optimize for better conversions over what a handful of people online say they like or don't like. Particularly when their opinion could cost you $$.

Why does the site need to have my github private email address? I use different email addresses for different sites. I don't want learningjavascript.online to have my github email address (or any email address, but that's doable).

I'd try out the site, but this is a show-stopper for me.

It needs your address so it can send you an email if you decide not to use the application for three days, and this is turned on automatically.

1. I don't want spam from the site. 2. I definitely don't want to use my github email address on this site so that future spam from them or the people who hack them looks like it came to my github address.

Hi OP, this looks great, first of all. Very nicely polished! On the other hand, I find the most difficult thing about frontend isn't necessarily the syntax, but the build tools - webpack, babel, etc. Is there any course material on that?

Thanks! No, not at the moment

Very nice! This seems like a better way to learn or refresh on the language that just wading through tutorials/textbooks.

One thing that is missing is a way to report problems in the exercises. Already in the Conditions section I found an exercise that says:

"Implement a function canVote that returns true whenever the age is bigger than 18"

But the test is for a function that returns true when age is greater than or equal to 18.

Thanks will fix! You could report those issues with the "?" icon on the lower right

I reported this before I saw this comment. Should have known someone would mention it here too! :)

Opened page and saw the animation

function nameLength(name){ return name.length }

Rather than

const nameLength = (name) => name.length

This is already enough for me not to bother looking.

const length = (string) => (string.length)

It is unnecessary to adopt a naming convention which implies a scope within the context of "names" when the method is compatible with all strings.

It was more about the lack of es6 syntax but yes 100% agree

ES6 is explained in detail, with implicit return in Chapter 5 (or 6). Developers still need to know the function syntax for when they look up documentation online Cheers!

Which is a completely useless function anyway

Maybe, depends on what you're doing.

Going full functional style could possibly be used.

You could change it to pointfree using Ramda and just write:

  const length = prop('length')

why not just name.length

I know JS has had a rough last few years and we have sayings like framework du jour, etc... but... haven't things actually started slowing down?

Has JS had a rough few years? There's been big advances like React and TypeScript. ES6 was a big improvement. JavaScript finally has lexical scoping. It's better than ever.

The frameworks exist for a reason, as much as it's popular to diss them. Stuff like jQuery has fallen out of use because it's not considered useful anymore.

Progress is important, faster progress is good. Changing stuff for the sake of doing so is bad, of course.

Is there a way to remove an account?

getting 500

Hey! It's probably because there's no confirmed primary email in the Github account

Modern JavaScript in practical for today should be just written in TypeScript with Strict mode turned on.

Assumptions like that can be done endlessly and you will never get 100% satisfaction but vanilla JS is the title and the main target here IMO. You do not start learning JS by doing some heavy dutty React+Redux stuff. Same goes here, it's a "get basics" lesson.

I agree that everyone should use Typescript but knowing what Typescript adds to Javascript doesn't help you with anything. You have to know Javascript first; because that's what the bulk of your code is. Typescript merely adds some annotations and all of its syntax strictly deals with types.

Your statement kind of sounds like "don't learn C, learn how to run gcc from the command line". Important but orthogonal.

I think people miss the point that it is just a compilation check, but the runtime is still completely dynamic. If you are writing typescript that interacts with anything else in the world the types make no guarantees at runtime so it is important to know how Vanilla JS would behave in that circumstance.

I might have plans to add a TypeScript chapter towards the end

Nope, it doesn't

No because then you'd be writing TypeScript which is not Javascript anymore than CoffeeScript is.

Reply on news.ycombinator.com