Eloquent JavaScript 4th edition (2024)

And JavaScript has a bigger ecosystem and more entrenchment, not to mention an international standard.

Flow has about a dozen of important features that typescript lacks (while being 10x smaller in terms of LoC).

I use TS, I like it.

I'm not sure you're 100% right about it overtaking JS for most of the industry.

I wouldn't recommend it to beginners until they've learned JS because it's a lot of stuff to learn on top of JS to achieve basically the same outcomes (with fewer bugs). Chapter 5 in the Eloquent JavaScript book gets to higher order functions, which in TS means Generics. Nobody needs to learn Generics in Chapter 5 of their programming journey.

You also don't really appreciate how useful TS is until you've battled at least one project in plain JS.

(Arguably you can go a long way without HoF too, but perhaps not if you're hoping to understand other people's code.)

Technically Haxe is still a thing, though its typical use case these days is almost 100% game development (including the JS target).

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.

I guess by that same definition, Coffeescript isn't a compile-to-JavaScript language either, as it has the same semantics as vanilla JavaScript?

I think that's besides the point. My point was more that people who are supposed to learn JavaScript, should do so by learning vanilla JavaScript first, then they can move on to learning whatever is currently hyped by the zeitgeist (which happens to be TypeScript currently).

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

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's ecosystem.

Most people though don't even bother reading the docs and can't tell you what a mapped type is or what is a disjointed union, etc.

Do you mean runtime type checking? Coming from compiled type safe languages, it was difficult to wrap my head around full type erasure too. Your name would have definitely helped.

Also effect schema if you're looking for something much more powerful and in effect-land.

Yep. But business requirements dictate what happens and these frameworks are the fastest way to achieve business goals, which sucks as when the frameworks lose their appeal, those devs are gonna struggle to transfer their skills to something else.

Are you reading programming books the same way you would read a fiction book? If so, stop doing that.

Programming or any technical learning is a hands on experience. Take notes and apply techniques, using pen-and-paper or the keyboard, as they are presented.

If you really have to just "read" a technical book, IME a less-is-more approach works best. 5-10 minutes at a time, not even a chapter at once. Maybe a few paragraphs if its something really information dense. Funny aside, I find my morning "business" is the perfect time to this sort of reading using the Kindle app on my phone.

Disclaimer: this is my own, metaphor-filled hypothesis.

It’s easy to fully internalize generalizations that someone has presented to you, usually because it’s wrapped up in a way that is mostly compatible with how you see the world. Because someone has done the work of distilling this information, you are not able to share in most of the intellectual benefit. It’s the process of having a question, discovering an answer, internalization of the concept, and synthesizing a summary that brings you closer to understanding. It feels like a series of “lightbulb moments” when we consume this content, but it is often shallow and fleeting because the genesis of the idea was not your own. Airport/self-help books are a good example of this mental candy that makes us feel good when reading it but, unless you are able to fully internalize it, are just empty mental calories.

Comprehension and understanding are derived from amassing knowledge a little bit at a time as your mind is ready to advance your understanding. In other words, you really have to be “primed” for knowledge found in books. This is the reason that information you obtain after an adequately-informed struggle stays so salient: your mental model had all the scaffolding around a concept but there was a clear “void” where this answer fits, and if you find that fits super cleanly, it’s extra satisfying.

When consuming information-dense material, you end up with this knowledge back-pressure where it’s floating around your short term memory but won’t be committed to long term memory because there is just no place for it yet. When recalling information in order to create new content with it, and assuming you are challenging yourself, you will end up in situations where there is information starvation (the opposite of back-pressure) where you must either find answers (to fit in your mental model) or find a workaround (ignore the gap).

Some people can just read books and create efficient mental models. Others (myself included) have a limit of how much they can learn in one sitting because our brains need to be fully ready to accept this information.

The last piece of this is the dopamine response cycle that is a positive feedback system (positive as in “more creates more”). Dopamine makes us feel good by rewarding behavior that evolution deemed necessary for species survival (over simplification). Dopamine indirectly triggers long term memory retention because we need to remember why we felt good in that moment so we can replicate it. This used to be, “this berry tastes good, I should remember where this bush was and what the berry looked like.” In the modern context, it ultimately delivers motivation to us because we have adapted to using it to learn new information that is less relevant to survival. Achieving goals and solving problems at hand causes a huge amount of dopamine release. The problem is that we’ve found ways to hijack these systems and short-circuit this feedback cycle so everything had to become way more stimulating.

This got long, but my advice is to work on a project of your choosing that you are intrinsically motivated to do. Begin work on that project and read some of the book that relates to the problem at hand. Repeat this cycle of reading and working, trying to incorporate patterns and concepts you find while reading into your project. Make little goals for yourself every day before your start, and really hold yourself accountable in finishing them.

What I like to do, when not under time pressure, is to read such a book cover-to-cover, as a first pass. I get an idea which parts will be difficult for me, and which are probably not.

In this stage, I don't sweat the parts I don't get, I just note for later, that, if these turn out to be important, will require some care, patience and time. I also build some sort of "map" in my mind about the elements that exist, to get an overview.

After doing so, I feel a lot more confident to tackle the topic of the book "properly", doing exercises, etc.

Take notes as you go or by chapter. If a chapter has a summary at the end, read that first before going through the chapter. If there are code examples, write them out and play around with it. Get the important bits out that way.

Also, realistically you probably won't remember most of what you read. I suck at that as well, but you do build up a lot of peripheral knowledge. You may not remember how to do that one thing, but maybe you do remember that it exists, or that it was in a particular book. Just that type of knowledge has worked well for me.

Not the original poster, but I learn best reading textbooks cover-to-cover. A couple things that help me:

1) I buy physical textbooks and absolutely destroy them with notes in the margins, highlighting, etc. It helps me to interact with the material instead of letting it wash over me, which means I'm both thinking about it more in-depth and as side effect I'm less bored. Otherwise I'll fall asleep and won't learn anything. 2) I accept that I'm not going to remember the entire book. A lot of books are most useful as references anyway. But if you ever find yourself going, "Oh that's really handy to know," then you can make a special note of it or even put it into flashcards. I've been using Anki. The trick is to recognize what is actually worth doing this for. 3) If something is especially worth knowing, (see point 2), see if you can either do problems from the book or try out the concept in some way if there are no problems available.

If you're reading something just because you feel like you should, you won't get anything out of it (or a least I don't).

Everyone has different learning styles. I retain maybe 90% of what I read, but only 10% of what I hear. So videos and any audio are the worst formats for me to learn anything.

The first step is figuring out what your learning style is.

1. Take notes. If you are reading an ebook or a webpage, handwritten notes may be better because you will not be tempted to copy and paste.

2. If feasible for you, consider getting a neuropsychological evaluation to rule out any learning disabilities like adult attention deficit disorder.

In that sense an annotated "this is what JS used to be when this book first came out" version could be of historical interest.

Last time was 2017 I think, don't know if there is a big difference I use both new and old things

I think Kyle Simpson is out of work and looking for something full-time and also started some other company, so probably not his main priority atm.

Immutable variable isn't a oxymoron. It can still vary between instantiations. If you have (a)=>{const b = a}, b can have different values even though it can't be reassigned.

My point is that it's not a simplification, it's precisely how the language works: bindings between values and names (JavaScript has no separate notion of memory pointer; everything is a "pointer"). (Similarly for Python: https://nedbatchelder.com/text/names1.html) Describing variables in this way gives readers the correct understanding, and the analogy of tentacles is no harder than that of boxes. Such things are what I most appreciated, that the author manages to be approachable without sacrificing accuracy.

It's not a simplification. It is abstraction. Binding doesn't imply a particular implementation.

A variable binding can disappear entirely. If you bind var x = 42 and never use it, the variable need not exist. If it doesn't exist, then there is no pointer.

If you do use it, constant propagation/folding can again make the variable disappear. If the variable is never assigned, all uses of it can be replaced with 2.

Variables that care captured by lexical closures can be treated differently from ones that are not. Variables captured by closures but not shared among different closures, or not mutated, can be treated differently from mutated variables shared among closures.

The abstraction of binding is more complicated than "every variable is a memory pointer" because it allows more possibilities, which can coexist.

Bash documentation says that "set -u" traps variables that are "unset".

The actual diagnostic itself is better educated:

  $ set -u
  $ asdasdf
  $ echo $asdasdf
  bash: asdasdf: unbound variable

I knew that in Python all variables are really references to objects (even when we're using a number) - is JavaScript the same way?

Also, does anyone have a link/reference to the place in the spec where it specifies this? I briefly skimmed through parts of [1] but couldn't find anything that says that JavaScript treats numbers this way.

[1] https://tc39.es/ecma262/multipage/#sec-intro

Secrets of the Javascript Ninja is my favorite JS book by far.