Skip to content
Permalink
Browse files

get started: more editorial tweaks, per #1565

  • Loading branch information
getify committed Dec 12, 2019
1 parent ed69b7d commit 58bc2ec2ebee732c46d5e4d2a8a0ede25a94f7a4
Showing with 14 additions and 16 deletions.
  1. +2 −2 get-started/apA.md
  2. +3 −3 get-started/ch1.md
  3. +3 −3 get-started/ch2.md
  4. +4 −6 get-started/ch3.md
  5. +1 −1 get-started/ch4.md
  6. +1 −1 preface.md
@@ -1,7 +1,7 @@
# You Don't Know JS Yet: Get Started - 2nd Edition
# Appendix B: Exploring Further
# Appendix A: Exploring Further

In this appendix, we're going to explore some topics from the main chapter text in a bit more detail.
In this appendix, we're going to explore some topics from the main chapter text in a bit more detail. Think of this content as an optional preview of some of the more nuanced details covered throughout the rest of the book series.

## Values vs References

@@ -15,7 +15,7 @@ Following this background chapter, the rest of the book lays out a high-level ma

In particular, Chapter 4 identifies three main pillars around which the JS language is organized: scope/closures, prototypes/objects, and types/coercion. JS is a broad and sophisticated language, with many features and capabilities. But all of JS is founded on these three foundational pillars.

Keep in mind that even though this book is titled "Getting Started", it's **not intended as a beginner/intro book**. This book's main job is to get you ready for studying JS deeply throughout the rest of the series; it's written assuming you already have familiarity with JS over at least several months experience before moving on in YDKJSY. So to get the most out *Getting Started*, make sure you spend plenty of time writing JS code to build up your experience.
Keep in mind that even though this book is titled "Get Started", it's **not intended as a beginner/intro book**. This book's main job is to get you ready for studying JS deeply throughout the rest of the series; it's written assuming you already have familiarity with JS over at least several months experience before moving on in YDKJSY. So to get the most out *Get Started*, make sure you spend plenty of time writing JS code to build up your experience.

Even if you've already written a lot of JS before, this book should not be skimmed over or skipped; take your time to fully process the material here. **A good start always depends on a solid first step.**

@@ -53,7 +53,7 @@ Whether you call it JavaScript, JS, ECMAScript, or ES2019, it's most definitely
## Language Specification

I mentioned TC39, the technical steering committee that manages JS. They are primarily tasked with managing the official specification for the language. They meet regularly to vote on any agreed changes, which they then submit to ECMA, the standards organization.
I mentioned TC39, the technical steering committee that manages JS. Their primary task is managing the official specification for the language. They meet regularly to vote on any agreed changes, which they then submit to ECMA, the standards organization.

JS's syntax and behavior are defined in the ES specification.

@@ -127,7 +127,7 @@ So an `alert(..)` call *is* JS, but `alert` itself is really just a guest, not p

### It's Not Always JS

Using the console/REPL (Read-Evaluate-Print-Loop) in your browser's Developer Tools feels like a pretty straightforward JS environment at first glance. But it's not, really.
Using the console/REPL (Read-Evaluate-Print-Loop) in your browser's Developer Tools (or Node) feels like a pretty straightforward JS environment at first glance. But it's not, really.

Developer Tools are... tools for developers. Their primary purpose is to make life easier for developers. They prioritize DX (Developer Experience). It is *not* a goal of such tools to accurately and purely reflect all nuances of strict-spec JS behavior. As such, there's many quirks that may act as "gotchas" if you're treating the console as a *pure* JS environment.

@@ -137,11 +137,11 @@ names[1];
// Kyle
```

JS arrays can hold any value type, either primitive or object (including other arrays).
JS arrays can hold any value type, either primitive or object (including other arrays). As we'll see towards the end of Chapter 3, even functions are values that can be held in arrays or objects.

| NOTE: |
| :--- |
| Another entity you'll encounter in JS programs that, like arrays, is a special kind of object is a function. We'll cover these in more detail in a bit. |
| Functions, like arrays, are a special kind (aka, sub-type) of object. We'll cover functions in more detail in a bit. |

Objects are more general: an unordered, keyed collection of any various values. In other words, you access the element by a string location name (aka "key" or "property") rather than by its numeric position (as with arrays). For example:

@@ -750,7 +750,7 @@ The `class` form stores methods and data on an object instance, which must be ac

With `class`, the "API" of an instance is implicit in the class definition -- also, all data and methods are public. With the module factory function, you explicitly create and return an object with any publicly exposed methods, and any data or other unreferenced methods remain private inside the factory function.

There are other variations to this factory function form that are quite common across JS, even in 2019; you may run across these forms in different JS programs: AMD ("Asynchronous Module Definition"), UMD ("Universal Module Definition"), and CommonJS (classic Node.js style modules). The variations are minor, though. All of these forms rely on the same basic principles.
There are other variations to this factory function form that are quite common across JS, even in 2019; you may run across these forms in different JS programs: AMD ("Asynchronous Module Definition"), UMD ("Universal Module Definition"), and CommonJS (classic Node.js style modules). The variations, however, are minor (yet not quite compatible). Still, all of these forms rely on the same basic principles.

Consider also the usage (aka, "instantiation") of these module factory functions:

@@ -3,17 +3,15 @@

If you've read Chapters 1 and 2, and taken the time to digest and percolate, you're hopefully starting to *get* JS a little more. If you skipped/skimmed them (especially Chapter 2), I recommend you consider going back to spend some more time with that material.

In Chapter 2, our focus was on syntax, patterns, and behaviors. Here, our attention shifts to some of the lower-level root characteristics of JS that underpin virtually every line of code we write.
In Chapter 2, we surveyed syntax, patterns, and behaviors at a high level. In this chapter, our attention shifts to some of the lower-level root characteristics of JS that underpin virtually every line of code we write.

It should be noted that this material is still not an exhaustive exposition of JS; that's what the rest of the book series is for! Here, our goal is still just to *get started*, and more comfortable with, the *feel* of JS, how it ebbs and flows.
Be aware: this chapter digs much deeper than you're likely used to thinking about a programming language. My goal is to help you appreciate the core of how JS works, what makes it tick. This chapter should begin to answer some of the "Why?" questions that are may be cropping up as you explore JS. However, this material is still not an exhaustive exposition of the language; that's what the rest of the book series is for! Our goal here is still just to *get started*, and become more comfortable with, the *feel* of JS, how it ebbs and flows.

Be aware: this chapter digs much deeper than you're likely used to thinking about a programming language. My goal is to help you appreciate the core of how JS works, what makes it tick. This chapter will begin to answer some of the "Why?" questions that are may be cropping up as you explore JS.

Don't go so quickly through this material that you get lost in the weeds. As I've said a dozen times already, **take your time**. Even still, you'll probably finish this chapter with remaining questions. That's OK, though, because there's a whole book series ahead of you to explore!
Don't run so quickly through this material that you get lost in the weeds. As I've said a dozen times already, **take your time**. Even still, you'll probably finish this chapter with remaining questions. That's OK, because there's a whole book series ahead of you keep exploring!

## Iteration

Since programs are essentially built to process data (and make decisions on that data), the patterns used to step through the data has a big impact on the program's readability.
Since programs are essentially built to process data (and make decisions on that data), the patterns used to step through the data have a big impact on the program's readability.

The iterator pattern has been around for decades, and suggests a "standardized" approach to consuming data from a source one *chunk* at a time. The idea is that it's more common and helpful iterate the data source -- to progressively handle the collection of data by processing the first part, then the next, and so on, rather than handling the entire set all at once.

@@ -35,7 +35,7 @@ To dig further into scope, closures, and how modules work, read Book 2, *Scope &

The second pillar of the language is the prototypes system. We covered this topic in-depth in Chapter 3 ("Prototypes"), but I just want to make a few more comments about its importance.

JS is one of very few languages where you have the option to create objects bespoke, without any need for defining their structure in a class first.
JS is one of very few languages where you have the option to create objects directly and explicitly, without first defining their structure in a class.

For many years, people implemented the class design pattern on top of prototypes -- so called, "prototypal inheritance" (see Appendix A) -- and then with the advent of ES6's `class` keyword, the language doubled-down on its inclination towards OO/class style programming.

@@ -11,7 +11,7 @@ If you are new to programming or JS, please be aware that these books are not in

## The Parts

These books approach JavaScript intentionally the opposite of *The Good Parts*. No, not *the bad parts*, but rather, focused on **all the parts**.
These books approach JavaScript intentionally opposite of how *The Good Parts* treats the language. No, that doesn't mean we're looking at *the bad parts*, but rather, exploring **all the parts**.

You may have been told, or felt yourself, that JS is a deeply flawed language that was poorly designed and inconsistently implemented. Many have asserted that it's the worst most popular language in the world; that nobody writes JS because they want to, only because they have to given its place at the center of the web. That's a ridiculous, unhealthy, and wholly condescending claim.

0 comments on commit 58bc2ec

Please sign in to comment.
You can’t perform that action at this time.