Chapter 11 on async is particularly good, I still get confused by async/promises sometimes in Javascript - https://eloquentjavascript.net/11_async.html
Eloquent JavaScript 4th edition (2024)
61–70 of 249 posts
Re: Eloquent JavaScript 4th edition (2024)
#62What's new in this edition?
It should be mentioned in the "Introduction" but it seems your question is not covered there.
Could've used better commit messages, but:
https://github.com/marijnh/Eloquent-JavaScript/compare/3rd_e...
Re: Eloquent JavaScript 4th edition (2024)
#63Part 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.
Re: Eloquent JavaScript 4th edition (2024)
#64Fancy 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).
Re: Eloquent JavaScript 4th edition (2024)
#65This 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, pl…
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 t…
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.
Re: Eloquent JavaScript 4th edition (2024)
#66The best JavaScript book out there, IMHO
Re: Eloquent JavaScript 4th edition (2024)
#67This 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…
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.
Re: Eloquent JavaScript 4th edition (2024)
#68I 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://masto…
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…
"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).
Re: Eloquent JavaScript 4th edition (2024)
#69What's new in this edition?
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)
Re: Eloquent JavaScript 4th edition (2024)
#70Earlier quoted context omitted.
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.
This statement is quite questionable starting from the fact that there is no definition for what strong typing is. Care to provide what you mean? Strict TS won't compile pretty much any type-unsafe operation. It's not perfect, the standard libraries are a bit too unsafe type wise, exceptions are untyped and need Either/Result-like data types to be handled but it's an extremely powerful language if you know it and it'…
If you are in a completely self-defined world, then yes you can trust the compiler. But I once built a react component which was called from library code and it simply did not adhere to the method signature (this was for a material UI table extension).
As soon as you have third party code calling your methods all bets are off. It could be JS calling your methods, or there simply is a hidden cast somewhere.
This is the moment that you realize that type annotations really are just a compile-time fiction, much like Python. At least in my definition, this is weak typing as the variable is physically capable of changing to any type at runtime, despite its type annotations.