Eloquent JavaScript 4th edition (2024)

by vajdagabor • 2 years ago

1274 231 2 years ago

msoad• 2 years ago

This is the book that helped me really understand JavaScript. Really great content and I can't thank Marjin enough for putting this out there for free.

Also how this person is so productive? I really would love to read on how he manages his time and priorities.

dcre4• 2 years ago

This is my favorite book about JS, and I always recommend it to people. It occurs to me for the first time that the lack of TypeScript might be a problem, because if I’m making recommendations to someone learning, I am definitely going to recommend they write TS instead of JS. On the other hand it may actually be helpful to learn the concepts in this book without the additional syntax overhead of type annotations, plus the more webby content doesn’t really have much to do with types anyway.

OmarShehata• 2 years ago

I very much concur that it is better NOT to introduce TS when explaining JS fundamentals. I've seen smart engineers with a C++ background get tripped up on and very confused working with TS, because it's not clear to them what concepts are "language fundamentals" and what concepts are "the TS transpiler".

(Like expecting that just because you declared something as type X, that it guarantees at runtime it will always be type X, but it won't. You may get data from an API that _says_ it returns type X but the contents don't match. That can be valid code that compiles and has weird runtime behavior)

DarkNova64• 2 years ago

What helped me understand the Runtime behaviour of TS is to understand that TS doesn't actually have strong typing. If it was named "LintScript", its name would be much closer to the truth.

lost_womble• 2 years ago

Agree. I wish tools like zod/valibot were first class in typescript.

myvoiceismypass• 2 years ago

It is (or should be) common practice to parse/validate any external data you depend on. You should be doing this for Javascript too. I find that the library https://zod.dev/ is quite helpful for this

samtho4• 2 years ago

I've seen smart engineers with a C++ background get tripped up on and very confused working with TS, because it's not clear to them what concepts are "language fundamentals" and what concepts are "the TS transpiler".

This is exactly why I never recommend TypeScript to new developers.

A similar problem (that used to be worse) with people learning JavaScript is the lack of separation between JavaScript and the DOM + browser APIs. 10+ years ago, people have told me how much they hated JavaScript and when probed about it further, would admit that it’s actually the DOM or new/inconsistent browser APIs that have caused issued.

JS has a number of its own flaws and quirks, yes, but there are two fundamental issues that make it harder to approach as a new learner (as opposed to, to say, Python) are how tightly coupled it has historically been to it’s primarily application case and how high or low level is this language?

preommr• 2 years ago

I've seen smart engineers with a C++ background get tripped up on and very confused working with TS,

The idea that someone is good at another language so they'll automatically be good at another is a common misconception. In fact, they're likely to be worse because they're less likely to spend time trying to learn things from the ground up and less likely to write idiomatic code.

It's especially bad with js/ts because of it's popularity (so lots of new programmers that complain about how NaN doesn't equal itself), and because it's the defacto web language so lots of people are forced to use it as a secondary language that don't want to spend time learning it.

ayuhito• 2 years ago

I wholeheartedly agree. At most, I introduce JSDoc[1] to newer developers as standardising how parameters and whatnot are commented at least gets you better documentation and some safety without adding any TS knowledge overhead.

[1] https://jsdoc.app/

diggan4• 2 years ago

I am definitely going to recommend they write TS instead of JS

Why is that? If you want them to learn JS, teach/recommend them to learn JS?

Compile-to-JavaScript languages come and go, but JavaScript has remained. First learning vanilla JavaScript makes sense, and then add TS on top if you really have to. At the very least they'll be prepared for when TypeScript goes out of favor.

epolanski5• 2 years ago

Because TypeScript is the de facto standard way of writing JavaScript for most of the industry and it has killed all of the other compile-to-js languages.

The chances of it going out of favour are very slim, there's a giant ecosystem built on it and the language is very well loved by devs (should be second only to Rust).

Microsoft has 50 people on payroll working only on TS. Any competitor needs a gargantuan investment.

wk_end4• 2 years ago

TypeScript isn't really a "compile-to-JavaScript" language in the same way that, say, Rescript is. Modulo a few corner cases (e.g. enums) which are now considered anti-features, TypeScript has the exact same runtime semantics as JavaScript - you can (almost) convert TypeScript to JavaScript just by stripping away the type annotations (and, if various ECMAScript proposals go through, you won't even need to do even that).

This is both a curse and the secret behind its success - it's arguably not a separate language, but instead an annotation layer on top of the existing language for encoding and checking your static reasoning and assumptions.

dcre4• 2 years ago

I don't want them to "learn JS." Most likely the person in question is trying to write web applications, and I want them to learn what is most useful for that. After writing web applications for years without TypeScript and then for years with it, I cannot imagine going back. I can make complex refactors with very little worry. Thanks to type inference, most of the TypeScript code I write is indistinguishable from JavaScript, so the idea that learning TS takes away from learning JS is ridiculous. When I suggested that the extra syntax might be distracting at first, I meant for like... a week.

irrational3• 2 years ago

It is useful to know vanilla JS. Right now I am learning an integration platform that uses JS for its scripting language, but you cannot use TS.

synergy203• 2 years ago

ts-node with ts can do script the same as node with js? surprised why TS can not be used as it's 'safer' for scripting.

rglover• 2 years ago

It's better if they learn the core language and then graduate to TypeScript (if at all, as there's active discussion of adding type annotations to the core language [1]).

An anecdote: I was sold a similar story on CoffeeScript back in the day, stressed myself out learning it, only to discard it a couple years later. TS won't have an identical fate as its shepherded by Microsoft, but eventually it will go the way of the dodo (whereas core JS will still be humming along).

[1] https://youtu.be/SdV9Xy0E4CM?feature=shared&t=380

cdme• 2 years ago

This was the approach one of my first mentors recommended and it's served me well. Learn the core language and its features and then add tools/frameworks as needed. Lately it feels like we're teaching new devs popular frameworks and completely ignoring the fundamentals.

llmzero• 2 years ago

What's new in this edition?

begueradj2• 2 years ago

It should be mentioned in the "Introduction" but it seems your question is not covered there.

e12e• 2 years ago

Could've used better commit messages, but:

https://github.com/marijnh/Eloquent-JavaScript/compare/3rd_e...

llimllib• 2 years ago

you can see the differences on github: https://github.com/marijnh/Eloquent-JavaScript/compare/3rd_e...

From a quick browse:

- # for private properties

- ESM imports in node

- hasOwnProperty -> hasOwn (TIL: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)

- Math.pow -> **

- coverage of `function*` generators (https://eloquentjavascript.net/11_async.html#h-o+cFzGGhnz)

bewuethr• 2 years ago

Here's a diff without the first commit that changed all linebreaks: https://github.com/marijnh/Eloquent-JavaScript/compare/d8290...

greenie_beans2• 2 years ago

this book taught me javascript! great book, highly recommend it.

begueradj2• 2 years ago

I agree. Have you also read "JavaScript: The Good Parts" ?

greenie_beans2• 2 years ago

nope, looks like a deep cut and will fill in some knowledge gaps i have. thanks for the rec.

another good one for my learning was "secrets of the javascript ninja"

davidroetzel• 2 years ago

"JavaScript: The Good Parts" was a great and a very important book back in the day. I am sure it inspired many of the improvements JavaScript has seen since then. But as it has seen these improvements, and as they were many indeed, I am not sure the book is still as relevant as it once was. Or to put it differently: There are many more good parts to JS these days compared to when the book was released :)

ramesh31• 2 years ago

As others have stated, The Good Parts is no longer something I'd reccommend. It's more or less the K&R of JavaScript at this point. An interesting historical primer, but it would only serve to confuse a newcomer today, as all of the warts in the language discussed are ancient obsolete history.

svat9• 2 years ago

I love this book, even since its first edition. It's very clear even on elementary stuff, e.g. see the section on bindings/variables: https://eloquentjavascript.net/02_program_structure.html#h-l... — avoids the pitfall of thinking of variables as “boxes”.

I was trying to find what's new in the 4th edition, and following links from the author's website https://marijnhaverbeke.nl/ found this on Mastodon (https://mastodon.social/@marijn/112020092273623390):

The FOURTH EDITION of Eloquent JavaScript is now online, adjusted to the realities of 2024 and generally touched up.

DenverSWE• 2 years ago

Looks as if there will still be a paperback version released in the future as well for anyone that prefers that format.

I don't work in JS at all professionally but this book has intrigued me for a while at this point after seeing it recommended so often. I think I'll pick up a copy once the paperback is released.

ricardobeat4• 2 years ago

It's a great explanation, but I've never heard the term 'binding' used to describe variables. It's usually reserved to function binding or bridge APIs like the DOM.

The tricky thing is that "boxes" are the right abstraction for primitive values. After that you need to explain how references work, and that's pretty much the same 'tentacle' concept. This method spares the reader one step, but might cause confusion once they face problems that require that understanding.

pier252• 2 years ago

"binding" seems like a more casual term for memory pointer. I guess if people are just getting started with programming it make sense to simplify things a bit.

michaelcampbell• 2 years ago

"binding" is pretty standard terminology in some oldtimey languages; lisp, ML, etc.

jameshart• 2 years ago

1) the most common binding used in well written modern JavaScript is a const binding. It is by definition not a variable.

2) the ‘binding/tentacle’ metaphor works just fine for primitives and the ‘boxes’ model adds more complexity.

NlightNFotis3• 2 years ago

"binding" is a PLT term, denoting the association between a name and a value.

It's a higher level concept than the variable - a mutable binding is what people usually refer to as a variable, and an immutable binding is the correct term for what people refer to an "immutable variable" (an oxymoron, if you think about it).

svat9• 2 years ago

"Binding" is used thousands of times in the language standard, including for variables: https://tc39.es/ecma262/#sec-variable-statement -- that's my point, that this book is precise while being approachable to beginners.

And I dispute the claim that "boxes" are the right abstraction for anything in JS. (Boxes may work for primitive values, but nothing further.) Directly seeing names as bindings ("tentacles") not only skips the incorrect "boxes" step, but also causes no confusion or problems whatsoever at any point. (If you have an example, I'd be curious to see it.) (There are some differences in the language between primitive values and Object, but none of them are particularly helped treating variables as boxes AFAICT.)

arrowleaf• 2 years ago

The book is actually maintained on GitHub too, https://github.com/marijnh/Eloquent-JavaScript.

When I was just starting out I read this book and noticed a small mistake, I was really proud that one of my first contributions to any open source project was a PR to this repo.

svat9• 2 years ago

Thanks, that gives a way of seeing the diff between the third edition and the current (last commit 45 minutes ago): https://github.com/marijnh/Eloquent-JavaScript/compare/f8f00...

MikeTheGreat2• 2 years ago

I'm curious - could you expand on why it's a pitfall to think of variables as boxes?

svat9• 2 years ago

Because that's not how variables work in JavaScript/Python etc (though it may be fine for say C++ in the case of value types and copy constructors). For example:

I'm typing on phone so for a quick example:

    let a = [];
    let b = a;
    a.push(1);

and consider the value of b now (or the fact that we could write "const" above because the binding is constant, even though we mutate the value). Or see the equivalent for Python by Ned Batchelder, which has more examples and elaboration: https://nedbatchelder.com/text/names1.html

alyandon4• 2 years ago

Serious question - has Javascript the language evolved any features for handling integer math correctly so expressions like 2*57 aren't silently rounded? I realize that in most cases Javascriopt is "good enough" for useful work but I've seen even senior engineers get tripped up by Javascript's corner cases when it comes to its handling of integer vs float.

wk_end4• 2 years ago

There's BigInt [0]. Probably less useful for this specific case, but possibly useful as well, are typed integer arrays [1].

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

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

alyandon4• 2 years ago

Ah, very cool. Thanks.

throwaway632• 2 years ago

handling integer math correctly

JavaScript doesn't have integers. Everything is a float. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Although it has BigInt now.

alyandon4• 2 years ago

Yes, I'm aware that internally it is using floating point representation and that is one of the main reasons I avoid using it for anything math related. However, I am now aware that BigInt() exists so thanks for the link.

samtho4• 2 years ago

This is, in my opinion, the book to use to learn JavaScript at more than a surface level. The only other materials I recommend as much (but for a different level of learner) are the “You don’t know JavaScript” in-depth book series.

In 2015, I was consulting for a distance learning program, administered by a major California University, that wanted to replace their current textbook (one of those “Head First” O’Reilly books) with something that had a bit more meat but was very approachable. I immediately recommended this and it was fawned over by both the advisors and instructors. It was also the cheapest option they had in the running (even excluding the fact it can be read for free) as it was competing against traditional text books. One year later, students were polled on it and it was met with a lot of positivity as well.

Sn0wCoder2• 2 years ago

One hundred percent agree on both this book and the “You don’t know JavaScript”. Both are free (search Kyle Simpson GitHub). I ended up buying the YDKJ first edition paperbacks but see the second edition of all of them are done or a work in progress. EJs is the one I tell my students to start with as IMO is more of a programming book that just happens to us JS. I can tell the ones that read it (it’s optional) and the ones that do not. I do a few random chapters every year and learn something that I either missed or forgot I knew every time. I am mostly using TS these days but also enjoy vanilla JS for side projects and prototypes. Note the YDKJ books can come off as very ‘only my opinion is the right one’ kind of like JS the good parts but just look past that and absorb the content, what you do with it after that is up to you regardless of the author’s opinion.

synergy203• 2 years ago

YDKJ 2nd edition after first two parts the rest seems less actively worked on? hope the 2nd revision will be done soon.

shanusmagnus3• 2 years ago

Note the YDKJ books can come off as very ‘only my opinion is the right one’ kind of like JS the good parts

I got the same feeling and it's very off-putting. KS seems like a dick. It's ironic that so much of his dickishness seems to be reacting against what he takes as Doug Crockford's dickishness. Ah the irony.

memonkey• 2 years ago

If you want a video series that accomplishes a lot of the content in these books it's Will Sentance's Javascript: The Hard Parts.

willsentance• 2 years ago

Cheers Josh :)

pwb252• 2 years ago

yes, also javascript the good parts is really good(hehe) because it's more theoretical and there is not html or web stuff in it just the language

TehShrike• 2 years ago

How recently have you read it? I thought it was a worthwhile read when I first read it 12 years ago, but I picked it up to skim a couple years ago and was struck with how much of it was irrelevant for modern JS due to changes in the language spec.

mtalantikite• 2 years ago

I remember reading the first edition back in maybe 2011 when I decided I should sit down and actually learn JavaScript beyond the superficial grasp I had of it from working on web things (mainly via Rails at the time). What a great book, I learned so much from it at the time. For years after, whenever anyone told me they wanted to learn programming, I told them to pick up this book as a first introduction to it. Plus, it was available for free on his website.

I've gotten rid of lots of old programming books over the years, but I've held on to my first edition copy of Eloquent Javascript. Lots of thanks to Marijn for writing this!

iwsk2• 2 years ago

I don't think this is a good book for someone who wants to learn programming for the first time.

kabes2• 2 years ago

+1 for "You don't know js", it's a must read for any js programmer IMO.

I haven't read eloquent JS though, you say it's a different level of learner. Can you expand a bit? Is Eloquent for after "you don't know js" or vice-versa?

Edit: nevermind, reading the TOC of eloquent JS gave me a good enough idea

deprecative• 2 years ago

I get so jealous that people can absorb information via books as an adult. I can read the same chapter a hundred times and nothing sinks in.

I know this is off topic but do you, or anyone passing, have a system or tips for how y'all do this? I've got so many programming books but they only collect dust after I read through them without benefit.

redbell• 2 years ago

I second JavaScriptInfo as another great resource to learn JS: https://javascript.info/

neiesc• 2 years ago

I agree

m4tthumphrey• 2 years ago

Thank you for mentioning YDKJS. I hadn’t heard of it before and am in the beginning of my first proper JS project for about 10 years; man has the JS world changed. I have already skimmed the first few chapters and am already understanding it all very concisely. I will be reading this properly via GitHub for sure.

idk1• 2 years ago

If I put "You don’t know JavaScript" into Amazon I get approx 10 books at £20 each, is there a specific one / author I should look for, of even better and ISBN. Thanks!

samtho4• 2 years ago

There are 6 books, the author recommends reading them in an order:

https://github.com/getify/You-Dont-Know-JS?tab=readme-ov-fil...

If the second edition is not available, you can read the first edition, just be aware some small things may be slightly out of date.

z3t4• 2 years ago

Someone asked about integer support in JavaScript. JS now supports BigInt!

  >2**57
  144115188075855870
  >2n**57n
  144115188075855872n

ethagnawl• 2 years ago

That's news to me!

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

alyandon4• 2 years ago

Yes, I was asking about that and I'm very happy to see this exists now.

williamstein• 2 years ago

And in some JavaScript engines (eg V8) bigint multiplication is asymptotically fast, unlike say the default CPython. It’s a very pleasant surprise if you happen to be a number theorist (say).

csjh• 2 years ago

How do you mean? CPython uses karatsuba's for large numbers which should be asymptotically fast

https://github.com/python/cpython/blob/d864b0094f9875c5613cb...

bovermyer• 2 years ago

Oh thank god.

I've been having to do some hacky things to represent numbers on an astronomical scale for my star system/planet generators.

veggieWHITES• 2 years ago

The field of programming is young and still developing rapidly, and it is varied enough to have room for wildly different approaches.

This was an interesting line of thought to digest. He's right, of course. Programming is probably still in it's infancy.

Studying and learning about programming however, can make you believe it's some ancient art mastered by the giants of our recent past, the perfection of which is never to be surpassed again.

tithos• 2 years ago

https://arc.net/boost/3098D5E3-F164-478B-9586-077889192460

The 'Eloquent JavaScript 4th edition (2024)' in Dark Mode

wes-k• 2 years ago

For those that don't know the author, Marijn Haverbeke is the creator of CodeMirror (code editor) and later ProseMirror (text editor).

https://codemirror.net/

https://prosemirror.net/

felideon• 2 years ago

I'll always know him as the author of Postmodern, an impressive CL library for PostgreSQL: https://marijnhaverbeke.nl/postmodern/

jamager• 2 years ago

Prosemirror user, it is fantastic. Didn't know Marijn was so prolific, all with free/open source projects. Wonder how can make a living...

jmkni• 2 years ago

Chapter 11 on async is particularly good, I still get confused by async/promises sometimes in Javascript - https://eloquentjavascript.net/11_async.html

felipefar• 2 years ago

Part of the force of this book comes from its explanation of fundamentals of computing, and how it relates to javascript. Another part is due to how interesting are the projects that it proposes that the reader build. I don't even like programming in javascript but was drawn to read the book.

NlightNFotis3• 2 years ago

Fancy seeing this here, some days after finishing the third version :)

I'm also glad to see the asynchronous programming chapter significantly reworked - it was materially weaker than the rest of the book because of some weird analogies involving crows and their nests that didn't seem to make any sort of sense to me.

The third edition also gave me the impression that it was a reasonable book to learn JS and the DOM (and a sprinkle of Node.js, for good measure), but that it was a book aimed primarily at experienced people who were transitioning to JS and the web - not beginners (despite the book's efforts at claiming suitability for beginner programmers).

Jerrrry• 2 years ago

book because of some weird analogies involving crows and their nests that didn't seem to make any sort of sense to me.

I am glad I am not the only one. I believe he over-abstracted it to it's own detriment.

I went to purchase a paperback earlier this week. Now I will wait for this one to hit print.

m1keil• 2 years ago

Ah! I vaguely remember rage quitting over the crows but didn't remember which book was it. I should give this another try then.

ginkgotree• 2 years ago

The best JavaScript book out there, IMHO

synergy203• 2 years ago

Great book, looking for some info about main changes from 3rd edition but did not find it.

ibobev• 2 years ago

I'm currently going through a hard copy of the book's third edition. But I'm wondering whether the description of the language in the book is detailed enough. Could you share some opinions on whether it will be good to go through some other JavaScript books after it? I'm considering going through "JavaScript: The Definitive Guide"[1] or "The Modern JavaScript Tutorial"[2] after it.

[1] https://www.amazon.com/JavaScript-Definitive-Most-Used-Progr...

[2] https://javascript.info/

XeO3• 2 years ago

"JavaScript: The Definitive Guide" does go deeper, with thorough examples in all the topics mentioned in the index. It also provides examples of static types using Flow instead of TypeScript.

ravenstine3• 2 years ago

I don't mean to throw shade on the whole book, but I don't think the section on errors takes things in the right direction.

A distinction should be made between errors and exceptions. In JavaScript and many languages, we conflate the two and use exception handling as logic flow control. In my experience, this can end up being a headache and encourage unnecessarily weird structuring of code.

Look at this example from the page on errors:

---

function getAccount() {

  let accountName = prompt("Enter an account name");

  if (!Object.hasOwn(accounts, accountName)) {

    throw new Error(`No such account: ${accountName}`);

  }

  return accountName;

}

---

The possibility that a user will enter a account name that doesn't exist is not an exception, but we are treating it like one in this case. In order to handle this exception when getAccount is called, we have to wrap it or some higher level scope in a try-block and then regex-match the error message if we want to handle it differently from other errors.

You might be saying "it's just an example", but there's plenty of production code in the wild that is written this way. Maybe this could be improved by subclassing Error, but now you're having to manage a bunch of clutter and using object-oriented features as a way to reliably determine what kind of exception you're dealing with.

I find this pattern to be preferable:

---

const ACCOUNT_NOT_FOUND_ERROR_CODE = 1;

function getAccount() {

  let accountName = prompt("Enter an account name");

  if (!Object.hasOwn(accounts, accountName)) {

    return {

      accountName: null,

      error: {

        code: ACCOUNT_NOT_FOUND_ERROR_CODE,

        message: `No such account: ${accountName}`,

      }

    };

  }

  return { accountName, error: null };

}

---

Then we can call the function like this:

---

const { accountName, error } = getAccount();

if (error) {

  if (error.code === ACCOUNT_NOT_FOUND_ERROR_CODE) {

    errorModalService.show(error.message);

  }

} else {

  // do something with the account name

}

---

No doubt, you may still want to catch exceptions at a higher level scope, but at the nice thing here is that exceptions (almost) always represent actual unexpected conditions that aren't being handled properly while return values with error codes represent expected conditions and can be handled like any other logic in your code. It also reduces any ambiguity of how an error should be handled but without subclassing. An error can even contain more information than just a message if you want it to.

Also, if you really want to ignore an error for some reason, then you can just pretend that the error doesn't exist. No need to use a try-catch where the catch-block is a no-op.

I wish we'd encourage this sort of pattern, but maybe that's one of many pipe dreams of mine.

svachalek2• 2 years ago

In other languages like Java this can work because of checked exceptions (can work, I know there are a lot of mediocre devs who don't know what to do with checked exceptions but that's another issue). But in JS this is a terrible way to deal with any problem that can be handled.

Exoristos• 2 years ago

1. Exceptions can have codes, too, you know, and often do. 2. In the example, the exception is meant to bubble up all the way to the consumer. Different consumers can then handle as they see fit, even just displaying the exception message to the user.

ravenstine3• 2 years ago

Yes, exceptions can have codes. As far as I have experienced, their error instances don't do anything better than a plain object, and a non-exception error object can more clearly take a wide variety of shapes. It also limits potential confusion between errors or exceptions raised by your code and that of some dependency.

It is true that exceptions "bubble", and plenty of developers take advantage of that behavior. In my opinion, it is not helpful for errors that are expected to happen as part of normal application behavior. Bubbling of errors creates a sense of logical indirection. Errors as return values communicate that likely nothing " wrong" actually happened. Good communication through code reduces the amount of time developers spend using the wrong assumptions when debugging.

There is also no reason why errors in a return value can't be returned by the caller. When you learn to love objects/hashes as return values, you can get the same benefits of bubbling but with a more clear path to follow when getting a picture of where a value is coming from and why.

In the case of actual exceptions, like accessing a property on undefined, an error being thrown is appropriate because, like you say, it can be bubbled up. The nice thing about reserving exceptions for this sort of thing is you might get away with a single try-catch at the highest scope and have a single straight forward error modal for when an unexpected problem occurs. Then you can otherwise implement errors in your code without the possibility that they will escape through bubbling and trigger behavior that is not immediately obvious when following the path of execution.

This is not to say that the tradition of using errors and try-catch for normal application control flow is inherently bad. Its just another tool. I do subjectively believe they are counter productive when used that way, and encourage others to try something like my approach. I think we would benefit by making it a standard practice.

brailsafe2• 2 years ago

I'd agree, but incidentally I've also been extracting string labels into some higher level, such as a constant or message creator function that looks up the message by it's code in some dictionary. It helps with readability, particularly in modern view libraries, to just have all your labels in one place and not have to scan the JSX or HTML for the string literals, and likewise all modifications will produce more concise diffs, testing could be easier if you're doing string matching, localization is more manageable with fewer scattered external dependencies on translation hooks or w/e

rofrol• 2 years ago

like Result in Rust

ravenstine3• 2 years ago

Haven't even looked at Rust code until just now, but yes, that looks like a more formalized version of this idea. Interesting!

justanotheratom2• 2 years ago

What if one is using TypeScript?

brink• 2 years ago

The rules still apply.

mixmastamyk6• 2 years ago

I have Zakas' Professional JavaScript for Web Developers and ECMAS 6 update. Was very happy with them (easy to read) but both are getting long in the tooth and the author seems to have lost interest in updates.

How does this one compare as an all-in-one? Being up to date is a win, but I'm wondering about the quality of the writing.

justanotheratom2• 2 years ago

I wonder if such high quality free books are already fed to LLMs during training?

0xCMP• 2 years ago

They're open source and easily accessible, so I would practically guarantee some/most of them are using it and other open source books.

Given so many are just on Github and very well known/linked-to I doubt they even put any special effort into getting these specific resources.

lazysalmon35• 2 years ago

When is the print book coming ?

panphora• 2 years ago

Paper book will take a while longer.

According to the author, Marijn Haverbeke.

https://mastodon.social/@marijn/112020092273623390

illegalsmile• 2 years ago

test

aydoubleyou• 2 years ago

I don't consider myself a good programmer. I struggled throughout my youth to grasp even the basics. This book pointed me in the right direction. Can't recommend it enough.

culopatin• 2 years ago

And how are you doing today?

prudentpomelo• 2 years ago

Definitely one of my favorites. It helped me level up when I was learning Javascript but also helped me understand how to be a better programmer.

TheRealPomax• 2 years ago

The one odd thing in it is that it still claims SVG markup needs a namespace. Which it doesn't, SVG became part of the HTML5 spec and emphatically should _not_ use namespaces when used as "just another element" inside an HTML document.

(even though you do need a namespace when creating svg elements through createElementNS, both "of course" and "unfortunately", and of course you need namespaces if you're creating an actual stand-alone SVG document)

_obviously• 2 years ago

Sounds like a joke, an oxymoron.

coding-saints• 2 years ago

Great book

slow_typist• 2 years ago

How does Eloquent JavaScript compare with Horstmann‘s JavaScript for the Impatient?

no_wizard• 2 years ago

Its not for the impatient, its a deeper dive than that.

degun• 2 years ago

This is what really taught me JavaScript.

jimhefferon• 2 years ago

Does the author ever talk about why he is publishing a free version along with a more traditional paper version?

marijn3• 2 years ago

Makes it available to more people. Also probably helps paper books sales more than it hurts them, through exposure.

radicalriddler• 2 years ago

Frustrating that the online version uses weird format for it's code blocks, which leads reader view (Mozilla Readability) to not put code in a <pre> tag or a <code> tag and leaves it as plain text.

marijn3• 2 years ago

How is a `<pre>` tag for code blocks a 'weird format'?

looshch2• 2 years ago

does anyone know where can i get the list of changes compared with the previous edition?

lioeters• 2 years ago

From a comment above thread, here's the diff of current state against the 3rd edition: https://github.com/marijnh/Eloquent-JavaScript/compare/f8f00...

looshch2• 2 years ago

many thanks, lioeters!

gassiss• 2 years ago

Seconding the sentiment on this thread, I used this book to learn JS 5 years ago, and it's awesome. I've never seen another resource as good. YDKJS is more of an advanced treatment. If you're a beginner it feels academic, while Eloquent JS is very practical and approachable.

jslakro• 2 years ago

First jquery, then React, now this book reaches a new version. Good times for JS

jgord• 2 years ago

Looks pretty solid.

CH 5 : "Higher Order Functions" seems a nice segway into one of my favorite, lesser known js util libraries Ramda.js

cradle• 2 years ago

Where is the physical copy of the 4th edition? I can't find it.

rnewme• 2 years ago

Not yet, soon. It is in the making

pojzon• 2 years ago

To learn js I recommend „WAT” tutorial.

Nothing changes in last few years. We still go in with what we incorrectly assumed at the start.

richrichie2• 2 years ago

Every now and then, someone comes up with a new way to circumvent the limitations of a browser and do something harmful, ranging from leaking minor private information to taking over the whole machine that the browser runs on. The browser developers respond by fixing the hole, and all is well again—until the next problem is discovered, and hopefully publicized, rather than secretly exploited by some government agency or criminal organisation.

This is from the chapter on HTML and JS (emphasis mine). It is funny to see how govt agencies and criminal organisations are mentioned in the same breath. How did we end up here?

tracker1• 2 years ago

Like that this now includes a chapter on Node. I think it would be nice to see a follow-up book in a similar style that covers a bit more with Node, Deno and Bun.

I really like the Deno approach so far. I prefer TS mostly these days as well as the esm stroke modules. I think node just made usage harder in their approach. I understand why, I still disagree on the solution.

ArcMex• 2 years ago

In my interactions with Marijn, he’s been very responsive. I’m happy to see this release and wish him continued success.

I learned JS from the second edition.

Incredible resource.

isquaredr• 2 years ago

Any suggestions from the community on the best way to consume this site as an audio book? I know I could scrape and feed into a text-to-speech library but was wondering: is there is anything off-the-shelf?

boringuser26• 2 years ago

This book took me from having nothing -- literally being a political science major grocery store employee -- to making 2xx,xxx YOY.

It was challenging and made me question whether or not I had it in me to code. Turns out, I could, and, vis-a-vis my peers, exceptionally well.

Well, I took me, but this book was my first real introduction to computer science.

Funnily enough, I didn't then and don't now personally care for the author (he seems untalented as a teacher), but I feel he accidentally made a good resource in his hubris.

marijn3• 2 years ago

You're welcome

boringuser26• 2 years ago

Thumbs up emoji.

mixmastamyk6• 2 years ago

Where are you making $200k+ with limited experience and do you need a senior partner? :-D

boringuser26• 2 years ago

6 years is sufficient experience, and we're good, thanks!

noname120• 2 years ago

My go-to JavaScript book will always remain “JavaScript for impatient programmers”[1], a 639-page book written by Dr. Axel, PhD.

It's quite complete and detailed. But as if it wasn't enough the author wrote a second (smaller book) named “Deep JavaScript: Theory and techniques”[2].

Both are free to read online!

[1] https://exploringjs.com/impatient-js/

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

jrvarela56• 2 years ago

I love the web version has a feature to link back to any given paragraph. I hadn't noticed this in any other site and found it delightful.

Eloquent JavaScript 4th edition (2024)

Related Stories