Giter VIP home page Giter VIP logo

you-dont-know-js's Introduction

You Don't Know JS Yet (book series) - 2nd Edition

This is a series of books diving deep into the core mechanisms of the JavaScript language. This is the second edition of the book series:

     ...

To read more about the motivations and perspective behind this book series, check out the Preface.

If you're looking for the previous first edition books, they can be found here.

Titles

I recommend reading the second edition books in this order:

If you're looking for the previous first edition books, they can be found here.

Publishing

As always, you'll be able to read these books online here entirely for free.

This edition of the books is being self-published through GetiPub publishing. The published books will be made available for sale through normal book retail sources.

If you'd like to contribute financially towards the effort (or any of my other OSS efforts) aside from purchasing the published books, please consider these options:

Contributions

Please feel free to contribute to the quality of this content by submitting PRs for improvements to code snippets, explanations, etc. While typo fixes are welcomed, they will likely be caught through normal editing/publishing processes, so please don't worry about them right now.

Any contributions you make to this effort are of course greatly appreciated.

But PLEASE read the Contributions Guidelines carefully before submitting a PR.

Thank You To These Wonderful Sponsors

Frontend Masters Logo (dark)

Frontend Masters Logo (light)

The first two books of the second edition are exclusively sponsored by Frontend Masters.

Frontend Masters is the gold standard for top-of-the-line expert training material in frontend-oriented software development. With over 150 courses on all things frontend, this should be your first and only stop for quality video training on HTML, CSS, JS, and related technologies.

Note: I teach all my workshops exclusively through Frontend Masters. If you like this book content, please check out my video training courses.

I want to extend a warm and deep thanks to Marc Grabanski and the entire Frontend Masters team, not only for their excellent work with the video training platform, but for their unwavering support of me and of the "You Don't Know JS" books!


License & Copyright

The materials herein are all © 2019-2022 Kyle Simpson.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 4.0 Unported License.

you-dont-know-js's People

Contributors

4thana avatar cncolder avatar davidtheclark avatar diogocampos avatar fay-jai avatar getify avatar harpreetkhalsagtbit avatar imurchie avatar infinnie avatar jrencz avatar jtassia avatar kemar avatar ljharb avatar machineloop avatar magul avatar mdouglasbrett avatar noblemule avatar olawd avatar pdawyndt avatar pelonpelon avatar rwaldron avatar ryanplusplus avatar severyanov avatar skeep avatar umpox avatar varun06 avatar wkich avatar yannmadeleine avatar zacharymarshal avatar zackgao avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

you-dont-know-js's Issues

Chapter 1, "Conversation?" section edits

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.

"types & grammar": cover what `&&` and `||` operators ACTUALLY do

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.

ES6 modules are privileged over other module systems

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.

Appendix to discuss indirect `this` bindings

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

Tech Editors

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!

Chapter 1, "Compilation" Section edits

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.

Chapter 3, "Collision Avoidance" section edits

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.

Chapter 5, "Future Modules" section edits

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.

technical review - vball525

Scope and Closures

Chapter 1

I read this chapter a couple of times, researched some of your assertions, and tried every example in IE and Chrome

  • I like your explaination of how JS compiliation works but it is not universal. Quick Googling around shows many different JS engines and they all dont work exactly the same as far as I can tell.
  • Will you address the difference how JS is handled by each engine/browser and also any resulting errors?
  • fig1.png is missing (reading other reviews i saw your note about this)
  • In the Error example: IE shows error the first time b is called as b is undefined. Chrome shows what the example says it should.

Chapter 2

Read through once so far and tried every example in IE and Chrome.

  • fig2.png missing twice (reading other reviews i saw your note about this)

Chapter 3, "IIFE" section edits

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.

The book has a degrading title to its readers

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.

Chapter 1, "Scope Conversations" section edits

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?

Code missing in code snippet - Module section, Chapter 5

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
};

scope & closure technical review - [email protected]

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.

Ch 4 Functions First is a little confusing

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?

"types & grammar": cover (some) native functions and control flows

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

Chapter 1, "Building on Metaphors" section edits

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.

Copyright attribution isn't explicit

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.