Fix name of JavaScript

This commit is contained in:
Alexey Pyltsyn 2019-04-23 11:51:28 +03:00
parent 3b14ed8185
commit c5ce5578fc
32 changed files with 61 additions and 61 deletions

View file

@ -45,7 +45,7 @@ The engine applies optimizations at each step of the process. It even watches th
Modern JavaScript is a "safe" programming language. It does not provide low-level access to memory or CPU, because it was initially created for browsers which do not require it.
Javascript's capabilities greatly depend on the environment it's running in. For instance, [Node.JS](https://wikipedia.org/wiki/Node.js) supports functions that allow JavaScript to read/write arbitrary files, perform network requests, etc.
JavaScript's capabilities greatly depend on the environment it's running in. For instance, [Node.JS](https://wikipedia.org/wiki/Node.js) supports functions that allow JavaScript to read/write arbitrary files, perform network requests, etc.
In-browser JavaScript can do everything related to webpage manipulation, interaction with the user, and the webserver.
@ -88,7 +88,7 @@ There are at least *three* great things about JavaScript:
+ Simple things are done simply.
+ Support by all major browsers and enabled by default.
```
Javascript is the only browser technology that combines these three things.
JavaScript is the only browser technology that combines these three things.
That's what makes JavaScript unique. That's why it's the most widespread tool for creating browser interfaces.

View file

@ -221,7 +221,7 @@ function sayHiBye(firstName, lastName) {
}
```
Here the *nested* function `getFullName()` is made for convenience. It can access the outer variables and so can return the full name. Nested functions are quite common in Javascript.
Here the *nested* function `getFullName()` is made for convenience. It can access the outer variables and so can return the full name. Nested functions are quite common in JavaScript.
What's much more interesting, a nested function can be returned: either as a property of a new object (if the outer function creates an object with methods) or as a result by itself. It can then be used somewhere else. No matter where, it still has access to the same outer variables.
@ -473,7 +473,7 @@ The code outside of the block (or inside another script) doesn't see variables i
### IIFE
In the past, there were no block-level lexical environment in Javascript.
In the past, there were no block-level lexical environment in JavaScript.
So programmers had to invent something. And what they did is called "immediately-invoked function expressions" (abbreviated as IIFE).

View file

@ -79,7 +79,7 @@ No, it's not, because it may lead to naming conflicts: the same variable name ca
As of now, the multi-purpose `window` is considered a design mistake in the language.
Luckily, there's a "road out of hell", called "Javascript modules".
Luckily, there's a "road out of hell", called "JavaScript modules".
If we set `type="module"` attribute on a `<script>` tag, then such script is considered a separate "module" with its own top-level scope (lexical environment), not interfering with `window`.

View file

@ -3,7 +3,7 @@
In the first chapter of this section, we mentioned that there are modern methods to setup a prototype.
The `__proto__` is considered outdated and somewhat deprecated (in browser-only part of the Javascript standard).
The `__proto__` is considered outdated and somewhat deprecated (in browser-only part of the JavaScript standard).
The modern methods are:
@ -81,7 +81,7 @@ Why was `__proto__` replaced by the functions? That's an interesting question, r
```warn header="Don't reset `[[Prototype]]` unless the speed doesn't matter"
Technically, we can get/set `[[Prototype]]` at any time. But usually we only set it once at the object creation time, and then do not modify: `rabbit` inherits from `animal`, and that is not going to change.
And JavaScript engines are highly optimized to that. Changing a prototype "on-the-fly" with `Object.setPrototypeOf` or `obj.__proto__=` is a very slow operation, it breaks internal optimizations for object property access operations. So evade it unless you know what you're doing, or Javascript speed totally doesn't matter for you.
And JavaScript engines are highly optimized to that. Changing a prototype "on-the-fly" with `Object.setPrototypeOf` or `obj.__proto__=` is a very slow operation, it breaks internal optimizations for object property access operations. So evade it unless you know what you're doing, or JavaScript speed totally doesn't matter for you.
```
## "Very plain" objects

View file

@ -68,7 +68,7 @@ So, what exactly is a `class`? That's not an entirely new language-level entity
Let's unveil any magic and see what a class really is. That'll help in understanding many complex aspects.
In Javascript, a class is a kind of a function.
In JavaScript, a class is a kind of a function.
Here, take a look:

View file

@ -55,9 +55,9 @@ In JavaScript, there are three types of properties and members:
In many other languages there also exist "protected" fields: accessible only from inside the class and those extending it. They are also useful for the internal interface. They are in a sense more widespread than private ones, because we usually want inheriting classes to gain access to properly do the extension.
Protected fields are not implemented in Javascript on the language level, but in practice they are very convenient, so they are emulated.
Protected fields are not implemented in JavaScript on the language level, but in practice they are very convenient, so they are emulated.
In the next step we'll make a coffee machine in Javascript with all these types of properties. A coffee machine has a lot of details, we won't model them to stay simple (though we could).
In the next step we'll make a coffee machine in JavaScript with all these types of properties. A coffee machine has a lot of details, we won't model them to stay simple (though we could).
## Protecting "waterAmount"
@ -186,7 +186,7 @@ So protected fields are naturally inheritable. Unlike private ones that we'll se
[recent browser=none]
There's a finished Javascript proposal, almost in the standard, that provides language-level support for private properties and methods.
There's a finished JavaScript proposal, almost in the standard, that provides language-level support for private properties and methods.
Privates should start with `#`. They are only accessible from inside the class.
@ -325,6 +325,6 @@ Hiding complexity
To hide internal interface we use either protected or public properties:
- Protected fields start with `_`. That's a well-known convention, not enforced at the language level. Programmers should only access a field starting with `_` from its class and classes inheriting from it.
- Private fields start with `#`. Javascript makes sure we only can access those from inside the class.
- Private fields start with `#`. JavaScript makes sure we only can access those from inside the class.
Right now, private fields are not well-supported among browsers, but can be polyfilled.

View file

@ -30,7 +30,7 @@ As said in the [specification](https://tc39.github.io/ecma262/#sec-jobs-and-job-
- The queue is first-in-first-out: tasks enqueued first are run first.
- Execution of a task is initiated only when nothing else is running.
Or, to say that simply, when a promise is ready, its `.then/catch/finally` handlers are put into the queue. They are not executed yet. Javascript engine takes a task from the queue and executes it, when it becomes free from the current code.
Or, to say that simply, when a promise is ready, its `.then/catch/finally` handlers are put into the queue. They are not executed yet. JavaScript engine takes a task from the queue and executes it, when it becomes free from the current code.
That's why "code finished" in the example above shows first.
@ -54,7 +54,7 @@ Now the order is as intended.
## Event loop
In-browser Javascript, as well as Node.js, is based on an *event loop*.
In-browser JavaScript, as well as Node.js, is based on an *event loop*.
"Event loop" is a process when the engine sleeps and waits for events, then reacts on those and sleeps again.

View file

@ -12,7 +12,7 @@ async function f() {
}
```
The word "async" before a function means one simple thing: a function always returns a promise. Even If a function actually returns a non-promise value, prepending the function definition with the "async" keyword directs Javascript to automatically wrap that value in a resolved promise.
The word "async" before a function means one simple thing: a function always returns a promise. Even If a function actually returns a non-promise value, prepending the function definition with the "async" keyword directs JavaScript to automatically wrap that value in a resolved promise.
For instance, the code above returns a resolved promise with the result of `1`, let's test it:

View file

@ -5,7 +5,7 @@ There are many areas where we need random data.
One of them is testing. We may need random data: text, numbers etc, to test things out well.
In Javascript, we could use `Math.random()`. But if something goes wrong, we'd like to be able to repeat the test, using exactly the same data.
In JavaScript, we could use `Math.random()`. But if something goes wrong, we'd like to be able to repeat the test, using exactly the same data.
For that, so called "seeded pseudo-random generators" are used. They take a "seed", the first value, and then generate next ones using a formula. So that the same seed yields the same sequence, and hence the whole flow is easily reproducible. We only need to remember the seed to repeat it.

View file

@ -462,7 +462,7 @@ If we don't catch the error there, then, as usual, it falls through to the outer
- Inside generators (only) there exists a `yield` operator.
- The outer code and the generator may exchange results via `next/yield` calls.
In modern Javascript, generators are rarely used. But sometimes they come in handy, because the ability of a function to exchange data with the calling code during the execution is quite unique.
In modern JavaScript, generators are rarely used. But sometimes they come in handy, because the ability of a function to exchange data with the calling code during the execution is quite unique.
Also, in the next chapter we'll learn async generators, which are used to read streams of asynchronously generated data in `for` loop.

View file

@ -130,7 +130,7 @@ That's natural, as it expects to find `Symbol.iterator`, same as `for..of` witho
## Async generators
Javascript also provides generators, that are also iterable.
JavaScript also provides generators, that are also iterable.
Let's recall a sequence generator from the chapter [](info:generators). It generates a sequence of values from `start` to `end` (could be anything else):
@ -358,4 +358,4 @@ In web-development we often meet streams of data, when it flows chunk-by-chunk.
We could use async generators to process such data, but there's also another API called Streams, that may be more convenient, as it provides special interfaces to transform the data and to pass it from one stream to another (e.g. download from one place and immediately send elsewhere). But they are also more complex.
Streams API not a part of Javascript language standard. Streams and async generators complement each other, both are great ways to handle async data flows.
Streams API not a part of JavaScript language standard. Streams and async generators complement each other, both are great ways to handle async data flows.

View file

@ -4,7 +4,7 @@
As our application grows bigger, we want to split it into multiple files, so called 'modules'.
A module usually contains a class or a library of useful functions.
For a long time, Javascript existed without a language-level module syntax. That wasn't a problem, because initially scripts were small and simple. So there was no need.
For a long time, JavaScript existed without a language-level module syntax. That wasn't a problem, because initially scripts were small and simple. So there was no need.
But eventually scripts became more and more complex, so the community invented a variety of ways to organize code into modules.
@ -56,7 +56,7 @@ The browser automatically fetches and evaluates imports, then runs the script.
What's different in modules, compared to "regular" scripts?
There are core features, valid both for browser and server-side Javascript.
There are core features, valid both for browser and server-side JavaScript.
### Always "use strict"
@ -222,7 +222,7 @@ In a module, top-level `this` is undefined, as opposed to a global object in non
There are also several browser-specific differences of scripts with `type="module"` compared to regular ones.
You may want skip those for now if you're reading for the first time, or if you don't use Javascript in a browser.
You may want skip those for now if you're reading for the first time, or if you don't use JavaScript in a browser.
### Module scripts are deferred
@ -259,7 +259,7 @@ Please note: the second script actually works before the first! So we'll see `un
That's because modules are deferred, so way wait for the document to be processed. The regular scripts runs immediately, so we saw its output first.
When using modules, we should be aware that HTML-document can show up before the Javascript application is ready. Some functionality may not work yet. We should put transparent overlays or "loading indicators", or otherwise ensure that the visitor won't be confused because of it.
When using modules, we should be aware that HTML-document can show up before the JavaScript application is ready. Some functionality may not work yet. We should put transparent overlays or "loading indicators", or otherwise ensure that the visitor won't be confused because of it.
### Async works on inline scripts
@ -350,7 +350,7 @@ Build tools do the following:
- Unreachable code removed.
- Unused exports removed ("tree-shaking").
- Development-specific statements like `console` and `debugger` removed.
- Modern, bleeding-edge Javascript syntax may be transformed to older one with similar functionality using [Babel](https://babeljs.io/).
- Modern, bleeding-edge JavaScript syntax may be transformed to older one with similar functionality using [Babel](https://babeljs.io/).
- The resulting file is minified (spaces removed, variables replaced with shorter named etc).
That said, native modules are also usable. So we won't be using Webpack here: you can configure it later.

View file

@ -29,7 +29,7 @@ For instance, here all exports are valid:
````smart header="No semicolons after export class/function"
Please note that `export` before a class or a function does not make it a [function expression](info:function-expressions-arrows). It's still a function declaration, albeit exported.
Most Javascript style guides recommend semicolons after statements, but not after function and class declarations.
Most JavaScript style guides recommend semicolons after statements, but not after function and class declarations.
That's why there should be no semicolons at the end of `export class` and `export function`.