I’ve been doing a series of JavaScript videos on YouTube as part of a larger effort teaching Software Development. I find that I create a video 2 to 4 times before actually recording the real one. When describing something, when I find I have to reference a basic concept, I instead stop, and record a video around that basic concept first. This has worked well, and similar to blogging/writing books, it forces you to plug all holes no matter how minute in your knowledge of a subject so you can succinctly describe it in a way that makes sense.
From a programming perspective, teaching advanced JavaScript is quite challenging because it wasn’t designed for traditional OOP concepts and large application design. Many of the more popular languages today are either built on, or support and promote OOP usage. On the same token, once you know OOP you better appreciate Functional languages, parametric polymorphism, and other dynamic language features.
However, I don’t believe you can effectively teach OOP in JavaScript as it stands today, mainly because JavaScript doesn’t have a de-facto way to approach OOP. You have Douglas Crockford of JSON/JavaScript The Good Parts/etc fame promoting closures, various others promoting through their actions of having x-compile languages exporting to and/or optimizing the Object.prototype way, and still others keeping with the compromise of sticking to Functional roots via Object.create. Of those, you have a variety of implementation standards.
The more I read, the more you can see implementations based on preconceptions from other languages that the developer(s) have experience with, not ECMAScript suggested (with the exclusion of TypeScript). However, teaching cross compiler/transpiler ways of doing OOP for JavaScript defeats the purpose because anyone who has experience with prototype based languages, or even just dynamic ones, recognizes the broad flexibility they provide to communities and learning potential of those who deploy them since developers effectively “create their API” from extending existing prototypes.
Case in point, a n00b can use Promises without knowing what promises are in 3 lines of jQuery to make his/her site “work” as can an Enterprise dev, whether coding by hand, cross compiling (Gmail, Oracle ADF, .NET, etc), or both scale hundreds of thousands of lines of code. Both can extend the language via Object.prototype modifications for both back porting or simple utilities, and those who write libraries differently can, with knowledge of JavaScript scope, relatively easily borrow those for their style of coding assuming the algorithms are contained within JavaScript vs. CSS.
Additionally, you CAN market to the n00bs, the Functional crowd, and the traditional OOP developers simultaneously.
So skipping JavaScript to teach CoffeeScript or Java GWT instead of teaching JavaScript defeats the purpose, and cheats the student of that value.
Instead, it helps to be pragmatic, and explain what’s really happening: There is enough business demand for traditional OOP developers to get the features they desperately need in a standardized fashion, whether syntactic sugar or true implementation. This means asynchronous modules and OOP syntax. Harmony, of which much already supported, and ECMA 6’s better class support, shows that the OOP developers have made their case, and that the Functional crowd has made theirs as well: both can co-exist.
Thus, it seems more prudent to teach the vision of JavaScript OOP that is real, and actually coming vs. teach a like-minded OOP language and apply those concepts to JavaScript with it’s various incarnations. That and it’s more relevant to their present AND future.
If you teach the architected future, you can easily dissect various strategies employed currently to use that future today.
I wish I had done that with ActionScript 1.0. I learned OOP after the fact and was basically taught for reasons both valid and invalid that dynamic Functional languages don’t really help you build software and I think that was a shame. I hope to remedy that in a future set of videos to help prevent developers going through what I went through.