[0] - https://github.com/getify/You-Dont-Know-JS

[1] - https://www.ecma-international.org/publications/standards/Ec...

I don’t think you can master a language in one go. It’s not how most people’s brains work. I think you do it in stages. Get yourself a good introductory JS resource. The eloquent javascript book others posted looks good although I haven’t read it myself. Then read You Don’t Know JS. And then study the spec. Almost by definition the spec is the only thing that can give you a perfect and complete understanding the language. But don’t start there as a complete beginner is not its intended audience.

Be sure to apply what you learn from each book by working on projects. Don’t just read the books. The material won’t stick that way.

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.

But looking into the details of how object prototypes and properties really work is essential for getting a good grasp of the language.

At some point, that knowledge can then be applied by learning more advanced language features such as implementing Proxies, Generators, and template literal functions.

To do so, some here are suggesting you read the language spec. I think Rau schmaer's series "Exploring ES6" [0] (and then ES7/8/9) is a great alternative to the actual spec. In those books he basically goes through the new features of each version of the language and does the deepest dive I've seen, with examples and references to the spec.

[0] - https://exploringjs.com/es6.html

I do believe you need to have worked in JS for a while before jumping into YDKJS though. Having hit some of the idiosyncrasies of the language in the real world makes the book a much richer learning experience.

The author, Kyle Simpson, has some really good video courses available online as well. He goes further in depth about some of the more interesting topics in YDKJS and is really able to sell some of his patterns.

Again, Kyle’s material was better digested after some practical experience with the language.

Understand exactly how JavaScript gets converted under the hood. Remember, ECMA could be implemented in any language not just C/C++. What you're looking for is algorithmic understanding.

For example, here's the snippet that explains how "new" works in JavaScript https://www.ecma-international.org/ecma-262/5.1/#sec-15.2.2..... Going through the algorithm, your first thought may be "wtf is [[Prototype]]"? Dig into it. Understand when, where, and how [[proto]] and __proto__ get assigned. Learn about the cyclic references that allow everything to be an object including functions.

Of course, feel free to use external resources to assist you while reading ECMA since it is quite dry. For the example above, this amazing Stack Overflow post can help you visualize the algorithm: https://stackoverflow.com/questions/650764/how-does-proto-di...

You'll quickly be forced to ask yourself what you want to accomplish with the knowledge you've gained and from there you will have to set yourself another course of learning the relevant APIs, frameworks, libraries, and tooling associated with that field.

The fastest way to learn a language is to use it constantly, so my actual recommendation would be to begin by building a series of small toy projects. Build the classic ToDo app in whatever form you prefer. Build a calculator, a text editor, pong, an HTTP server, a database, a data visualization tool, a physics simulation, a paint program, etc., etc. None of them should be overly complicated, at first at least, but they will force you to think about how you use the language and will quickly show up the large gaps in your knowledge about it as well as point you in the direction of the current 'state of the art'.

"Not hearing is not as good as hearing, hearing is not as good as seeing, seeing is not as good as knowing, knowing is not as good as acting; true learning continues until it is put into action." --Xunzi

or if you prefer

"What I cannot create, I do not understand." --Richard Feynman

Javascript doesn't exist in a vacuum, and focusing on becoming an expert on just the language is IMHO a misguided effort.

The language is a means to an end and the most useful bits are exactly in the API's that the runtime provide, be they the browser or something like node / react-native.

The advice I often give for "how do I learn ___" is find something you want to make, do what you need to do to arrive at the most basic version that you possible can, then iterate.

If you have someone who can help direct you when you get stuck, or can point out ways things can be vastly better with minimal effort that will be a real boon to your efforts.

Focusing on arcane corners of the language just isn't productive. If you have a mission, you can deal with those when they come up (which due to their arcane nature, will be rarely if at all).

How does one take this knowledge and learn the browser APIs (in particular, best practices around those APIs) plus to navigate the frontend ecosystem in general without getting overwhelmed? Obviously you learn the APIs by building stuff, which I do. I can and do write frontend code, but always with the feeling that I've never learned this stuff properly.

I know there are tutorials aplenty on this stuff -- other than MDN, is there anything authoritative, comprehensive, and deep? Like, the SICP or TAOP of frontend programming?

I would recommend the official spec. It won't be an easy read, unless you're already used to reading standardese, but there's nothing more authoritative than that.

I've worked with JavaScript many times through the years, and never felt that I got close to becoming an expert no matter what. The language it self is in the way. Browser compatibility, language weirdness (like the =, == or === mess) and there are a lot of standards around. But now a days working with ClojureScript, which settles the language problems, I get to focus on getting good at libraries, react and browser-stuff.

I hope I never have to work with vanilla JavaScript again, but since ClojureScript is a niche I'm pretty sure this dream will burst at some point. But I can attest ClojureScript has brought significantly more enjoyment into my life when dealing with front-end development.

+ Use Typescript (no, it's not the same as JS)

+ Use ClojureScript

+ Use Elm

+ Use Reason

+ Use ...

If you go back about five years, you'll find this pattern also exists, except all the things people were saying to use are dead. Dead like a forgotten Egyptian pharaoh - buried and never to be seen again.

Unfortunately, all the code bases written in these poor JS-likes are still alive and I and many other poor souls still have to maintain the dang things.

You know what's still alive? Javascript. You know what still basically works the same? Javascript. You know what codebases from five or seven years ago I don't mind maintaining as much? Javascript.

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

I suspect that most of the ones I name will join the bone pile of the many other "superior languages" or continue to be used at most by a niche few.

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.

Unfortunately your chances of getting a job doing ClojureScript is probably slim to none :(

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.

We have an old creaky app which I'm tempted to rewrite in ClojureScript in my own time and then show them it.

Worst case scenario they say it's great, now can we please rewrite it in JS. Best case scenario I get something in Clojure / CLJS into our system.

Either way I'd probably learn a lot just from the project. And I kinda need a new side project at the minute.

Linux did not win the server space because admins snuck it in. It won because it was free and worked well enough compared to signing up for tens of thousands of dollars worth of lengthy contracts with SCO/HP/IBM or even Microsoft.

> Sneak ClojureScript in

I don't see this ending well.

It's great to do your side projects in your favorite language but foisting it onto your employer so they they are forced to use it is a pretty bad violation of trust.

What happens if you quit and ClojureScript programmers are hard to find at the price the employer can afford without going out of business?

I would never try and pull this off.

Many companies would not or because of SLAs _could not_ use free Linux. They would pay RedHat or Suse fees that included support/maintenance. Yes, it was still usually cheaper than Window licenses, but the price was not really the point.

Now about sneaking languages, platforms, and stacks in... Java was once too risky and unknown to be used in place of C/C++, but we snuck that in and proved it was up to task. Python... hah, Python was a toy "scripting language". No self-respecting CIO would approve of building company products in Python. Ruby? Rails? Surely not, those were also free, unknown, unproven technologies (which ironically were trying to supplant Java-based systems... that same Java which was once too risky).

PosgreSQL or MySQL? No way, that's not reliable for production. Of course it is, and it got snuck into companies whose engineers despised Oracle and SQL Server (not because MSSQL sucked, but because it only ran on Windows).

You can pick any modern best of breed tool, and I can point in history when that tool had to be snuck in to prove itself and gain acceptance.

I don't like the idea of "snuck in".

Working with management and having buy in that there's going to be a risk involved in taking something up that's new and unknown is OK.

That way we have a plan and action in place if things go other than expected.

That is exactly why I left a BIG5 firm and now work at startups because I can run these by the CEO and have a discussion.

The place where I work does not exist for my amusement.

Many people's livelihood including those of close friends and their families depend on the decisions I make.

If I am at a VC funded startup I am playing with the retirement of millions of people.

I owe it to them to be in the know of any risky decisions I take that I judge to be risky enough to affect them negatively.

Anything that's new and relatively unknown is risky.

That does not mean we don't try it.

It does mean we need to have a plan and action in place if things go other than expected.

Thats just good engineering and business because people depend on me.

Otherwise it's just a hobby and pastime.

My email is my handle at gmail.com

No obligation. I just want to connect with an individual interested in a "non-traditional" language :)

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.

It doesn't cover the complete language, in particular it doesn't cover all outdated concepts and backward-compatible features. To get a complete understanding you would have to read the JavaScript specifications, but I don't think it makes sense to start there without having a solid understanding of the basic concepts first.

If you want to dive deeper, you can then read Deep JavaScript[1] by the same author.

[1] https://exploringjs.com/deep-js/index.html

https://www.udemy.com/user/sgslo/

[Not sponsered, non-affiliate link, etc]

This point is made in the (now very outdated) book "Javascript: The Good Parts," https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfo.... Crockford, the author, brings you through the best way to write Javascript in 2008.

Related note: I once attended a talk from Crockford in 2010 where he was rather religious about how async code was significantly better than threads. I pointed out that async code is significantly harder to write due to the mess of callbacks, and his answer was quite rude. Now Javascript has async-await, which fixes the madness that comes from callbacks.

    waitForPromise()
        .then(handleResolve)
        .fail(handleReject)
        .catch(handleException);

    waitForPromise()
        .then(handleResolve, handleReject)
        .catch(handleException);

    waitForPromise()
        .then(handleResolve)
        .catch(handleReject)
        .catch(handleException);

As initially I thought catch() is only handling promise rejections. Then suddenly I ended up in the catch() although the Promise resolved fine, just to learn that my handleResolve code threw an exception. Unsurprisingly my handleReject code was not prepared for this.

enough said

JS is a rather forgiving language (maybe too forgiving) that's very suitable for learning by trial and error. Get the basics, start hacking, find what works and what doesn't, look at other people's code to draw inspiration etc...

> Where do I go?

You don't really need to go anywhere else (especially not into the vortex of looking for the best resource) to learn and be confident with vanilla javascript.

> ... and how hard is this actually going to be?

Well that depends more on you and your preference for learning materials. I studied a chapter a day (like 3 hours concentrated per day) and was done in 3 weeks.

I have bookmarked few other links from HN

https://news.ycombinator.com/item?id=13979472

https://github.com/getify/You-Dont-Know-JS

https://www.robinwieruch.de/javascript-fundamentals-react-re...

If you don’t know any programming, it’s a bad idea to start by JavaScript. Its design has followed a path from a hackish webpage scripting language to being used server-side, so a lot has evolved and a lot of crap remains from the old days. If you don’t know programming, you’ll have a hard time discerning the newer, cleaner features from the older less polished ones.

In my opinion it’s easier to learn java or C or Kotlin, which are a lot neater. And then learn about how JavaScript differs.

I’ve found the courses on this site to be great. Easy to follow, diverse, and useful for non-front end engineers like myself.

However, just being able to do something in a language and being able to do it the most correct and future-proof way is different, and in JS, "best practices" seem to be constantly evolving with language and community. Every library and framework seem to be doing things in a slightly different way, and there's a lot of freedom to experiment with different coding styles and programming paradigms (unlike in a language like Go). Personally, I would suggest Typescript for professional projects, but there are plenty of very knowledgegble and competent people with a lot of different opinions on it. If you're the kind of person who likes this kind of environment, you'll fall in love with JS ecosystem.

Why choose V8 as your target, and not a recent standard that multiple modern browsers support?

If you're dead set against browsers, you'll probably have to use deno since its API is friendlier to async/await than node's is.

IMHO, Eloquent JavaScript is a great book but not really beginner-friendly. It's a solid choice if you are already proficient with another language.

This course really pushed my js knowledge forward!

https://www.udemy.com/course/understand-javascript/

After watching that I would recommend https://github.com/getify/You-Dont-Know-JS and that should give one a solid base.

There's not a lot of point in obsessing over the minutiae that is constantly in flux and varying at the whim of the Chrome and Firefox teams. You'd be aiming at a moving target, and one that is constantly jinking up and down and side to side, even when it is going in the same direction and not doubling back on itself.

This isn't comprehensive, but it's probably the most helpful deep-dive I've ever seen about some aspect of JavaScript. It's about the Event Loop, which is one of the biggest differences between JS and comparable languages like Python: https://www.youtube.com/watch?v=8aGhZQkoFbQ

Contrary to what you might think, even though the event loop is in some sense "distinct from the language", it isn't simply an API. You can't really have JavaScript without the event loop; it exists in both the browser and in Node, and is the basis for most of the language's advantages.

If you mean ES6 as "modern" JS, then you might want to avoid any material on prototypical nature of "true" JS (which it still is under the hood). Personally I find classes and modules to be very useful.

Although you say you don't care for DOM, CSS and the many frameworks, you might need still need to build a small HTML file to kick start your JS programs. I do all my exploring and learning in Chrome's DevTools console and debugger. JS is not that difficult to learn if you already know a curly brace language (C, C++, C#, Java, etc). Even after years of working with JS, fiddling with DOM still catches me off guard on occasion.

ES6 classes still use prototypal inheritance and it still has important effects on usage.

I have found that understanding prehistoric JS provides a good base for making sense of where JS is today.

John Resig's (jquery) writings were very helpful, and this site is an absolute must for me.

https://johnresig.com/apps/learn/

[Javascript: The Good Parts](http://shop.oreilly.com/product/9780596517748.do) -- Once something makes it into Javascript, it's there forever. While this book only covers up to ES5, it creates a good foundation for things to use and things to avoid. This is especially relevant if you wind up working with older codebases.

[Exploring ES6](https://exploringjs.com/es6/) -- This book will take you from the ES5 land into the world of ES6 (ES 2015). It does NOT cover newer features from ES2016-ES2019, but only a couple of those are major updates.

[Javascript Allonge](https://leanpub.com/javascriptallongesix/read) -- A nice, soft introduction to functional JS concepts.

[You don't know JS](https://github.com/getify/You-Dont-Know-JS/blob/2nd-ed/READM...) -- an overview of the language feature by feature. I feel it's a bit too advanced for an introduction on quite a few things though.

I'd avoid Javascript: The Definitive Guide. It doesn't do a great job of distinguishing between the good and bad parts of the language and some examples aren't best practice anymore. Maybe they'll get around to creating a 7th edition one day that'll be worth reading. Likewise, I'd avoid reading the spec until you've worked with the language for a while. It's not light reading. I'd start with the 5.1 edition because it's much easier to approach (and much smaller at only around 250 pages). Once you've read that, it'll make reading the newer specs much easier (ES2019 spec is over 3x as long).

It takes years to become good at programming. Once you know programming, it usually takes hours to learn a new (procedural) programming language.

Really? I feel like I’ve spent longer than that just trying to get my head around JavaScript’s prototypal inheritance. I’m even more confused by Promises.

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. doesn't seem very useful now, but they are composable:

``` function add2(a, b) { // return a promise NOW, that will give us the sum of two numbers in 5 return new Promise((onComplete) => { setTimeout(() => { add2(a + b) }, 5 * 1000); }); }

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

Now we don't have the masses of indentation of callback hell. Note that will take the same amount of time to run as the callback example. Promises don't make anything faster, they just help us to write synchronous looking code. The next step to bring us back to imperative looking code is async/await. But that's for another time.

Finally, the best way to learn is to do. Get a hold of VSCode, and get the Quokka extension. You can then `Ctrl+Shift+P` or `Cmd+Shift+P` and `Quokka: new javascript file`, and get a real time repl where you can mess around and log to your hearts content to get a feel of things.

I also tried to learn JS from all the popular books and the problem was that most of the stuff I read in thos, I've never used in real life. And so much sophisticated stuff which books didn't teach was hidden in some lib's Github repos.

That said, if you want a comprehensive read about Javascript, there's You don't know JS: https://github.com/getify/You-Dont-Know-JS

https://www.youtube.com/watch?v=qoSksQ4s_hg&list=PL4cUxeGkcC...

https://www.youtube.com/watch?v=iWOYAxlnaww&list=PL4cUxeGkcC...

I'd also use various materials, like books or courses online.

Finally, start a small project in JS, best way to apply your knowledge and discover gaps.

Pure JS will be a bit boring. You’d want to learn some Node apis to do something useful. But you could limit it to file I/o if it’s the JS you want to focus on. At least that’ll give you some async experience which I’m sure you’d be keen to learn.

[0] https://bellard.org/quickjs/

"If you think you understand quantum mechanics, you don't understand quantum mechanics." - the same is true for C++ which is one of a few languages impossible to learn to the perfect and complete level.

now that book is old and es6 changed a lot of things, so find a good book read it and if it has examples go thru them. only with examples was i able to understand scope inheritence and asynchronous calls in javascipt. like if you call settimeout in loop and all other gotchas.

I don't mean babel. I mean from scratch. Using whatever language you're comfortable with, turn lists of expressions into JS code.

https://github.com/sctb/lumen does this in just a couple thousand lines.

this is where i got started , now got a good handle at JS, but not sure if it will fit / suit you

(I know the author lurks here sometimes)

https://www.executeprogram.com/courses/modern-javascript

The JS courses are free.

[1] https://wesbos.com/courses/

https://javascript.info/

https://sivers.org/prog

i had no idea eloquent javascript was updated with modern javascript. what a surprise! i read that book many years ago. i will check the other resources too.

[0] https://quokkajs.com/

My recommendation for learning this language is to forget all the books and helpful guides. Just build something. Here is a good reference of the standard methods: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Of that reference list the most immediately important areas are: Array and String.

My personal recommendation for really embracing this language are to learn and master scope in the language. Don't mess around with class, prototypes, inheritance, new, or this until after you have built at least one tool in the language. Most people coming into this language jump in expecting to program in the style of some former language only to be disappointed that JavaScript is not in fact their former language.

My second personal recommendation is to gain confidence around the expressiveness of functions in this language. Functions are first-class objects, which means they can be used anywhere a primitive type can be used. https://developer.mozilla.org/en-US/docs/Glossary/First-clas...

Perhaps the most important thing to learn for any language is data structures. If you have a solid understanding of data structures you can bend any algorithm to your will.

You mention not learning any APIs, but there are two exceptions you should make in order to better understand the language.

* DOM - If you are learning JavaScript in the browser I recommend learning the DOM. I mean the standard imperative DOM methods from the DOM specification. The DOM is a tree model of nodes where each node knows its place in the tree relative to its peers. By appreciating the nature of those fluid relationships you can do incredible things with little effort that execute incredibly fast. I built a complete GUI in the browser in just over 2 weeks that executes as fast as the OS's GUI because I had an understanding of the DOM. Here is the video demo: http://mailmarkup.org/sharefile/demo1.mp4 and code: https://github.com/prettydiff/share-file-systems

* Nodes fs library - If you are learning JavaScript on the terminal with Node.js I recommend learning Node's fs library methods. The file system is also a tree model comprised of nodes that can be walked very quickly.

After you have built one or more tools in this language you will independently learn to appreciate the conventions in this language that best suit your personal programming styles.