Ask HN: How do I learn JavaScript?

You can think of a prototype as 'cloning' an object (but not quite), distinct from classes in OOP, which are typically created afresh, i.e. no entanglement occurs between instance 1 and 2 of the same class (unless of course explicitly specified in a constructor). If I have `var a = {one: 1, two: 2}`, I can use that as a 'live template' to stamp out other 'instances' that prototypically inherit from that ancestor. Any attribute lookups that are not specified directly on an object created with a prototype recursively look up the prototype ancestry chain until it is found. So if c -> b -> a (where a -> b means a prototypically inherits from b), looking up a property on c will try to look for the property on c first, failing that b, then a. If nothing is found, `undefined` is returned.

Let's open our inspector and have a play: ``` var a = {one: 1, two: 2}; var b = Object.create(a); // create b, based on prototype a var c = Object.create(b);

console.log(c.one) // 1, how, when this wasn't even defined! We looked up the p. chain until we found it

b.three = 3;

console.log(a.three) // undefined, a's only prototype is Object console.log(c.three) // 3, wow, c knew about something that happened to b! This is different from OOP. 'instances' share data defined at runtime.

```

Why promises? Before promises, js code often used an error first callback strategy to communicate when an asynchronous process has finished. It's important to write blocking code as little as possible, since your computer can and should spend time doing 'compute' stuff, whilst waiting for a resource, such as a network request or disk etc.. which can take an unbounded amount of time.

Back to how callbacks look: ``` function myExpensiveSuccessfulFn(cbFn) { setTimeout(() => { cbFn(null, 'success'); // pretend we did something useful }, 60 * 1000) // time waste for a minute }

function myExpensiveFailingFn(cbFn) { setTimeout(() => { cbFn('oh no'); // pretend we tried to do something useful }, 60 * 1000) // time waste for a minute }

function myCallback(err, data) { console.log(`err: ${err}`); console.log(`data: ${data}`); }

myExpensiveSuccessfulFn(myCallback); // after 1 minute: err: null, data: 'success'

myExpensiveFailingFn(myCallback); // after 1 minute: err: 'oh no', data: undefined ```

Awesome. We can wait for some result and be notified whenever it finishes. Have a play in your inspector as before. Immediately after calling our expensive functions, we can execute code straightaway (try logging anything immediately after calling an expensive function)

Now callbacks start to get unwieldy when those same callbacks also want to do things that require something else asynchronously. There are better examples online, but I'll write something with anonymous functions to give you an idea:

``` function addSomethingSoon(a, b, cbFn) { // in 5 seconds, return the sum of two numbers setTimeout(() => { cbFn(a + b)// no err first style in this example }, 5 * 1000); }

// now let's get the sum of four numbers:

addSomethingSoon(1, 2, (result1) => { addSomethingSoon(result1, 3, (result2) => { addSomethingSoon(result2, 4, (finalResult) => { console.log(`1+2+3+4=${finalResult}`); }); }); }); ```

Only 3 operations, and things are getting quite ugly. Contrived, but let's see how we can do better.

Enter the promise. A promise is a 'promise' of a future result. It's like if you went to a fast food restaurant, made an order and got a ticket in return. Once you are given a ticket, they'll call out your number and give you your food, since you are holding the ticket (the promise of food in the future).

Let's have a play:

``` function getFoodIn5(menuItem) { // don't worry about the syntax here. You'll likely not be creating promises with 'new' often. You'll likely get given them from a library, say a http call or similar. return new Promise((onComplete) => { setTimeout(() => { onComplete(`fresh ${menuItem}`); }, 5 * 1000) }); }

const promiseOfFood = getFoodIn5('burger'); console.log(promiseOfFood) // depends on your browser, nothing very useful, and definitely NOT our burger....

promiseOfFood.then((food) => { console.log(food); // fresh burger, yes, it tastes so good! }); ```

So we got our burger, pretty fast too. Unfortunately they just hired a few trainees:

``` function burntFoodIn5(menuItem) { // don't worry about the syntax here. You'll likely not be creating promises with 'new' often. You'll likely get given them from a library, say a http call or similar. return new Promise((onComplete, onError) => { setTimeout(() => { onError(`burnt ${menuItem}`); }, 5 * 1000) }); }

const promiseOfFood = burntFoodIn5('burger'); console.log(promiseOfFood);

promiseOfFood.then((food) => { console.log(food); // ... :( nothing }).catch((mistake) => { console.log(mistake) // burnt burger, you don't want to eat this. }); ```

that is promises in a nutshell...

If Fabrice Bellard can do it, in C, with no dependencies, you can do it in whatever language you're already comfortable with, using the standard library. It's simply a matter of sustained effort and focus over time.

Sneak ClojureScript in. I know of one shop that trained its JavaScript engineers to use ClojureScript in two weeks. Quite frankly, if one is smart enough to write actual good, safe JavaScript, then one can definitely grok ClojureScript.

So as a Java developer ClojureScript keeps me a little in a familiar realm instead of jumping to a whole new ecosystem where I have to pick up every new aspect in the tool chain, including the language.

But this is personal, and I have absolutely no experience in these other languages you mention and they may be awesome.

ClojureScript and Reason are superior languages, period. They will live long happy lives, too.

There is no relief in sight and it'll suck for a long time because everything is very fluid everywhere. Legacy will suck.

But if you want to be as productive and confident as you can these days; my take it is to not engange in vanilla JavaScript.