
Eloquent JavaScript 3rd Edition (2018) - quazar
https://eloquentjavascript.net/
======
neovive
I'm actually working through this book right now. I've been away from front-
end coding for a bit and my weekend/evening project over the next month is to
brush up on modern Javascript and ReactJS. This book is very well written and
great re-introduction to JS/programming fundamentals.

For those interested--Besides this book, my current learning plan includes:
Javascript 30 by WesBos Exploring ES6
[[http://exploringjs.com/es6/](http://exploringjs.com/es6/)] Learning
React-2nd Edition on O'Reilly Learning The Beginners Guide to React on Egghead
Data Structures and Algorithms in JavaScript on Egghead.

I also used Kent C. Dodds' excellent "JavaScript to Know for React" article as
an outline.

~~~
ggregoire
For React, why not just read the docs? You don't really need anything else.

~~~
karimdxy
Yes. I 100% agree with you. For whatever reason most people almost alway look
elsewhere for the thing while it’s right in front of them.

~~~
tvanantwerp
The React docs are excellent. But many (if not most) other projects have
woefully under-developed docs that offer confusion more than clarity. I
wouldn't blame anyone for assuming that the docs are _not_ the place to start
for learning something new.

~~~
nkhodyunya
Nowadays if you face a tool with sparse official documentation or with total
absence of it, it's probably better to find another tool or be prepared to
learn from the source code.

~~~
karimdxy
Exactly. That’s one of the heuristic I use nowadays to filter things.

Does it have a good documentation?

Yes? Cool. I dive in head first.

No? Hard pass.

------
smlckz
JavaScript is very expressive and powerful language. Maybe hard to learn. The
prototypal inheritence and 'this' were confusing to me and took much time to
understand those.

Then I learnt that prototypal inheritance is a superset of ''class''ical
inheritance [1] as well as this [2]. Hmm.

With Reflect, Proxy etc. you have great metaprogramming capabilities that make
this language much powerful.

Still, there are some (many?) edge/corner cases and unfixable bugs (aka
features) that the language is stuck with for the sake of backwards
compatibility and developers have to learn these. (The most famous of these
might be typeof null === "object")

When I look at the amount of features added to the language specification,
sometimes it seems like it is going to become another incarnation of the C++
specification.

I still like its expressiveness and power, but if it becomes another C++ in
future, I have to look somewhere else. (TypeScript maybe.)

[1]: [https://aaditmshah.github.io/why-prototypal-inheritance-
matt...](https://aaditmshah.github.io/why-prototypal-inheritance-matters/)
[2]:
[https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent](https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent)
and
[https://www.crockford.com/javascript/private.html](https://www.crockford.com/javascript/private.html)

~~~
kazinator
I'm convinced that prototype object systems represent a poor set of
requirements.

Those requirements are chosen because they lead to ease of implementation:
prototype objects are the quickest and dirtiest way to enhance an interpreter
such that programs can be written in it that are discernibly OOP-ish.

They don't represent a set of requirements that amount to a good OOP system.

~~~
smlckz
Read the accepted answer to this question:
[https://stackoverflow.com/questions/2800964/benefits-of-
prot...](https://stackoverflow.com/questions/2800964/benefits-of-prototypal-
inheritance-over-classical)

~~~
searchableguy
> @s̮̦̩e̝͓c̮͔̞ṛ̖̖e̬̣̦t̸͉̥̳̼ It's been a while since I wrote this answer. My
> views have changed since I wrote it. Now, I believe that inheritance, both
> classical and prototypal, are bad and should be avoided at all costs.
> There's never a good reason to use inheritance. If you're writing object-
> oriented code then you should always prefer composition over inheritance.
> Even better, don't write object-oriented code. Embrace functional
> programming.

Author finally opened his eyes.

~~~
kazinator
> _There 's never a good reason to use inheritance._

Looks rather like eyes closing to me.

~~~
skipants
Definitely agree with you. as much as I hate inheritance... _never_ using it
seems like a big leap.

~~~
kazinator
I hate being locked to single inheritance. Like, okay, we got the properties
of _foo_ ; so that means we now absolutely cannot be a _bar_. It bugs me even
if there is no plan to do that in the current program. By inheriting from
_foo_ , I'm enforcing the decision that this cannot be a _bar_ , which could
cause a problem to a future maintainer (maybe myself in six months).

Java has single inheritance, which sucks; but it has multiple inheritance of
interfaces at least, and good luck doing any serious work in Java without that
being involved. (That is also designed that way in order to pander to
implementation ease and certain run-time efficiencies; but has been turned
into fallacious arguments like "multiple inheritance is bad ... unless it's
interface inheritance").

Oh, and one problem with this prototype business is that in fact it is single
inheritance (in the typical incarnations, at least; am I invoking a strawman)?
It seems inescapable that supporting multiple inheritance under the prototype
paradigm requires that we make a single new object out of two or more existing
objects. But if objects are effectively just bags of properties (a.k.a. hash
tables) it does seem easily doable. Make new empty object, stuff with
properties of all argument objects, season to taste, return.

------
warent
I would consider myself pretty close to an expert with JavaScript. I've been
using it for 5 years professionally, currently use ES2020. Fairly familiar
with Node 12, V8, etc. But I'm always worried about those situations where you
dont know what you dont know. This might sound strange, but would anyone
recommend any reading material or blogs for someone at my level?

~~~
hoorayimhelping
I've been using JavaScript professionally for about 12 years.

You're going to have to look for talks and really technical posts. Consider
whitepapers and source code for JavaScript engines at this point. You'll
probably want to start reading up on the things attached to JavaScript, rather
than the language itself. Browser rendering, event loop, V8 things, garbage
collection, etc.

I'm sure you've seen it, but things like this:
[https://www.youtube.com/watch?v=8aGhZQkoFbQ](https://www.youtube.com/watch?v=8aGhZQkoFbQ),
and this:
[https://www.youtube.com/watch?v=SmE4OwHztCc](https://www.youtube.com/watch?v=SmE4OwHztCc)

It might be time for you to start writing what you know about JavaScript.

~~~
nujabe
I definitely wouldn't consider the first video 'advanced' material (an
excellent talk btw), JavaScript event loop is something beginners should know
about and intermediate developers know very well.

~~~
azangru
Ah, but do they know where in the event loop, for example, "microtasks" get
executed as opposed to... I forget.. tasks? In other words, how execution of
promises is different from the execution of setTimeout?

------
varrock
Great read, though his writing style is less intuitive if you are fairly new
to JavaScript and trying to grasp some of its concepts. For example, in his
reduce function [0] example, he names his variable "current" to bind the
accumulated value the reduce function is going to eventually return. That is a
totally fair name, but I don't know if it really "clicks" if you were reading
over this for the first time. I think it would be faster to grasp the reduce
function's purpose if it was simply named "accumulated" or something alike,
especially when this snippet is advertising the idea of higher order functions
and callbacks.

Little things like this I am nit-picky about, but overall, great book.

[0]
[https://eloquentjavascript.net/05_higher_order.html#h_fx3e34...](https://eloquentjavascript.net/05_higher_order.html#h_fx3e34kT/k)

------
mrwww
We used EJS in our basic programming courses in my CS program and it was a
great book. Loved the exersices you could try directly in the book!

I now program JS for a living so i guess the book also really worked. Thank
you for the third edition!

------
wdb
I am unable to find out what has changed between editions

~~~
18nleung
I learned JS with this book back when it was ES5 - looks like the new edition
is updated for ES6

~~~
Kwantuum
ES6 came out 5 years ago

------
chrischen
Does anyone have a book recommendation (free or paid) that is modern and up-
to-date, preferably regarding typescript, that talks about best practices and
patterns for large-scale project design and code structure?

For example, a book that could go into details of code practices at companies
like Airbnb, Facebook, or Google.

~~~
taylorlapeyre
Typescript is relatively new, and I think a lot of those companies are still
trying new things and experimenting with what works. I expect that we will see
more refined content and books about TS-at-scale in the near future though.

However, for those looking for a great way to learn Typescript from a
beginner's perspective I can fully recommend Execute Program[1].

[1]: [https://www.executeprogram.com/](https://www.executeprogram.com/)

~~~
chrischen
At the speed of javascript though, it's pretty mature now. When I tried
searching on Amazon I was getting back $30+ dollar ebooks with chapters on how
to use Gulp (superseded by webpack or babel)...

------
BenoitEssiambre
I've been toying with the idea of promise free async/await lately. I'm
interested in feedback anyone would have.

[https://github.com/bessiambre/casync](https://github.com/bessiambre/casync)

~~~
fenwick67
I have avoided yield() and generators like the plague because they're hard to
read and I've never seen them used except in examples explaining how they
work. Yield feels like recursion - a neat trick for some corner cases but
generally unnecessary.

~~~
galaxyLogic
JavaScript syntax for generators is clunky no doubt. But they let you do some
things more naturally than anything else in JavaScript. They keep track of
state "implicitly" you don't have to do an assignment to 'save a state", you
just yield and your state is remembered.

I found generators useful for implementing my home-brew parsers. Parsers must
try out all possible combinations of possible syntactic elements before they
can say that parse failed. Generators are a good tool for that

~~~
alcover
> Parser in JS

Insteresting ! Would you mind sharing how you did ?

~~~
galaxyLogic
The basic idea is that a generator yields one potential parse of a section of
input-string. The caller continues checking the rest of the string but if it
fails to find all expected syntactic elements it will go back to the generator
basically asking it: Your previous suggestion did not work out, can you give
me another possibility?

------
tracer4201
As someone who hasn’t done much JavaScript since AngularJS in 2014/2015, what
is the current state of JS like?

I see there’s Angular (not AngularJS that I worked with), React, and some
other frameworks. I see there are all kinds of bundlers and plug ins for these
things.

When I was doing AngularJS, I’d just link to a few dependencies manually from
a CDN. Looks like now there’s a bunch more complexity and package management
for front end dependencies.

It feels like FAR more complexity, but I’m not sure what has been gained. I
also don’t know that much, so would love to learn perspectives here from
people actively developing in this space.

~~~
ridicter
If you're looking for a fully featured framework, Angular is a joy to work
with. React is great too, but the configuration overhead is enormous due to
the fact that it's mainly a view library. I realize you are pining for the
days when you just pasted a CDN link in your index.html, but while those use
cases still exist, for the most part users are demanding more native-like web
experiences, which requires a bit more complexity.

One of the main strengths (and according to some, weakness) of Angular is that
it has everything you might need to create a full featured SPA out of the box,
and it's all tightly orchestrated by the Angular CLI. Creating a component or
a service is a simple command, and many third party packages leverage the CLI
(Angular Schematics) to install and configure themselves in your codebase.
Core packages--such as such as forms, router, angular material--are all high
quality (by Google), updated together, and work cohesively with each other.
That means updating even major versions of Angular is an easy `ng update`
command. For me, the minimal configuration overhead is a BFD, as I plain hate
that stuff.

The fact that Typescript has been a first class citizen of Angular from its
outset makes development pretty enjoyable. I'm so used to exploring APIs using
intellisense, leveraging types to figure out what data types can be passed in
functions, relying heavily on auto-complete/auto-import to pick up my pieces
and finish typing a word for me and importing the corresponding library while
I keep going.

Granted, there is a significant learning curve. But once you get over the
initial learning curve, you become incredibly productive. Arguably, the
learning curve in other frameworks is worse, given that you have to research
what libraries to use (e.g., which forms library, with its own set of
conventions), configure it, and make sure it plays nice with the other
patchwork of libraries.

------
fizixer
Can anyone recommend reading for the web-related Javascript "API" so that when
Javascript is used in the form of generated code, e.g., through asm.js, the
"API" can be used by the "generating program" without the need to learn all of
Javascript.

Essentially so you could do HTML/CSS/some-other-language (using asm.js,
emscripten, or some similar technology) instead of HTML/CSS/JS.

------
drongoking
Is this worth buying/borrowing if you already know programming languages but
not Javascript? Or is there a better approach?

~~~
Scarbutt
IMO, no. It has too much ceremony to demonstrate concepts. It's for absolute
beginners.

~~~
sixQuarks
Definitely NOT recommended for absolute beginners. I tried reading this as one
of my first programming books and it confused the hell out of me. There are
much better introductory books/courses - my recommendation is "Watch and Code
- Practical Javascript" if you are an absolute beginner and want to learn
javascript.

[https://watchandcode.com/p/practical-
javascript](https://watchandcode.com/p/practical-javascript)

Eloquent Javascript is a good book now that I know more about Javascript, but
please NEVER EVER recommend it as the first book for an absolute beginner.

~~~
terrycody
marked this,thx, btw, I always want to choose head first series to be my 1st
book, what do ya think compare with eloquent JS for absolute beginner?

~~~
sixQuarks
I skimmed through head first, it seems pretty good but similar to a lot of
other books. The watch and code course is different and I just think it’s so
on point for the absolute beginner, or at least how I like to learn.

With 20/20 hindsight, what I wish I had done is read through or watch one or
two courses without any pressure, just get familiar with the topic, and don’t
worry if I don’t understand things.

things start clicking into place after you’re exposed to this stuff a few
times. My mistake was that I wanted to understand everything and didn’t want
to skip ahead if I didn’t.

------
mesaframe
I read this book and found that explanations of quite a number of topics were
misleading.

~~~
vga805
Do you have examples of this? Perhaps they could be clarified in errata, or
future versions.

~~~
mesaframe
Are you the author?

I'll definitely give it a re-read and update.

------
htatche
There is an equivalent for Ruby too in case you're interested.

~~~
marijn
That's by a different author with no connection to this book, though, so
calling it equivalent is misleading.

------
markthethomas
this. is. awesome. SO glad this book is being kept up to date

------
johnchristopher
Is there an equivalent for php?

------
0xff00ffee
I always skip to the async part of JS text because explaining it is a bit like
handing a shotgun to a five year old. I think the folks over at risingstack
have the best explanations, IMHO.

I'm surprised they attempted timeouts in promises with so little text, that's
actually pretty dangerous pattern because it glosses over the complexity in
actually stopping an in-flight promise. It is VERY easy to end up with
hundreds of thousands of unresolved promises with their pattern. Dangerous!

There is a great repo on this issue.... aand I can't for the life of me find
it. Basically there's a github project that uses generators and passes an atom
down through the call stack to ensure everything below the race promise is
aware that it is being halted. And even that doesn't handle all the nuances of
this pattern.

And if anyone knows what github repo I'm talking about, I'll give you ... 50
DKP?

~~~
galaxyLogic
I used to use more "Promises" but now I mostly code with plain callbacks if
possible. It is just simpler, less thinking needed. I spend that thinking-
budget on other things.

One thing that is tricky with async is that nobody tells you if the async
function never does what it should. I wish they would add some more built-in
support for that in the next JS version.

Promises hold promise (pun intended) but they are a bit too complicated for my
brain.

~~~
BenoitEssiambre
I also find promises problematic. I do like async/await though, except for the
fact that it relies on promises.

I've been toying with the idea of a promise free async/await implementation
lately. I'm interested in feedback anyone would have.

[https://github.com/bessiambre/casync](https://github.com/bessiambre/casync)

~~~
galaxyLogic
Very interesting. I just don't have time to try it out right now.

Perhaps if you create and publish a simple comparison solving a given problem
with Promises vs. CaSync it would show that CaSync takes much less code?

That could convince more people to take the time to try it out.

~~~
BenoitEssiambre
I'm not sure it's much less code. Especially that async/await is integrated
into the language now. It's less state, less corner cases, more encapsulation
and better performance.

I'm thinking of trying (if I have time) to build a babel transpiler plug-in so
you could use it with keywords like async/await instead of explicitly wrapping
generator functions. I think the syntax would end up very simple.

------
ternaryoperator
This is from 2018. The title of the post should be updated.

~~~
wyclif
Yeah, people are going to be tempted to think this is brand new without the
date of publication.

------
shanghaikid
I really like the first edition...

------
kevindeasis
Here are the things that I really really hate about javascript:

I find javascript really hard and annoying, even if I have enough experience
with JS that lets me build a basic react framework, I still find it hard to
use.

On top of that, getting javascript jobs is harder compared to other
programming languages. IE: you need 7 years of experience for a company at the
same level where they only need 1 year of IOS/Android experience.

You always have to be keep up to date. The popular libraries that you can use
changes so fast, and sometimes they don't even work.

Javascript gets a lot of disrespect from beginner engineers. Something about
doing frontend work, isn't hard and it isn't software engineering in their
perspective

There are so too many ways to do the same thing, unlike something like lets
say golang

You always have to learn more than javascript to compete with other javascript
developers. IE: dev ops, backend, database, sre, ux design

~~~
ausjke
I'm sure you will be downvoted as hell because you're critic and not upbeat,
HN just likes everyone saying good words all the time, i.e. stay politically
positive. However I strongly believe critic is more meaningful most of the
time as long as it does not have bad intention, thus I upvote you.

JS is indeed hard, learning vuejs for the sake of 'it's simpler than react'
right now.

~~~
hombre_fatal
Client dev was always hard. People just mistake that for Javascript because
they don't have any experience building clients.

For example, I'd say JS/React is vastly easier than learning Cocoa/UIKit.
Writing GUI code that runs on N user devices is harder than writing headless
code running on a single server.

Btw, if they're getting downvoted, it's because "oh, Javascript is in the
title? time for me to complain about it like people do in every JS-related HN
thread!" is a tired HN comment.

~~~
dgentile
I disagree. Headless code on a single server can still be very difficult. For
instance, nginx, mariadb, etc, which allow the frontend to function well, are
difficult to write. You have to deal with multiple threads, search algorithms,
handling tcp/udp requests, and optimizing all of that so it isn't dead slow.
Whereas writing GUI in JS/React involves less "computer science" complexity
and more compatibility complexity-dealing with things like, what is the
screen-size, the locale, etc.

On the note of the HN's perceived hatred of JS, I think its because Javascript
has tried to do too many things. Despite its quirks I like Javascript in the
context of the web browser, but what I dislike it that it exists in
applications and on the server side. The Atom editor should not take up 200 MB
and take forever to boot. But it does because instead of taking the time (like
sublime text) to write a rockstar system code, they instead used electron. The
feeling I get sometimes is that JS developers want to program the same way
they do in the browser, everywhere.

~~~
omniscient_oce
Are there easy ways to write GUIs without Electron that still can use HTML+CSS
for layout and design that allow you to have an identical experience on
Windows/MacOS/Linux? I think this is the main thing webdev-land people like
(myself included). Also, there are so many npm libraries to handle stuff for
you that staying within that ecosystem is enticing.

~~~
dgentile
My point was more along the lines of the code bloat that comes from
essentially emulating a web browser on system, when in reality you can write
much faster code in C/C++ or even C#/Java. But, GUI design for applications
can be a nightmare, with QT on the one hand versus fragmented Cocoa/Windows
Whatever in C#.

I think Electron was the webdev community's response to this, and we really
haven't gotten one on the app/systems developer side besides QT.

Or to rephrase, using Electron to "emulate" a web browser is cross-platform
from the perspective of the electron user, while most other gui-ing solutions
in C/C++, are not necessarily cross-platform, and therefore this leads to
different set of challenges.

