Hacker News new | past | comments | ask | show | jobs | submit login
JavaScript for Impatient Programmers (exploringjs.com)
235 points by MindGods 2 days ago | hide | past | web | favorite | 123 comments

Can anyone recomand a “JavaScript for profesional programmers”?

I.e. something that introduces JavaScript assuming you know a lot more about programming than your average JS developer and explains the JS pitfalls in common terms and not js “ecosystem” inventions?

MDN has a guide called "A re-introduction to JavaScript"[1]. I believe this is what you're looking for

1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re...

I can second this recommendation. JS is an odd bugbeast in that it took some design shortcuts early in it's life that aren't really visible without this kind of "here are your primitives" review. It also works like any other language primer in that it doesn't go into needlessly specific domain bound examples. That kind of stuff should be in a stdlib-eqsue doc.

A good read for even for some one like me, who slings JS almost daily.

That's nice but just a start. JS type coercion is only mentioned in passing for example.

I know JS is mocked for the horrible type coercion, but on a day-to-day basis I don't find myself needing to know how it works in detail. All you really need to know is that you should avoid it. Use triple equals and don't try to add or subtract non-matching types.

It specifically gives you an example of how "==" clearly sucks and shows you how "===" fixes it. I don't see why a "guide for professional programmers that know more than the average JS programmer" (as per the request) would need to belabor that any further.

So what types are converted to what, automatically? And is it only for == or there are other traps?

In most languages that I know this is documented. They don't tell you "this sucks don't use it".

I think this is what you're looking for. 3rd result for "Javascript type coercion": https://2ality.com/2019/10/type-coercion.html

Sorry, I'm looking for a comprehensive manual, not a series of random blog posts. I knew about type coercion because everyone laughs at it, but what about the things I don't know to ask about because I don't know they exist?

Did you... read the link? It's literally exactly what you're asking for.

Sorry for trying to help I guess, good luck.

I did. It explains type coercion. It’s not a comprehensive JavaScript manual.

As a primarily frontend developer, I've had a couple of good experiences helping some experienced backend developers work through You Don't Know JS[0].

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

I'd consider Eloquent Javascript the best JS book out there and actually one of the best programming books I've ever read


It may be a bit more introductory than you're looking for, but trust me in that you'll want to read it from front to back as it builds on itself.

It's not short and quick, but it's comprehensive, good, and even fun!

Having read many programming books, I find at a professional level, you just want to get straight to the juicy stuff with real life examples. For that, Goal kicker is hands down my go to for that. While you're at it, also download the NodeJS ebook from there too. They're free.

https://books.goalkicker.com/JavaScriptBook/ and https://books.goalkicker.com/NodeJSBook/

Thank you for sharing

There's a new edition of the O'Reilly doorstop "Javascript: The Definitive Guide". I've learned a lot from it and started to use modules, promises and dropped all my horrible old 90s habits.

It reads really well, explains the modern bits as the right way of programming, but also puts the crusty, abandoned bits into the right perspective (if you're looking at old code I guess).

It's not at all a book for new programmers, but for someone who knows Ruby well, it's a great, concise read.

"You don't know js" book series is good for what you describe

JavaScript: The Good Parts by Douglas Crockford. Note that this was written in 2008 but still holds up well.


It may be a perfect time for a revision.

It predates ES5, and a revision is imo long overdue. It was an excellent resource in its day, but there are a lot of good parts too new for it to have covered.

Books that fit that description, and that I've heard good things about are JavaScript: The Good Parts (but maybe not quite up to date anymore?) and Eloquent JavaScript.

Zed Shaw is coming out with a book[0] on the topic, I like his Learn X the Hard Way series so I'll probably pick it up when it arrives.


I miss the old days of Ruby, Mongrel, and Zed Shaw (and drama).

Though I also think I took a liking to the guy when I decided he looked like Neal Stephenson.


Tell us how you really feel.

I have good experiences with Javascript Allongè, I know the author is on here as well. It builds up your understanding of the language from the basics, focusing on JS specific things like function scope and higher-order functions and `this`, without insulting your intelligence.

I can also vouch for Javascript Allongè. It's a fantastic read.

I recommend JavaScript: The Good Parts. It's pretty dated by now but still is a quick introduction to JavaScript for professionals. You can then read MDN for new features not covered by the book.

The Good Parts by Crockford will always be on my list. It's dated in terms of language expansions, but it really will lay the foundation for many of the patterns that are now commonly used.

Kyle Simpson's volumes are excellent.

Eloquent Javascript

The author's earlier ES6 book is great.

Most of the above books have a few chapters you'll end up skimming or skipping.

Don't know about "Professional" However, if you want to go the LISP route in the tradition of The Little Schemer, then check out: The Little JavaScripter:


Also in general even if programer don't end up using LISP type of language they get better by just learning it. And Javascript is decent stand in for LISP, as Crockford points out.

I actually know some LISP, among other things. I'm asking specifically about JS.

I'm enjoying Manning Book's "The Joy of JavaScript", in early access but available. I'm currently reading about how mixins are done using JavaScript's unique features, and I'm looking forward to the function programming and algebraic data types.

How much or how little does "your average JS developer" exactly know according to your opinion?

MDN is by far the best resource on JavaScript. It's most a reference site but they have tutorials too:


Maybe a bit too slow if you already know other languages, but you can at least trust it not to give bad advice. There are an absolute mountain of inexperienced JS developers out there giving a lot of bad advice. Take every StackOverflow answer with a fist full of salt. MDN is reliable though.

Yeah, that’s the whole point. I don’t want to be told how a loop works in kindergarten terms. I want to know the memory and event model and be told in one line why JS has three equality operators. I want a concise list of types and automatic conversions. I want to know how Node’s multitasking differs from Windows 3.1, because my impression now is it doesn’t. Stuff like that, you get the idea.

(Just in case the title is putting you off: You are describing the goals of this book.)

I agree. Sounds like this is exactly the book they're looking for:

"No prior knowledge of JavaScript is required, but you should know how to program."

As for introduction, how about this:

> ('b'+'a'+ +'a'+'a').toLowerCase()


For those curious, the +'a' after the space is a unary addition operator that evaluates to 'NaN'.

See also:

alert(Array(16).join("wat" - 1) + " Batman!");

From: https://www.destroyallsoftware.com/talks/wat

but if we're being serious, "Learn X in Y minutes" is pretty efficient, and also Dan Abramov's email series (sign up on his site)

Dan Abramov makes good, super accessible material on any subject he focuses on. His React series is also good. Guy's a good egg.

I'd recommend doing an online course where you learn something useful like React and the ES6 syntax will come for free as you go along. I found Udemy to be quite useful.

Otherwise, from a programmer's perspective, JS is like nothing else I've seen and it's not something you want to be using without an abstraction over it, i.e. some framework that makes life less miserable when building something more complex than a form.

I feel like being a 'JS professional', unlike other languages, mostly involves in-depth knowledge of the right tools and not the language itself. Unless, you are interested in building frameworks yourself, which I personally find no need to ever do given the available options.

React is a particularly bad way to learn pragmatic Javascript because it's idioms are quite different from how people program in any other scenario but UI dev. It's a UI library and you won't learn much about Javascript programming from it. You will just know React.

You should absolutely learn React if you want to be employed writing with JS, but people should understand where React lies in the context of javascript. It isn't an abstraction of JS, it's a UI library written in JS.

> You should absolutely learn React if you want to be employed writing with JS

I know that this probably isn't how you meant it, but I think what you said is a bit misleading to someone who wants to learn JS for a job.

Having skills in React are an almost guaranteed way to get a job writing JS. It's definitely not the only viable way to get employed writing JS. Contrary to popular belief, there are many jobs out there asking for Node.js skills but not necessarily React or any heavy frontend knowledge. You can also make a living doing Vue or Angular, and Svelte is an up and coming framework that will be good to learn and I believe will create lots of jobs. I've been writing mostly Ember.js code for years now, yet I'm employed.

I just want to make sure that learners don't think that it's all React or nothing. Nothing against React, by any means. If someone learns React but it doesn't interest them, their career in JS isn't over.

> it's idioms are quite different from how people program in any other scenario but UI dev.

Many of those idioms borrow from ideas (functional programming, reactive programming) outside UI development, and outside JavaScript.

I would think that an experienced programmer starting with JavaScript would appreciate React.

This advice is so strange. Do you imply, that learning pure JS is not useful? I dread this attitude. Also, you cannot have "in depth" knowledge of any higher end abstraction whithout knowing the language. By definition it will always be just a superficial knowledge.

Pure JS obviously has its uses but I am assuming every professional values productivity which one can't often obtain just by knowing JS itself. JS sometimes feels like assembly, you just don't want to touch it, that's why things like TypeScript exist, for example.

Also, saying an abstraction is useless without knowing the language is similar to saying you can't drive a car without knowing how the timing belt or crankshaft works - most people do fine without either. I'm not dismissing the value of JS fluency, just suggesting that it might be unnecessary and a more practical approach can be taken.

> JS sometimes feels like assembly

Every time I see this statement, I wonder what the Venn diagram of people who say so and people who have ever written a line of asm looks like.

I don't even get it. You write Javascript basically 1:1 the same as Python or Ruby. And I would argue it's even nicer in various cases, from destructuring to lambdas to async/await and first-class Promises.

I wonder if the people say they avoid JS at all costs because it's "like assembly" have been doing that so effectively since 2003 that they never even tried modern JS

See what I was saying in the OP about the average JS developer :)

It's not even their fault, it's all they know from those online courses or boot camps.

I read a blog of a fresh grad describing ‘this’ keyword in JS. The conclusion he/she had by the end of the article was ‘don’t use “this” keyword unless you are JS expert’.

I always see a pattern with these things. Usually if you don’t learn the language well enough, you probably are also not spending enough time learning the frameworks well enough, and you probably are not learning the DOM/Browser well enough, and you probably have not learned CSS well enough. You will have no choice but to hide behind the frameworks.

The people that just learn React or the latest ES6 think they know good enough JS, but when I see their code I see clear patterns of poor abstractions, separation of concerns, the kind of code that makes you want to take a shower after touching it.

Been there. Those who assume or are hubristic enough to think they know enough can be dangerous.

I'm curious, do you have a link to the blog post?

A little learning is a dangerous thing ; Drink deep, or taste not the Pierian spring : There shallow draughts intoxicate the brain, And drinking largely sobers us again.

I don't (think I) have much of a problem with JS syntax, generally speaking, but I'm often baffled by the surrounding ecosystem of build tools and "helpers". There are a million tutorials, all doing things slightly differently without really explaining why, and stuff breaks so often...

Any recommendation for something covering that sort of thing (npm, yarn, webpack...) in a more structured and in-depth way than "here's how to make a todo list in 10 minutes with some magical command that may or may not still work 3 months later"?

I sympathize with this. I wanted to use, and slightly modify, a small web app I found on GitHub.

Despite it being client-side only, it used node. An older version, with older versions of webpack, Babel, and so on. And tons of now deprecated npm packages. It was only a couple of years old.

The only way I could make it work, after days of trying, was a docker container of an older Linux distro. I did try just upgrading packages, but the avalanche of dependency hell made that literally impossible.

I have not had this experience with any other language.

Edit: Noting I have had to update/upgrade older Perl, Python, etc, projects. And they weren't all easy. But they were at least possible. Dozens of things to chase down. Not hundreds.

Yeah, because package-lock.json files were never a thing.

As a backend developer getting his foot into frontend I feel you. Configuring TSLint with Prettier and all the plugins was tiresome only to learn few months later it's getting deprecated and you should move to ESlint. This article helped me bit, it explains "what is what" in modern JS ecosystem https://medium.com/the-node-js-collection/modern-javascript-...

Excellent article, I just hope that's kind of stable... every time I look into the JS it feels like I've never looked into JS before.

My honest opinion is that you should read the npm-cli docs[0], the babel docs[1] and the webpack docs[2]. I think that most tutorials want to skip to the "getting stuff done" bit, and learning these tools with a bit of granularity is well worth it for any serious Javascript project.

These three tools form the backbone of most modern Javascript projects. Understanding what they are, why they do what they do, and how to extend them is vital to being able to work with modern JS.

The docs, particularly the introductions are written for a fairly inexperienced audience and I find them easy to work with.

[0] https://docs.npmjs.com/cli/npm [1] https://babeljs.io/docs/en/ [2] https://webpack.js.org/concepts/

I'd recommend the Webpack tutorial by Andrew Mead, interestingly enough. It goes through all these tools and why they're needed, and you build out a simple config with Webpack and understand exactly what it does and why.

I'm interested in checking this tutorial out but I can't locale it anywhere. Got any links?


Looks like I misremembered, it's actually by Colt Steele.

Thank you!

What do you think of it?

I really like it, actually. I finally had a free hour this afternoon to start getting into it. I'm only on video 6 so far but I've already learned quite a few things that I had missed and/or misunderstood previously. I've also sent it out to my team so that they can check it out next week, after the holidays, (and during work hours) to fill in some of the gaps they may have, as well. Thanks again for mentioning it and linking it!

Yeah, I'm in the same boat, I'm still struggling to figure out how to write a library in typescript and then use it as a browser library. I have a feeling that I just need a better understanding of the core concepts (modules, bundlers, etc..)

It's good to understand modules well. Understanding bundlers is less important and can be postponed. Just use let parcel do the transpiling and bundling for browsers.

It's quite simple actually. With native modules support you don't really need any of these helpers.

However, if you're concerned about users on older browsers, you can use Babel to "transpile" your code to equivalent code that older browsers can understand, often at the expense of size.

npm and yarn are simply 2 competing implementation for package management. Start with npm and you'll know it when you want yarn.

Webpack and other module bundlers are just tools to automate things like transpiling, code-transformation, bundle-splitting, minification which are not all that essential actually.

The point is all of these are extras. Think of them as enhancements/optimizations. If you have a solid understanding of JS you can write JS in a way that doesn't require any of this. I blame the tutorials out there that say you need this and that without many justifications that make it seem more complicated than it is.

> Webpack and other module bundlers are just tools to automate things like transpiling, code-transformation, bundle-splitting, minification which are not all that essential actually.

I wish this were true. My experience to illustrate the point:

I have a Javascript library[1] for working with the HTML5 <canvas> element. It's a nice library (in my opinion) but it is a bit on the large side. Also, I developed it as something that can be added to a website in the old-fashioned way, using a <script> tag.

However, most non-personal websites these days are built with toolchains which include code bundlers like Webpack (many React sites), Rollup (Svelte sites), Packet etc. Developers working on those sites don't want to add a <script> tag to their HTML file; they want all their Javascript npm-included or yarn-added so it can be shaken and bundled and tied up in ribbons and bows for delivery to the user's browser or device.

So I did the work of turning my library into an NPM package and tried building a toy project with a toolchain. The failure was embarrassing. It turns out that I was using a JS feature in my library code which isn't supported by any of the main bundlers (`import.meta`, for the curious[2]. I raised a ticket with one of the bundlers to see if they could add support in a future release[3] but it seems the feature is too obscure to care about.)

I sorted the problem by rewriting my library (in a very unsatisfactory, ugly way) to get bundlers to bundle the code. Now people can add my library to their React/Svelte/whatever project. But the whole learning episode left a bad taste in my mouth: Being tripped up by Vanilla JS is one thing; having your work trashed by the bundlers in the toolchain is just nasty!

[1] - https://scrawl-v8.rikweb.org.uk/

[2] - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3] - https://github.com/parcel-bundler/parcel/issues/3269

I agree. Even just finding out what the tools are is ridiculously hard. Here's a list:

* NPM: Package / dependency manager. Also has some basic support for running scripts.

* Yarn: Very similar alternative to NPM.

* Babel: Transpiles modern Javascript to "old" Javascript, in case you need to support IE9 but want to use async/await or whatever. If you only support modern browsers you don't need this.

* Webpack: Originally it was for "bundling" Javascript files. You don't want to write all your code in a single file, but you often want to deliver it that way. Webpack reads the 'import' statements of all your files, and them converts them into a single file with emulated modules. Also helps when you are targeting a browser that doesn't support modules natively. However Webpack also comes with a load of "loaders" that can transform input files in various ways, e.g. allowing importing CSS files from Javascript, compiling Typescript, etc. So now it is kind of a big ugly build system.

* Node: The Javascript engine extracted from Chrome, plus a load of native APIs that let you do stuff you can't do in the browser because of security (write files, make TCP connections, etc).

* Electron: Basically Chrome plus Node. You can set it up so that your web pages can access the Node APIs inside Chrome, but you can also have them talk to an actual Node process via IPC.

A little npm actually goes quite a long way:



Although you should probably prefer yarn these days (concepts should mostly transfer over).

As for tranformations/transpiling/minifying... You could use webpack - it is popular, but quite complex. I've found this a decent introduction to understand how it works:


The good part about going that route, is that is quite explicit... You might get away with throwing out explicit in favour of convention - by using parcel instead:


(looks like gh readme is currently best entry point for 2.0 docs).

NPM is a pretty awful build tool really. In the only NPM project I work on we write a Python script as the build system, and the NPM scripts call that.

Don't really disagree with that. On the other hand, npm/yarn is generally a dependency you can't get away from - so if your needs aren't complex, I'd say in general, you're better off with a simple npm/yarn config, than pulling in another dependency.

Of course pulling in python in a python project is free, if python is tightly coupled to the js stuff anyway.

Often eg: the front end will be just js/ts - and reusable/useful without any python.

I would not suggest this book. While it does begin with simple, concise examples, it leaves out many important details.

For example:

- The first variable using `const` is called ”immutable”, which is misleading, since only the _assignment_ is immutable. Later on the same page, a const object property is assigned to without any clarification as to why it works.

- Only single- and double-quoted strings are introduced at first, even though template strings are arguably the cleanest for building strings.

- Arrow functions are introduced as just another syntax - neither implicit `this` binding nor implicit return of last block statement are mentioned.

> The first variable using `const` is called ”immutable”, which is misleading, since only the _assignment_ is immutable

That’s a first look at the syntax. The details are explained here: https://exploringjs.com/impatient-js/ch_variables-assignment...

But I should clarify that “immutable” here means “immutable binding”.

> Only single- and double-quoted strings are introduced at first

I had to start somewhere. Template literals and tagged templates are a more complex topic that benefits from strings already having been introduced.

> Arrow functions are introduced as just another syntax

Arrow functions are introduced in detail here: https://exploringjs.com/impatient-js/ch_callables.html


In general, I occasionally have to initially leave out some details so that the book can be read linearly. But those details are then filled in later in the book.

Thank you for your books and websites! After reading 1,000 sites explaining that async/await is just "syntactic sugar" [hint, it's not], you're the only one who explains it correctly.

You should define and describe the concept of "binding", if you don't already. Telling me a const declaration is an immutable binding does nothing for me if I don't already know, or immediately find out, that binding is the general case of assignment, an association of a value with a name. Given that and an understanding of the differences between value and reference types, there are few surprises left for me in how Javascript handles names and values.

I sometimes find myself informally teaching devs less experienced with the language, and I've learned to cover this part of it very early. It's not made terribly obvious in a lot of resources people have mentioned using, and I've yet to encounter a case where developing that understanding failed to help someone better understand the code they were writing, and thus write better code. (Usually I'm also reviewing a lot of their PRs, and that makes the change pretty easy to see.)

I agree! I’m in the process of editing the relevant chapter.


I've been looking a long time for a good "Javascript in a Box" that I can give to mentees as a tool for extended learning beyond what we can cover directly. Your book and its associated materials look as if they might be just the thing, and I'm evaluating them as such.

Is there an email list or something I can use to be notified when the revisions you describe have landed? I have someone already in mind to be a "beta learner", but I'd rather wait a little for the updated version, and it would help to get some kind of push when it's available.

Ping me at dr_axel AT icloud.com and I’ll notify you. Two universities in Switzerland are using my book to teach JavaScript and seem happy with it, so far.

> an understanding of the differences between value and reference types

It's a common misconception among JavaScript programmers, especially experienced ones, that such a difference exists. It doesn't.

The usual explanation is that there are value types such as number or string, and reference types such as array or object, and these are treated differently both by the assignment operator and when passing an argument into a function: the value is copied for a value type, but a reference is copied for a reference type.

This is often illustrated with an example like this:

  function a( str ) {
      str = 'moo';
  let s = 'bar';
  console.log( s );  // 'bar'
  a( s );
  console.log( s );  // still 'bar', because a string is a value type
  function b( obj ) {
    obj.foo = 'moo';
  let thing = { foo: 'bar' };
  console.log( thing.foo );  // 'bar'
  b( thing );
  console.log( thing.foo );  // now 'moo', because an object is a reference type
This code does work as the comments describe: 'thing.foo' changes but 'n' doesn't. But this is not because of any distinction between "value types" and "reference types".

It's because the code in the a() and b() functions is different!

The code in a() reassigns the function parameter (which is a local variable) to a new value. The code in b() doesn't do this, it sets a property of its parameter.

The difference in behavior is solely due to this difference in code.

Every example that purports to illustrate how "value types" and "reference types" are handled differently in assignment or parameter passing makes this same mistake.

To illustrate further, strings are commonly described as a "value type", as in the example above, and most of these discussions say that when you assign or pass a value type, the entire value is copied. But no JavaScript engine worth its salt does this. If you have code like this:

  let str = 'one billion characters here';
  let copy = str;  // Does it *copy* the billion characters? Of course not.
Now for a short fixed-length value such as a number, a JavaScript engine may well store and copy the actual value. But this is an internal optimization, not part of the JavaScript language. It is fundamentally unknowable from JavaScript code whether the engine stores the value inside its internal Value object or stores a reference.

The real difference between so-called value and reference types is that the latter may have mutable properties and the former don't.

One last illustration: if you have an object and then call Object.freeze() on it, the object now has no mutable properties (and none can be added). Does that convert this "reference" type into a "value" type where future assignments will copy the value instead of copying a reference? No. It's just been made immutable.

I will be happy to discuss further if anyone has questions or disagrees.

This is a splendid example of the kind of thing I let mentees discover on their own, when it actually starts to matter in what they're doing, rather than burden them with right up front. If binding is an uncommonly encountered concept, interning is a practically unheard-of one, and it would be a severe disservice to explain it, and copy-on-write, at the same time as everything else I'm asking someone new to the language, and often new to programming entirely, to follow.

You're right that the description I gave is fundamentally a false one. But it is a harmless, and an extremely useful, lie.

(In any case, you're underplaying your hand here. If you're going to get deep into the weeds on how Javascript values really work, why leave out implicit autoboxing?)

I roundly disagree with your logic if not with its conclusion. Your comment makes the (same) mistake of conflating three entirely separate concepts:

- reference/value _data types_ - call by reference/value/value result/etc _evaluation strategies_ - (im)mutability

JavaScript has both reference types and (what are treated in the abstract if not in implementation as) value types. It also implements (solely) a call by value evaluation strategy, which is orthogonal to the previous statement.

> const is called immutable which is misleading

Consider that this may simply be a knowledge gap on your end. I think most programmers understand the concept of value vs reference types and would not assume an object to be a value type. Obviously the reference is immutable, as is any other value type you assign to the const.

> nor the implicit return of last block statement are mentioned

Probably not mentioned because it doesn’t exist. There is no implicit return of the last block statement. That statement is misleading in at least two ways: there cannot be multiple top-level block statements as the body of a function, nor does the singular block statement body of an arrow function implicitly return the last expression. It actually requires an explicit return statement. On the other hand, an arrow function with an expression body -does- implicitly return.

Good point. However, most web developers starting with JS tend to come from PHP with its &$variable reference-passing magic.

I seem to have chosen my wording badly, since I did not mean (labeled) blocks, but indeed the expression body (which may have been referenced in the book as a ”block”, too lazy to check).

Maybe they meant implicit return after the last block statement (ie the implicit return void)? But that's not exclusive to arrow functions, so probably not.

>Consider that this may simply be a knowledge gap on your end.

My experience says this is very far from the truth. JavaScript's implementation of const is confusing for almost everyone the first time they come across it, especially the area you're talking about - changing collections. Junior engineers and non JavaScript senior engineers alike don't seem to understand what const actually means until they dig in to get deeper context, which I would point as a pretty big failure of language design.

I think it's a failure of education, specifically around the concept of binding as the general case of assignment.

I came late to that myself, not encountering it as a discrete concept until I got interested in Lisp, and found it clarified a great deal for me that had previously been obscure.

With that concept available, const is trivially explained as an immutable binding, as indeed the author of the book under discussion explains it elsewhere in this comment thread.

Without it, yeah, const feels full of special cases, just like everything else involving non-primitive types. It's something I've learned to cover early in teaching the language, because a little early effort there goes a long way toward clearing up a lot of confusion later.

I don't think it is really confusing if you already know how "final" works in Java or (const) references in C++.

No book is perfect.

Good points. What would you suggest instead?

My two favorites are YDKJS (You Don't Know Javascript)[1], and Eloquent Javascript[2].

[1]https://github.com/getify/You-Dont-Know-JS [2]https://eloquentjavascript.net/

FWIW, I'd say that "javascript for impatient programmers" should have a course teaching patience as first chapter ;)

Thanks for the mention! The book is free to read online and was updated to ECMAScript 2020 last week.

It looks like a great book, but I find it strange that the target audience is "impatient programmers" and it's 548 pages long. Am I too impatient?

The book did indeed get longer than I had planned. However, there is a “quick mode” for reading it: https://exploringjs.com/impatient-js/ch_about-book.html#isnt...

Impatient Programmers should be reading "Patience for Impatient People" or consider an alternate career.

Suggestion: If you are impatient, do not become a programmer.

Programming is a craft. It needs patience. You need time to learn the ropes.

Some people look for shortcuts, learn the tricks of the trade instead of the trade. Please do not be one of those people.

Imagine what would happen if someone with that mindset built bridges or skyscrapers. Or roads. Anything, really.

In fact, be prepared to try things and then throw them away, because only after you failed once have you gained an understanding of your environment and what you are actually trying to achieve in it.

I strongly disagree.

Almost every very good programmer I know is very impatient. Due to their impatience they go faster, and going faster all the time leads to making more stuff, which leads to a compounding effect on all the work you do and the knowledge you acquire, which leads to better software.

Getting to a better or equal solution faster is always better, and you need to be impatient to go that way.

The hacking philosophy and its child UNIX are built around people and processes like that.

On a more general note, I think any gatekeeping like this is harmful, do not listen to people telling you to not become $SOMETHING (programmer, engineer, artist...) because you are $SOMETHING (impatient, disabled, a woman...) and do what you want with your life.

Larry Wall, granted he made Perl, says these are the three virtues of programming.

> Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.

> Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.

> Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.

I think in the end the best way to describe a good programmer is "detail-oriented" and "results-based" that cuts out the bullshit and can ship. The better programmers that are product developers see programming as a tool to make products, not a tool to bike shed and yak shave all day.

[1] http://threevirtues.com/

How did you come across such a narrowly scoped website? Is it yours?

I've seen this site multiple times. Larry Walls quote is well-known, and this site is often referenced at the same time.

The title is tongue-in-cheek. The book itself is not superficial.

Thank you, this is just what I needed! I started reading Eloquent Javascript recently, but since I already know Java and Python it was too slow paced for me (I don't need to read 5 pages on if/else statement)

I skipped some sections, but I feel like that book does a really good job of introducing lesser-known aspects of the language (like how async/await is kind of just generator functions + promises, or how Symbol.iterator works), and then it gives good historical context for idiosyncrasies (like the difference between esmodules and commonjs).

While a PhD is short for a Doctor of Philosophy, at universities such as Princeton or Stanford the title "Dr." is reserved for medical doctors. At less secure schools one sees the title imposed by administrators. It's a wonderful poker tell; you'd think people would be aware what they're signalling? Or they know, but we're not their intended audience.

In Germany, "Herr Professor Doktor" is often in jest, as one usually restricts to the highest ranking title. And titles are fading, a form of class-consciousness. To use "Doktor" unnecessarily reveals one is not a Professor.

So I don't understand the cultural context for this author's use of "Dr." It's welded to his web site dr-axel.de; perhaps this is a stage name like "Dr. Ruth".

I always just read it as "this person is proud they put the work in to get that title" and leave it at that. Life is too short to worry about the the other stuff ;)

Granted like you I noticed it too, it is something that I think I've seen less commonly used too ;)

> at universities such as Princeton or Stanford the title "Dr." is reserved for medical doctors.

At Stanford at least, this (admirable) attitude is more common in the med school and biological sciences where the ambiguity is common than In other departments, especially where you might not know the person.

In the scheme of things this is not a big deal.

Everything you’ve mentioned plays a role. It has also worked well marketing-wise: In Germany, people take you more seriously; in the US it doesn’t matter, but a title is still more memorable.

I thought the title was just a declarative statement about javascript rather than the name of instructional material

Love the writing style. Concise, straight to the point, zero nonsense. Will consider getting the paperback.

I'm very much in awe of author's subject expertises & writhing skills.

I don't get it. The ebook is 34 USD. At amazon you get the printed version for 31 USD. What is the logic there?

> 🇺🇸 Amazon.com (USD) 🇬🇧 Amazon.co.uk (GBP)

What kind of letters is this? 🇬🇧 (copied) / GB / gb - same font, different letters. Why?

So few people understand prototypal inheritance.

e.g.: sometimes you can do Object.create(obj) instead of Object.clone(obj) if you just want to have a one-off object.


I'm not familiar with Substack. I found the ToC but I haven't found the content. It could use better structure. Hope that helps.

Heh, show me a patient JS dev ;)

I consider myself a patient developer, yet I don't have any patience for JavaScript's bullshit.

sort of my point . . .

Just what we need - more uncaring ECMA programmers putting out substandard, massively slow, non-native code...

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact