getify / you-dont-know-js Goto Github PK
View Code? Open in Web Editor NEWA book series on JavaScript. @YDKJS on twitter.
License: Other
A book series on JavaScript. @YDKJS on twitter.
License: Other
Is it a label assigment?.
I read this chapter a couple of times, researched some of your assertions, and tried every example in IE and Chrome
Read through once so far and tried every example in IE and Chrome.
"Please feel free to contribute to the quality of this content by submitting PR's for improvements to code snippets, explanations, etc" and "The materials herein are all (c) 2013-2014 Kyle Simpson" don't work together. Contributors have to either preserve copyright on submitted material or explicitly sign over their copyright over to you.
Talk about the corner-cases of this
binding, such as how indirect references can result in unexpected bindings:
function foo() {
console.log(this.bar);
}
var omg = { bar: "bar", foo: foo };
omg.foo(); // bar
(omg.foo = omg.foo)(); // undefined
Number("123") // 123 -- decimal ftw!
Number("0x640") // 1600 -- hex ftw!
but:
Number("0640") // 640 not 416 :( octal ftl.
In "this & Object Prototypes" Ch 3 "Objects", we need a section to handle these ES5 object eccentricities.
parseInt(1/0,19); // 18
parseInt(0.000008); // 0
parseInt(0.0000008); // 8 ==> 8e-7
parseInt(false,16); // 250
parseInt(parseInt,16); // 15
possible enhancement
I am not sure where the line should be drawn for the scope of this project. Could this project move into areas such as native js functions (string, number, object and so on) and control flows (conditionals, loops, promises)? I would think design patterns and libraries are out of scope, but I am not sure about native functions and control flows.
Love your work
Explain how &&
and ||
operators are often incorrectly explained as boolean logical operators, when in reality they are more accurately "operand-selector operators":
"abc" || 2; // "abc"
"abc" && 2; // 2
null || 2; // 2
null && 2; // null
They use implicit coercion (if necessary) in the tests, but their end result is not the boolean result, but the operand selection.
http://javascript-puzzlers.herokuapp.com/
Some ones in particular to explain: switch
, []==[]
, var x = y = 1;
As per instructions starting a single issue for all of my comments on the book.
oops, missed this super important detail. going to have to address in the "scope & closures" book, in chapter 4 (or maybe 3). +@bmacdonald-oreilly
This section starts by explaining how collisions take place, then explains how libraries avoid collisions in global scope, then explains module management. Since the “Module Management” discussion gets a subhead, the “Libraries in Global Scope” section should have one too.
One of the properties of ES6 modules that the module champions use to sell the value of them is that they provide static checks upon import that a corresponding name has been declared for export. So if you attempt to import a name from a module that it doesn't export, that's an error at compile time, rather than deferring the check to runtime (where, to be clear, it would generally cause an eventual failure because the value of the corresponding name to be undefined
).
This is interesting mostly because it's unusual for JavaScript, which will almost always take the dynamic (runtime) path when presented with a choice between static and dynamic behavior. It also shows that the ES6 module syntax is more than just sugar around a more traditional JS module pattern.
It looks like we were both right about the distinction between module compilation and module loading (or, looked at in a less awesome way, we were both wrong). In addition to module compilation and module loading, there's also module linking, which is when the static checks for conflicts and missing values are applied. All three of these stages happen at compilation time, though, which preserves the idea of fast failure on typos or other common errors and is a kind of behavior that can only show up if it's baked into the language at design time.
I think you're right that to get too into the details of modules would probably be beyond the scope of what you're getting at in your discussion of closures -> modules, but it might be worth pointing out that ES6 modules are different just by virtue of living inside the static semantics portion of the language, which (in part) justifies making them part of ES6 in the first place.
I should also point out, I guess, that I'm ambivalent about this aspect of modules, given that static checking of various kinds could be justified as useful all over the place in JavaScript. The primary rationale offered for making imports static is "If import declarations were resolved dynamically, then imported variables would be dynamically scoped. Harmony will not have any dynamic scoping..." which makes sense from a formal design perspective (David Herman and Sam Tobin-Hochstadt are meticulous when it comes to their PLT!), but still feels weird in the almost-always dynamic JS environment.
You state that functions are hoisted before variables, and yet these functions can refer to variables defined in the same scope. Is it simply the case that the variables will be defined by the time the function is actually called, or is it that all the variable and function names are hoisted together, then the functions defined, and then the remainder of the code executed?
A little hard to follow the flow of the sections. For instance, you mention at the end of the chapter introduction for What is Scope about having a conversation, then you went into compilers, and then back to conversation. You note it yourself by asking a question at the end of the Compiler Theory section, about what does it have to do with scope, but then you don't answer that question in the beginning of the next section--you go back to the conversation.
Suggestion: right after the first mention of conversation, perhaps say something along the lines of "before we get to that conversation, we need to better under the JS compiler" or some such thing. Something to recapture that flow and better prepare the readers for jumps in topic.
put this fantastic video's content into book form!
As per instruction, I will be annotating all technical review notes here as comments on this issue thread.
You’ve introduced Engine as an entity, but you haven’t introduced Scope as one. It’s not that hard to figure out, but if you’ve formally defined one, you should formally define the other.
An excellent blog post by @rauschma that illuminates these important behaviors:
Unfortunately, related to my research around #42, I discovered via twitter conversation with @dherman that my treatment of ES6 modules w/ inline syntax is invalid as of Sept 2013, when that syntax was rejected from ES6.
Update the syntax and the discussion around it in Chapter 5: "Future Modules" according to the more recent accepted syntax: https://github.com/jorendorff/js-loaders/blob/master/specs/es6-modules-2013-12-02.pdf
/cc @bmacdonald-oreilly @othiym23
Starting with the Jack-Shit pun, you're basically tell the reader they don't know nothing, JavaScript or otherwise. Why is degrading your readers considered a good practice, I have no clue. This isn't humour. It's insulting.
function foo(str) {
"use strict";
eval(str);
console.log(a);
}
foo("var a = 2"); // ReferenceError: a is not defined
Why spend so much time discussing both eval() and with(), if the upshot is “these are bad, don’t use them”?
cover, if possible, differences in these cases between ES5 and ES6.
The link to the image isn’t working. Also, I don’t know if the “building” metaphor works for me. It implies that global scope is built “on top of” the nested scopes, which doesn’t quite fit, because that implies you couldn’t remove the nested scopes without affecting the global. I think a metaphor like a matryoshka doll may work better.
Item #2: You don’t have to apologize to the reader for telling them stuff. Acknowledge that it’s complicated, and move on.
Item #3: “turn it into a set of machine instructions to actually create a variable called a,”
Maybe there should be some mention of memory addresses there. I know you describe later exactly what the compiler does, but using the verb “create” sounds a bit too magical.
In the “Future Modules” section (by the way, I’m really liking that new module syntax), is there anything to say about closures? Even if the new syntax has no effect on the way closures work with modules (and I assume it doesn’t), you could reassure the reader that nothing has changed.
There's really no such thing as "constructors" in JS, there's functions called with new
, which make that call a "constructor call". Clarify this.
Not sure if this is a product of still being in draft form, or if a file got missed in a commit - https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closure/ch1.md#building-on-metaphors references ./fig1.png, which doesn't exist at the moment.
One stop shop...
In general, I prefer to spell out abbreviations that appear for the first time in headings. Even if you define it right away, that heading will appear in various places without any accompanying text (in the table of contents, for example), which could be confusing to readers. However, if IIFE is such a well-known abbreviation that readers would be less likely to recognize it spelled out, then you should leave it alone.
Also explain why?
...like document.all
. Though not officially part of JS the language, should mention this strange weirdness in the host layer.
In the Enumeration section of Chapter 3 of "this
& Object Prototypes":
Need a brief discussion of iterating through array values using forEach()
, every()
, and some()
, in contrast to the for-loop approach shown.
Your pseudo-code description of “var a = 2” is exactly what I did think was going on, so that’s clearly working for me. But your description of what’s actually going on doesn’t mention allocating space, so the two descriptions don’t seem to describe the same thing. Where is the memory allocation taking place?
I'm seeking out folks who want to be official tech reviewers for this book series (to work with the editors at O'Reilly). You will review the drafts as posted here and provide technical feedback, also here, which can be addressed as revisions during the editing/production phase.
You should have a solid understanding of the core parts of JavaScript (not just frameworks). :)
If you're interested, please leave your contact info in a comment below, and @bmacdonald-oreilly will get in touch with you!
The last Code snippet in Module section has some missing code.
Right now it looks like
var publicAPI = {
identify: identify1,
};
But along with identity function it should return change function as well
modified version:
var publicAPI = {
identify: identify1,
change: change
};
If you pass some non-object (null
, undefined
, 0
, 1
, etc) as the this
parameter to call()
, apply()
, or bind()
, that value is ignored for the purposes of the rules here:
Add a note explaining and illustrating what happens in that case.
In the first code example, you mention the scope for variables b and c, but not a.
Explain how an iterator works better by showing how the default built-in one (sorta) works:
https://gist.github.com/getify/9104721#file-gistfile1-js
Also, explain the "sort-of" example, instead of just presenting as-is and not saying anything.
big wtf: Array(3)
is production something more like [].length = 3
than [undefined,undefined,undefined]
. insane.
another oops to correct in "scope & closures". +@bmacdonald-oreilly
Address, as necessary, conversations like this:
And address this, as well as whether it will be changing?
"use strict";
foo(); // "b"
var a = true;
if (a) {
function foo() { console.log("a"); }
}
else {
function foo() { console.log("b"); }
}
Hi,
Can I contribute with texts/examples?
https://github.com/peterborkuti/other/tree/master/JavaScriptBasics
I did an in-depth presentation:
https://github.com/peterborkuti/other/blob/master/JavaScriptBasics/jsbasics-slide.odp
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.