7 ms·

Deep JavaScript

337 points by noch 5y ago

lewisjoe 5y ago
I haven't read the book yet, but the topics themselves are quite intriguing and looks useful. Definitely a good hammer to break out of the "advanced beginner" chamber.
Santosh83 5y ago
It is appreciable that he offers a discount for those for whom USD is ridiculously expensive in their own currency or have previously bought his books. Though I wish he would rather send the discount code via email rather than ask for a mobile number, which is rather invasive.
- codetrotter 5y ago
  Probably he wants the phone number because it indicates which country someone is from. I mean sure you can still get a temporary number from another country online, so it’s not 100% accurate. Or you could have recently moved countries and still be using the phone number that you got in your old country. But many people will probably use their actual number and of those people most probably have a number from the country they are living in.
brundolf 5y ago
Has anybody read this book? I'm curious about the quality. It's one of those things that could either be really great or really misguided.
- hparadiz 5y ago
  Referencing the few areas of it where I have domain knowledge I'm impressed. Lots of really good info. If nothing else it's a great starting point for research on various topics.
- pacomerh 5y ago
  Axel Rauschmayer has been writing JS books for a while, he's quite knowledgable. I would recommend
- amalive 5y ago
  Haven't read it but since it from the same author who writes these 'to the point' blogs - https://2ality.com/ https://2ality.com/ I believe the quality would be good.
  - xer0x 5y ago
    +1 it looks great.
- sparsely 5y ago
  I glanced through it and it has some interesting stuff, but I suspect you'll write better code in 99% of jobs if you don't read it, and don't know about most of the techniques described
  - welly 5y ago
    Why do you think this? I'd be interested as to why you came to this conclusion.
- RobertKerans 5y ago
  Yeah, it's good. Working with with learners, I always recommend his books (particularly the ES6 one) as reference once they're past the basics. He's very good and not someone who disseminates much information that isn't just practical explanations of and realistic usecases for spec. Slightly dry, but very concise. This one's [naturally] slightly more in depth, but it's IMO a necessary addendum to previous books/articles -- something that builds on them for slightly advanced usecases. Sibling comment says you'll write better code in 99% of jobs if you don't read it: I don't think that's true at all. Deep copying, for example isn't uncommon.
maga 5y ago
JS has been my main language for the last decade and Axel (the author of the book) is my go to source when it comes to understanding upcoming features. I frequent proposal repositories, read the standard, and still find myself learning something new when I read an article from Axel on the subject. I have not read the book, but I'm sure it's written with the same rigor and clarity as all Axel's writings.
- flakiness 5y ago
  +1 as a non-JS programmer. His "Exloring ES6" saved me when I was lost as knowing only about good old ES5 (or maybe ES3? I don't even remember.) "JavaScript for impatient programmers" [2] also looks promising. Just purchased one. The PDF looks great although the cover is meh :-) [1] https://exploringjs.com/es6.html https://exploringjs.com/es6.html [2] https://exploringjs.com/impatient-js/ https://exploringjs.com/impatient-js/
- JoBrad 5y ago
  This book is very well written, and interesting (at least to me). I didn’t know that JS didn’t have exceptions at first.
acmecorps 5y ago
I might be missing something; is the book free online..? Or, is there content that's paid only?
- flakiness 5y ago
  > https://exploringjs.com/ https://exploringjs.com/ "Most of the books are free to read online! You can also buy offline versions."
mjburgess 5y ago
I'm finding the serif font, whitespacing & line width, and inline code style quite hard to parse. The whole thing reads (visually) as a bit of an indiscriminate jumble. The following changes help (me). I'd also look at colouring some other sections to clarify the visual flow of document, ``` pre { background-color: #EEE; font-size: 1.2em; line-height: 1.4; margin-left: 1em; padding: 1em; } body { font-family: sans-serif; font-size: 1.2em; } #page-content { margin: 2em auto 2em auto; max-width: 40em; font-size: 1.1em; line-height: 1.7; } ```
- leephillips 5y ago
  I had no problem with parsing the type. I thought it was clear. But I found it odd that there is no copyright information, date of publication, etc.
bloopernova 5y ago
This is very useful right now because I'm about to embark on learning js to be able to write aws-cdk infrastructure code, after finding Terraform to be annoying in some ways. (mostly its declarative nature means any logic can be difficult to shoehorn in). Decided to buy the javascript for impatient persons book and start reading it on my tablet. (more offtopic, but we'll be using TypeScript, so I'm going to need to find some good guides for that too - any suggestions?)
- andrewl-hn 5y ago
  I you are just learning the language, I'd suggest skipping this particular book altogether for now. I'd start with a "Re-introduction" tutorial on MDN [1] followed by another Axel's book - "JavaScript for impatient programmers" [2]. Don't read the whole book at first, focus on specific chapters: parts on Modularity, Collections and Asynchronicity. As for TypeScript, the official Handbook [3] is great. Don't dwell much on intricacies of TS type system. Use it here and there to aid your editor or IDE in highlighting mistakes in your code, and get deeper into it once you get a good grip with JavaScript in general. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re... [2] https://exploringjs.com/impatient-js/toc.html https://exploringjs.com/impatient-js/toc.html [3] https://www.typescriptlang.org/docs/handbook/intro.html https://www.typescriptlang.org/docs/handbook/intro.html
  - bloopernova 5y ago
    Excellent, thank you! I bought the impatient book, and I'll check out the TypeScript handbook too. It's going to be a shock going from declarative DSLs like Puppet and Terraform to a real coding language! Most of my coding experience has been in shell scripting and some Perl/Ruby from ages ago.
    - k__ 5y ago
      I used the CDK for quite some time now and I can say that it's usually simpler to write things in TS than YAML. Being able to throw in some loops here and there is quite a simplification on its own.
dlojudice 5y ago
I have been using and advocating Javascript for over 10 years. I believe language evolution like ES6 are more than welcome. However, I have the impression that the path taken by the committee and the new proposals do not bring great gains (whether in UX, code reading, performance, etc.) but bringing unnecessary complexity. On the other hand, other serious problems such as the mathematical and numerical part of the language are being left aside.
- an1sotropy 5y ago
  Can you describe more about what are the serious problems in the math/numerical parts? (curious, not skeptical)
  - sa46 5y ago
    I’d characterize JS as having moderately annoying numeric limitations rather than serious problems. Two that come mind: Not having 64 bit integers is a large annoyance. There’s workarounds but none of them are especially ergonomic. The expression n | 0 is a signed 32 bit int. The expression n >>> 0 is an unsigned 32 bit int.
- rauschma 5y ago
  From what I’ve read, TC39 acknowledges that this is important and is working on fixing JavaScript’s deficiencies in this area: – BigInts (arbitrary precision integers) were a recent addition: https://exploringjs.com/impatient-js/ch_bigints.html https://exploringjs.com/impatient-js/ch_bigints.html – A proposal for `Decimal` (base 10 floating point numbers with arbitrary precision) is currently at stage 1: https://github.com/tc39/proposal-decimal https://github.com/tc39/proposal-decimal
kbmunchkin 5y ago
This looks really good and I'll probably read a little here and there when I get the urge. But I don't think deep knowledge of JavaScript will pay off in today's web development world. I deep dived JavaScript many years ago so I could move away from C#. It was only useful in interviews so I could answer all the esoteric trivia. On the job it was using JS frameworks and libraries like Lodash. And then TypeScript came along and eclipsed it all together. You're better off learning just enough JavaScript and then deep diving TypeScript and Angular, React, or another framework.
- enumjorge 5y ago
  I’d agree that if you’re looking to have a career in front-end your order should be some JavaScript, then React/Angular and possibly Typescript, but after that I’d still recommend you go back and really learn JavaScript. It doesn’t often happen but sometimes you run into a situation where that knowledge does come in handy. You can introduce bugs in your React code if you don’t understand closures for example, to use a library like redux-saga you need to understand generator functions, you may run into code where you need to know how the “this” keyword works, etc. A more junior dev needing help with those is fine, but I’d expect a senior dev to be able to navigate those type of situations on their own most of the time.
  - austincheney 5y ago
    Solving bugs is important but more to your point a good senior dev knowing those things provides flexibility and empowerment. Sometimes there is a more direct solution than what the internally available tools provide.
- hajile 5y ago
  There's an effect where young people watch Seinfeld and find it unfunny and derivative. That's not because it's true, but because they watched stuff that had copied what Seinfeld did first. People look at Crockford's "JS: The Good Parts" and comment on how it's obvious. It wasn't obvious then and that's why the book was so well received. Languages have radically copied the good parts JS since then while JS has lost most of the worst parts which means that when you move to JS, it's a much less radical shift. First-class functions and closures with all their implications (IIFE, module pattern, callback/continuation, lambdas, .map() and it's ilk, currying, etc) have all caught on as a result. Immutable data or more precisely, treating data as immutable and letting the GC sort it out was a huge boon for UI development. Promises/futures seem ubiquitous these days, but that's strictly because of JS libraries introducing them in 2005 (twisted library introduced them in Python in 2001, but Python wasn't super popular then and twisted has never been popular at all). I'd also say that the push for pattern matching has also been fueled by ES6. In truth, StandardML (SML) and Scheme had been doing most of this (and much more) since the 70s, but for whatever reason, they have been rejected by mainstream developers. Hopefully, one day we will recognize this and switch development away from languages with these features tacked on to ones where they are baked in and cohesive.
leephillips 5y ago
The URL should go the the front page of the book (https://exploringjs.com/deep-js/ https://exploringjs.com/deep-js/) rather than the table of contents.
shp0ngle 5y ago
This is a bit off-topic But I never understood prototypes and prototype inheritance, and how does that "map" to "classic" inheritance, from Java or C++. And I worked in FE for about 10 years... It seems you can model "classic" inheritance using prototypes, but... there is something more there that I don't understand. I started using ES6 "class" as quickly as I could, but I still wish I understood what .prototype and .__proto__ is and how to use it. I feel like I "miss" a lot of JS when misunderstanding prototypes. But none of my colleagues know either, so I guess I at least know what I don't know.
- turndown 5y ago
  A class is a blueprint you go to for constructing new objects. A prototype is an object you create once that is copied to a variable when the constructor is called. That is how I understand it, but maybe someone else can explain further.
  - k__ 5y ago
    You can think of a prototype as a fallback for your object. If something doesn't exist on your object, JS will check if it has a prototype and look there transparently. Now, if you got a prototype chain, JS will move through it in the hope to find what you wanted to access on the original object. try to access obj.a not there? try to access obj.prototype.a not there? try to access obj.prototype.prototype.a etc. The nice thing is "this" will usually (if you call a function as method and not pass a reference of it around for callbacks and such) refer to the object and not the prototype. Also, writes happen on the object.
- rauschma 5y ago
  In JavaScript, classes are mostly just a slightly weird way of setting up prototype chains. Diagrams help me understand how this works. At the following link, you can see the source code of a simple class and a diagram (section 29.2.2) that shows how all involved objects are connected: https://exploringjs.com/impatient-js/ch_proto-chains-classes.html#a-class-for-persons https://exploringjs.com/impatient-js/ch_proto-chains-classes...
- 5y ago
hyperpallium2 5y ago
Whether we've hit Peak JavaScript, or are looking at Long JavaScript, sooner or later we'll face Big JavaScript.
geonic 5y ago
This looks like a good book but boy, is JavaScript convoluted. Not bashing it. Just read the chapters about shallow and deep copies. https://exploringjs.com/deep-js/ch_copying-objects-and-arrays.html https://exploringjs.com/deep-js/ch_copying-objects-and-array...
- mikewhy 5y ago
  Isn't shallow vs deep copying a thing in most languages?
  - geonic 5y ago
    It is. JavaScript seems to have quite a few ways of getting it wrong though.
- kdmccormick 5y ago
  Fortunately, it seems to be convoluted as a result of its underlying simplicity, perhaps? The reason the article you linked is so long (instead of just being the standard OOP shallow- vs deep-copy disclaimer) seems to be because JS objects and classes are just dictionaries (in the Python sense of the word) with certain magic fields to control dispatch, inheritance, etc. The docs need to take care to explain how certain operations interact with those magic fields. So, still convoluted, but IMO better than if it were convoluted because everything was a built-in special case under the hood. At least that's my impression as someone who doesn't write a lot of JS. Happy to be corrected.
  - adt2bt 5y ago
    That's also my impression as someone who used to write a lot of JS - everything is either a value, dict or array, and once you learn some guardrails on how you write JS code (in your words, 'explain how certain operations interact with those magic fields'), it becomes remarkably nice to use.
- stupidcar 5y ago
  Do you have any empirical evidence it is more convoluted than equivalent popular languages?
TheRealPomax 5y ago
Clicked through to https://exploringjs.com/deep-js/ch_type-coercion.html https://exploringjs.com/deep-js/ch_type-coercion.html and I have to say that's already a bit questionable. The idea is there, but the writing around it is shaky (if you want to explain coercion, showing JS code without coercion without explaining that's what you're doing is not the best way to explain things to folks looking for answers). Same for https://exploringjs.com/deep-js/ch_copying-objects-and-arrays.html#shallow-copying-vs.-deep-copying https://exploringjs.com/deep-js/ch_copying-objects-and-array..., the idea is there, but the text isn't great (is it only for objects and arrays? if I'm new to JS but someone taught me about Set and Map, can I assume those always deep copy?). It's a great start, but it can definitely do with a few QA (rather than editorial) passes.
- rauschma 5y ago
  [I’m the author of “Deep JavaScript”.] Don’t forget that this book is for people who already know JavaScript well. It doesn’t try to explain the basics. This book does, though: https://exploringjs.com/impatient-js/ https://exploringjs.com/impatient-js/
  - TheRealPomax 5y ago
    Sure, but as an expert, explanations that holds up for everyone are always preferred no matter what level of book I'm reading, compared to an explanation that makes sense "if you already how it works". In both cases linked, the text feels incomplete or even just "wrong, were it not for the fact that I know what you actually meant".
imbnwa 5y ago
I've always found Raganwald Braithwaite's JavaScript Allongé to be a wonderful demonstration and application of the kind of idiomatic classless JavaScript you get when you understand the language's OO properties.
archibaldJ 5y ago
Not sure why author uses the phrase "pattern matching algorithm". There is nothing algorithmical about it. This is just a pattern matching language feature similiar to Haskell's. And since JS is dynmatically typed, I believe this is really just sytnax sugar at the interpreter level. Unless there is something time/space-specific about it, invoking "algorithm" feels to me an abuse of terminology. Of course will love to be enlightened otherwise.

337 points by noch 5y ago

I haven't read the book yet, but the topics themselves are quite intriguing and looks useful. Definitely a good hammer to break out of the "advanced beginner" chamber.

Santosh83 5y ago

It is appreciable that he offers a discount for those for whom USD is ridiculously expensive in their own currency or have previously bought his books. Though I wish he would rather send the discount code via email rather than ask for a mobile number, which is rather invasive.

codetrotter 5y ago
Probably he wants the phone number because it indicates which country someone is from. I mean sure you can still get a temporary number from another country online, so it’s not 100% accurate. Or you could have recently moved countries and still be using the phone number that you got in your old country. But many people will probably use their actual number and of those people most probably have a number from the country they are living in.

brundolf 5y ago

Has anybody read this book? I'm curious about the quality. It's one of those things that could either be really great or really misguided.

hparadiz 5y ago
Referencing the few areas of it where I have domain knowledge I'm impressed. Lots of really good info. If nothing else it's a great starting point for research on various topics.
pacomerh 5y ago
Axel Rauschmayer has been writing JS books for a while, he's quite knowledgable. I would recommend
amalive 5y ago
Haven't read it but since it from the same author who writes these 'to the point' blogs - https://2ality.com/ https://2ality.com/ I believe the quality would be good.
- xer0x 5y ago
  +1 it looks great.
sparsely 5y ago
I glanced through it and it has some interesting stuff, but I suspect you'll write better code in 99% of jobs if you don't read it, and don't know about most of the techniques described
- welly 5y ago
  Why do you think this? I'd be interested as to why you came to this conclusion.
RobertKerans 5y ago
Yeah, it's good. Working with with learners, I always recommend his books (particularly the ES6 one) as reference once they're past the basics. He's very good and not someone who disseminates much information that isn't just practical explanations of and realistic usecases for spec. Slightly dry, but very concise. This one's [naturally] slightly more in depth, but it's IMO a necessary addendum to previous books/articles -- something that builds on them for slightly advanced usecases. Sibling comment says you'll write better code in 99% of jobs if you don't read it: I don't think that's true at all. Deep copying, for example isn't uncommon.

maga 5y ago

JS has been my main language for the last decade and Axel (the author of the book) is my go to source when it comes to understanding upcoming features. I frequent proposal repositories, read the standard, and still find myself learning something new when I read an article from Axel on the subject. I have not read the book, but I'm sure it's written with the same rigor and clarity as all Axel's writings.

flakiness 5y ago
+1 as a non-JS programmer. His "Exloring ES6" saved me when I was lost as knowing only about good old ES5 (or maybe ES3? I don't even remember.) "JavaScript for impatient programmers" [2] also looks promising. Just purchased one. The PDF looks great although the cover is meh :-) [1] https://exploringjs.com/es6.html https://exploringjs.com/es6.html [2] https://exploringjs.com/impatient-js/ https://exploringjs.com/impatient-js/
JoBrad 5y ago
This book is very well written, and interesting (at least to me). I didn’t know that JS didn’t have exceptions at first.

acmecorps 5y ago

I might be missing something; is the book free online..? Or, is there content that's paid only?

flakiness 5y ago
> https://exploringjs.com/ https://exploringjs.com/ "Most of the books are free to read online! You can also buy offline versions."

mjburgess 5y ago

I'm finding the serif font, whitespacing & line width, and inline code style quite hard to parse. The whole thing reads (visually) as a bit of an indiscriminate jumble. The following changes help (me). I'd also look at colouring some other sections to clarify the visual flow of document, ``` pre { background-color: #EEE; font-size: 1.2em; line-height: 1.4; margin-left: 1em; padding: 1em; } body { font-family: sans-serif; font-size: 1.2em; } #page-content { margin: 2em auto 2em auto; max-width: 40em; font-size: 1.1em; line-height: 1.7; } ```

leephillips 5y ago
I had no problem with parsing the type. I thought it was clear. But I found it odd that there is no copyright information, date of publication, etc.

bloopernova 5y ago

This is very useful right now because I'm about to embark on learning js to be able to write aws-cdk infrastructure code, after finding Terraform to be annoying in some ways. (mostly its declarative nature means any logic can be difficult to shoehorn in). Decided to buy the javascript for impatient persons book and start reading it on my tablet. (more offtopic, but we'll be using TypeScript, so I'm going to need to find some good guides for that too - any suggestions?)

andrewl-hn 5y ago
I you are just learning the language, I'd suggest skipping this particular book altogether for now. I'd start with a "Re-introduction" tutorial on MDN [1] followed by another Axel's book - "JavaScript for impatient programmers" [2]. Don't read the whole book at first, focus on specific chapters: parts on Modularity, Collections and Asynchronicity. As for TypeScript, the official Handbook [3] is great. Don't dwell much on intricacies of TS type system. Use it here and there to aid your editor or IDE in highlighting mistakes in your code, and get deeper into it once you get a good grip with JavaScript in general. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re... [2] https://exploringjs.com/impatient-js/toc.html https://exploringjs.com/impatient-js/toc.html [3] https://www.typescriptlang.org/docs/handbook/intro.html https://www.typescriptlang.org/docs/handbook/intro.html
- bloopernova 5y ago
  Excellent, thank you! I bought the impatient book, and I'll check out the TypeScript handbook too. It's going to be a shock going from declarative DSLs like Puppet and Terraform to a real coding language! Most of my coding experience has been in shell scripting and some Perl/Ruby from ages ago.
  - k__ 5y ago
    I used the CDK for quite some time now and I can say that it's usually simpler to write things in TS than YAML. Being able to throw in some loops here and there is quite a simplification on its own.

dlojudice 5y ago

I have been using and advocating Javascript for over 10 years. I believe language evolution like ES6 are more than welcome. However, I have the impression that the path taken by the committee and the new proposals do not bring great gains (whether in UX, code reading, performance, etc.) but bringing unnecessary complexity. On the other hand, other serious problems such as the mathematical and numerical part of the language are being left aside.

an1sotropy 5y ago
Can you describe more about what are the serious problems in the math/numerical parts? (curious, not skeptical)
- sa46 5y ago
  I’d characterize JS as having moderately annoying numeric limitations rather than serious problems. Two that come mind: Not having 64 bit integers is a large annoyance. There’s workarounds but none of them are especially ergonomic. The expression n | 0 is a signed 32 bit int. The expression n >>> 0 is an unsigned 32 bit int.
rauschma 5y ago
From what I’ve read, TC39 acknowledges that this is important and is working on fixing JavaScript’s deficiencies in this area: – BigInts (arbitrary precision integers) were a recent addition: https://exploringjs.com/impatient-js/ch_bigints.html https://exploringjs.com/impatient-js/ch_bigints.html – A proposal for `Decimal` (base 10 floating point numbers with arbitrary precision) is currently at stage 1: https://github.com/tc39/proposal-decimal https://github.com/tc39/proposal-decimal

kbmunchkin 5y ago

This looks really good and I'll probably read a little here and there when I get the urge. But I don't think deep knowledge of JavaScript will pay off in today's web development world. I deep dived JavaScript many years ago so I could move away from C#. It was only useful in interviews so I could answer all the esoteric trivia. On the job it was using JS frameworks and libraries like Lodash. And then TypeScript came along and eclipsed it all together. You're better off learning just enough JavaScript and then deep diving TypeScript and Angular, React, or another framework.

enumjorge 5y ago
I’d agree that if you’re looking to have a career in front-end your order should be some JavaScript, then React/Angular and possibly Typescript, but after that I’d still recommend you go back and really learn JavaScript. It doesn’t often happen but sometimes you run into a situation where that knowledge does come in handy. You can introduce bugs in your React code if you don’t understand closures for example, to use a library like redux-saga you need to understand generator functions, you may run into code where you need to know how the “this” keyword works, etc. A more junior dev needing help with those is fine, but I’d expect a senior dev to be able to navigate those type of situations on their own most of the time.
- austincheney 5y ago
  Solving bugs is important but more to your point a good senior dev knowing those things provides flexibility and empowerment. Sometimes there is a more direct solution than what the internally available tools provide.
hajile 5y ago
There's an effect where young people watch Seinfeld and find it unfunny and derivative. That's not because it's true, but because they watched stuff that had copied what Seinfeld did first. People look at Crockford's "JS: The Good Parts" and comment on how it's obvious. It wasn't obvious then and that's why the book was so well received. Languages have radically copied the good parts JS since then while JS has lost most of the worst parts which means that when you move to JS, it's a much less radical shift. First-class functions and closures with all their implications (IIFE, module pattern, callback/continuation, lambdas, .map() and it's ilk, currying, etc) have all caught on as a result. Immutable data or more precisely, treating data as immutable and letting the GC sort it out was a huge boon for UI development. Promises/futures seem ubiquitous these days, but that's strictly because of JS libraries introducing them in 2005 (twisted library introduced them in Python in 2001, but Python wasn't super popular then and twisted has never been popular at all). I'd also say that the push for pattern matching has also been fueled by ES6. In truth, StandardML (SML) and Scheme had been doing most of this (and much more) since the 70s, but for whatever reason, they have been rejected by mainstream developers. Hopefully, one day we will recognize this and switch development away from languages with these features tacked on to ones where they are baked in and cohesive.

leephillips 5y ago

The URL should go the the front page of the book (https://exploringjs.com/deep-js/ https://exploringjs.com/deep-js/) rather than the table of contents.

shp0ngle 5y ago

This is a bit off-topic But I never understood prototypes and prototype inheritance, and how does that "map" to "classic" inheritance, from Java or C++. And I worked in FE for about 10 years... It seems you can model "classic" inheritance using prototypes, but... there is something more there that I don't understand. I started using ES6 "class" as quickly as I could, but I still wish I understood what .prototype and .__proto__ is and how to use it. I feel like I "miss" a lot of JS when misunderstanding prototypes. But none of my colleagues know either, so I guess I at least know what I don't know.

turndown 5y ago
A class is a blueprint you go to for constructing new objects. A prototype is an object you create once that is copied to a variable when the constructor is called. That is how I understand it, but maybe someone else can explain further.
- k__ 5y ago
  You can think of a prototype as a fallback for your object. If something doesn't exist on your object, JS will check if it has a prototype and look there transparently. Now, if you got a prototype chain, JS will move through it in the hope to find what you wanted to access on the original object. try to access obj.a not there? try to access obj.prototype.a not there? try to access obj.prototype.prototype.a etc. The nice thing is "this" will usually (if you call a function as method and not pass a reference of it around for callbacks and such) refer to the object and not the prototype. Also, writes happen on the object.
rauschma 5y ago
In JavaScript, classes are mostly just a slightly weird way of setting up prototype chains. Diagrams help me understand how this works. At the following link, you can see the source code of a simple class and a diagram (section 29.2.2) that shows how all involved objects are connected: https://exploringjs.com/impatient-js/ch_proto-chains-classes.html#a-class-for-persons https://exploringjs.com/impatient-js/ch_proto-chains-classes...
5y ago

hyperpallium2 5y ago

Whether we've hit Peak JavaScript, or are looking at Long JavaScript, sooner or later we'll face Big JavaScript.

geonic 5y ago

This looks like a good book but boy, is JavaScript convoluted. Not bashing it. Just read the chapters about shallow and deep copies. https://exploringjs.com/deep-js/ch_copying-objects-and-arrays.html https://exploringjs.com/deep-js/ch_copying-objects-and-array...

mikewhy 5y ago
Isn't shallow vs deep copying a thing in most languages?
- geonic 5y ago
  It is. JavaScript seems to have quite a few ways of getting it wrong though.
kdmccormick 5y ago
Fortunately, it seems to be convoluted as a result of its underlying simplicity, perhaps? The reason the article you linked is so long (instead of just being the standard OOP shallow- vs deep-copy disclaimer) seems to be because JS objects and classes are just dictionaries (in the Python sense of the word) with certain magic fields to control dispatch, inheritance, etc. The docs need to take care to explain how certain operations interact with those magic fields. So, still convoluted, but IMO better than if it were convoluted because everything was a built-in special case under the hood. At least that's my impression as someone who doesn't write a lot of JS. Happy to be corrected.
- adt2bt 5y ago
  That's also my impression as someone who used to write a lot of JS - everything is either a value, dict or array, and once you learn some guardrails on how you write JS code (in your words, 'explain how certain operations interact with those magic fields'), it becomes remarkably nice to use.
stupidcar 5y ago
Do you have any empirical evidence it is more convoluted than equivalent popular languages?

TheRealPomax 5y ago

Clicked through to https://exploringjs.com/deep-js/ch_type-coercion.html https://exploringjs.com/deep-js/ch_type-coercion.html and I have to say that's already a bit questionable. The idea is there, but the writing around it is shaky (if you want to explain coercion, showing JS code without coercion without explaining that's what you're doing is not the best way to explain things to folks looking for answers). Same for https://exploringjs.com/deep-js/ch_copying-objects-and-arrays.html#shallow-copying-vs.-deep-copying https://exploringjs.com/deep-js/ch_copying-objects-and-array..., the idea is there, but the text isn't great (is it only for objects and arrays? if I'm new to JS but someone taught me about Set and Map, can I assume those always deep copy?). It's a great start, but it can definitely do with a few QA (rather than editorial) passes.

rauschma 5y ago
[I’m the author of “Deep JavaScript”.] Don’t forget that this book is for people who already know JavaScript well. It doesn’t try to explain the basics. This book does, though: https://exploringjs.com/impatient-js/ https://exploringjs.com/impatient-js/
- TheRealPomax 5y ago
  Sure, but as an expert, explanations that holds up for everyone are always preferred no matter what level of book I'm reading, compared to an explanation that makes sense "if you already how it works". In both cases linked, the text feels incomplete or even just "wrong, were it not for the fact that I know what you actually meant".

imbnwa 5y ago

I've always found Raganwald Braithwaite's JavaScript Allongé to be a wonderful demonstration and application of the kind of idiomatic classless JavaScript you get when you understand the language's OO properties.

archibaldJ 5y ago

Not sure why author uses the phrase "pattern matching algorithm". There is nothing algorithmical about it. This is just a pattern matching language feature similiar to Haskell's. And since JS is dynmatically typed, I believe this is really just sytnax sugar at the interpreter level. Unless there is something time/space-specific about it, invoking "algorithm" feels to me an abuse of terminology. Of course will love to be enlightened otherwise.