1“Any sufficiently advanced technology is indistinguishable from magic.” Arthur C. Clarke. Love that quote :)↩

2The ECMAScript standard in which JavaScript is based is evolved by the TC39 (Technical Committee 39) composed of several companies with strong interest in JavaScript (all major browser vendors) and distinguished members of the community. You can take a look at their GitHub page for a sneak-peek into how they work and what they are working in↩

3Previously known as Angular 2 and later re-branded to just Angular. The former version of Angular 1.x is now known as Angular.js↩

4Really, A LOT :)↩

Tome I. Mastering the Arcane Art of JavaScript-mancy

1For those of you that are not fantasy nerds I have included a small glossary at the end of the book where you can check words that you find strange. You should be able to understand the book and examples without the glossary, but I think it’ll be more fun if you do↩

Tome II. JavaScriptmancy and OOP: The Path of The Summoner

1In Fantasy, wizards of all sorts and kinds summon or call forth creatures to act as servants, or warriors, and follow the wizard’s commands. As a JavaScript-mancer you’ll be able to use Object Oriented Programming to summon your own objects into reality and do with them as you please.↩

2In this section I am going to make a lot of generalizations and simplifications in order to give a simple and clear introduction to OOP in JavaScript. I’ll dive into each concept in greater detail and with an appropriate level of correctness in the rest of the chapters ahead.↩

3They are also safer to use: They aren’t hoisted and JavaScript will alert you if you try to call a class constructor without the new operator.↩

4The Liskov substitution principle is one of the S.O.L.I.D. principles of object-oriented design. It states that derived classes must be substitutable for their base classes. This means that a derived class should behave as portrayed by its base class and not break the expectations created by its interface. In this particular example if you have a castsSpell and a steals method in the base class, and a derived class throws an exception when you call them you are violating this principle. That’s because the derived class breaks the expectations established by the base class (i.e. that you should be able to use both methods).↩