Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eloquent JavaScript 4th edition (2024)

eloquentjavascript.net

Post reply on HN
Print view View original

51–60 of 249 posts

Re: Eloquent JavaScript 4th edition (2024)

#51

Post by michaelcampbell »

ricardobeat wrote: post #43
svat wrote: post #14

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://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 pretty standard terminology in some oldtimey languages; lisp, ML, etc.

Re: Eloquent JavaScript 4th edition (2024)

#52

Post by Solvency »

wk_end wrote: post #36
diggan wrote: post #7

Earlier quoted context omitted.

> 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.

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 tha…

Which further exposes the irony of casual hipsters who say things to me like "Thank God for Typescript, it's like a whole other language than JS". For example, a designer, who writes a quick one off plug-in for Figma in Typescript without realizing 99.9% could have been just written/pasted into the JS file (which is ultimately what Figma runs).

Re: Eloquent JavaScript 4th edition (2024)

#53

Post by diggan »

epolanski wrote: post #16
diggan wrote: post #7

Earlier quoted context omitted.

> 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.

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 investme…

> Because TypeScript is the de facto standard way of writing JavaScript for most of the industry

It really isn't, but I guess that's really context specific. What country and sector are you talking about? For US-SaaS, what you're saying is probably true, but there is a whole world outside of that, and JavaScript is with 99% certainty much more wildly used than TypeScript.

> and it has killed all of the other compile-to-js languages.

Also it hasn't. I've been writing ClojureScript for the last 5 years, almost exclusively. And while the community is small, I wouldn't say it's "dead" or been killed. There are a bunch of compile-to-JS languages that haven't "been killed", besides ClojureScript.

But it serves basically the opposite niche compared to TypeScript.

> The chances of it going out of favour are very slim

Same has been said about everything, always, and it's always not true. Winds change, and surely so shall the winds of TypeScript. Not being able to see that it's possible, will put you at disadvantage.

Re: Eloquent JavaScript 4th edition (2024)

#54

Post by alyandon »

throwaway632 wrote: post #27
alyandon wrote: post #21

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.

> 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.

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.

Re: Eloquent JavaScript 4th edition (2024)

#56

Post by jameshart »

ricardobeat wrote: post #43
svat wrote: post #14

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://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…

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.

Re: Eloquent JavaScript 4th edition (2024)

#57

Post by Sn0wCoder »

samtho wrote: post #38

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…

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.

Re: Eloquent JavaScript 4th edition (2024)

#58

Post by MikeTheGreat »

svat wrote: post #14

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://masto…

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