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↩

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↩

2This is a gross oversimplification. If you’ve read some traditional literature about static vs dynamic programming languages you’ll be familiar with the idea that static programming languages like C++, Java, C# are compiled and then executed whereas dynamic programming languages like Ruby, Python or JavaScript are not compiled but interpreted on-the-fly as they are executed. The repercussions of this being that a compiled program cannot be changed at runtime (you would need to recompile it), whereas an interpreted one can, since nothing is set in stone until it is run. In today’s world however, JavaScript runtimes like V8 (Chrome) or SpiderMonkey (Mozilla) compile JavaScript to machine code, optimize it, and re-optimize it based on heuristics on how the code is executed.↩

3For those of you not familiar with magic, mana can be seen as a measure of magical stamina. As such, doing magic (like summoning minions) spends one’s mana. An empty reservoir of mana means no spellcasting just as a empty reserve of stamina means no more running.↩

4As an article of interest you can augment objects in C# if you use the dynamic keyword with ExpandoObjects↩

5One does not simply change the prototype of an object willy-nilly at runtime since it can affect performance a lot. Instead, you would use Object.create or a function constructor, and if needed, you would augment the prototype as needed.↩

6like a hobbit but with shoes. If curious look up the joyful, corageous and beloved Tasslehoff Burrfoot.↩

7in reality, it does not need to be an array, but an iterable that produces key/value pairs [<key>:<value>]↩

8for the sake of correctness, you can use the for/of loop not only on arrays, maps and sets but on anything that implements the iterable protocol. We will discuss iterability later within the series.↩

9An interesting thing to think about is that Array.from can be easily polyfilled while the rest syntax requires transpilation. If you, for some reason, cannot or don’t want to add the transpilation step to your project then you can still use Array.from by adding a polyfill or a shim. Which is a very painless alternative.↩

10Open for extension and closed for modification. http://bit.ly/ocp-wikipedia↩

11As long as it is not frozen via Object.freeze, which makes an object immutable to all effects and purposes.↩

12I say mostly because if you have a this keyword within a method and within a callback function (which I dare say is pretty common) then you are screwed. But worry not! You’ll learn everything there is to learn about this in the next chapter.↩

13or the new operator that we’ll see when we get to glorious tome of OOP ↩

14that’s from the one and only JavaScript specification ECMA-262 (http://bit.ly/es6-spec-symbols)↩

15AJAX stands for Asynchronously JavaScript and XML and is a technology that allows you to get data from a server even after a web page has already been loaded. The significance and impact of AJAX in modern web development is huge because not only does it let you create highly interactive websites but also deliver a website in chunks as they are needed. Since its inception, browsers have implemented support for AJAX via the XMLHttpRequest object. Because of its complexity, I decided to use the simpler $.getJSON. In the near future, you’ll be able to do AJAX requests using the improved fetch API. Yey!↩

16You can find more information about the Window object and the DOM at MDN (http://bit.ly/mdn-window-object)↩

17Another cool use of bind is partial application, but we’ll take a look at that when we get to the tome of functional programming.↩

18In this particular case however, because we are using jQuery to perform an AJAX request, the value of this is jQuery jqXHR object, an object that represents the AJAX request itself (we can assume that jQuery calls the updateUsers callback in the context of a jqXHR object).↩

19Check this awesome jsJabber chapter to learn more about the origins of JavaScript from the very illustrious Brendan Eich http://bit.ly/js-origin.↩

20Template literals are also known as String Templates↩

21The next step would be to create two methods first and last that would encapsulate these two implementation and extend the Array.prototype object. Soon we will take a look at that within the OOP section of the book.↩

22Find out more about arrow functions within the spec at http://bit.ly/es6-spec↩

23The DOM or Document Object Model is an object representation of a website where each HTML element is represented by an object called a node.↩

Tome I.II JavaScriptmancy and Data Structures

1The for/in loop let’s you iterate over all the enumerable properties of an object. Later in this section of the book you’ll learn more about the concept of enumerability and how it differs to the concept of iterability introduced in ES6.↩

2See bit.ly/javascriptmancy-is-this-an-array for more info on why instanceof is not a safe way to determine that an object is an array.↩

Tome I.III JavaScriptmancy and OOP: The Path of The Summoner (preview)

1In Fantasy, Wizards of all sorts and kinds summon or call forth creatures to act as servants or warriors and follow the wizard 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 about OOP.↩

3The 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 the steals method you are violating this principle because the derived class breaks the expectations established by the base class (i.e. that you should be able to use both methods).↩