You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 1-js/1-getting-started/1-intro/article.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -68,7 +68,7 @@ The examples of such restrictions are:
68
68
Modern browsers allow it to work with files, but the access is limited and only provided if the user does certain actions, like "dropping" a file into a browser window or selecting it via an `<input>` tag.
69
69
70
70
There are ways to interact with camera/microphone and other devices, but they require an explicit user's permission. So a JavaScript-enabled page may not sneakily enable a web-camera, observe the surroundings and send the information to the [NSA](https://en.wikipedia.org/wiki/National_Security_Agency).
71
-
- Different tabs/windows generally do not know about each other. Sometimes they do, for example when one window uses JavaScript to open the other one. Such action is allowed. But even in this case, JavaScript from one page may not access the other if they compe from different sites (from a different domain, protocol or port).
71
+
- Different tabs/windows generally do not know about each other. Sometimes they do, for example when one window uses JavaScript to open the other one. But even in this case, JavaScript from one page may not access the other if they compe from different sites (from a different domain, protocol or port).
72
72
73
73
That is called a "Same Origin Policy". To workaround that, *both pages* must contain a special JavaScript code that handles data exchange.
The code editor is the place where a programmer spends most his time.
4
+
5
+
There are two archetypes: IDE and lightweight editors. Many people feel comfortable choosing one tool of each type.
6
+
7
+
[cut]
8
+
9
+
## IDE
10
+
11
+
The term [IDE](https://en.wikipedia.org/wiki/Integrated_development_environment) (Integrated Development Environment) is a powerful editor with many additional features that usually operates on a "whole project".
12
+
13
+
An IDE loads the project (can be many files), and then allows navigate between files, provides autocompletion based on the whole project, does other "project-level" stuff.
14
+
15
+
If you haven't considered selecting an IDE, pleae look at the following variants:
16
+
17
+
- IntelliJ editors: [WebStorm](http://www.jetbrains.com/webstorm/) for frontend development and [PHPStorm (PHP)](http://www.jetbrains.com/phpstorm/), [IDEA (Java)](http://www.jetbrains.com/idea/), [RubyMine (Ruby)](http://www.jetbrains.com/ruby/) and other if you need additional languages.
18
+
- Visual Studio is fine if you're a .NET developer.
19
+
- Eclipse-based products, like [Aptana](http://www.aptana.com/) and Zend Studio.
20
+
-[Komodo IDE](http://www.activestate.com/komodo-ide) and it's lightweight free version [Komodo Edit](http://www.activestate.com/komodo-edit).
21
+
-[Netbeans](http://netbeans.org/)
22
+
23
+
All of them with the exception of Visual Studio are cross-platform.
24
+
25
+
Most IDEs are paid, but have a trial period. Their cost is usually negligible compared to a qualified developer's salary, so just choose the best one for you.
26
+
27
+
## Lightweight editors
28
+
29
+
"Lightweight editors" are not as powerful as IDEs, but they're fast, elegant and simple.
30
+
31
+
They are mainly used to instantly open and edit a file.
32
+
33
+
The main difference between a "lightweight editor" and an "IDE" is that the latter works on a project-level, meaning it has to load a lot of data to start, and the former one opens just the files. That's much faster.
34
+
35
+
In practice, "lightweight" editors may have a lot of plugins including directory-level syntax analyzers and autocompleters, so there's no strict border between a lightweight editor and an IDE.
- Vim, Emacs are cool. If you know how to use them.
43
+
44
+
## My favorites
45
+
46
+
I believe one should have both an IDE for projects and a lightweight editor for quick and easy file editing.
47
+
48
+
I'm using:
49
+
50
+
-[WebStorm](http://www.jetbrains.com/webstorm/) for JS, and if there is one more language in the project, then I switch to other Jetbrains editors like [PHPStorm](http://www.jetbrains.com/phpstorm/) (PHP), [IDEA](http://www.jetbrains.com/idea/) (Java), [RubyMine](http://www.jetbrains.com/ruby/) (Ruby). There are editors for other languages too, but I didn't use them.
51
+
- As a lightweight editor -- [Sublime Text](http://www.sublimetext.com).
52
+
53
+
If you don't know what to choose -- you can consider these ones.
54
+
55
+
## Let's not argue
56
+
57
+
The editors in the lists above are those that me or my friends -- good developers use for a long time and are happy with.
58
+
59
+
There are other great editors in our big world, please choose the one you like the most.
60
+
61
+
The choice of an editor, like any other tool, is individual and depends on your projects, habbits, personal preferences.
And the one more thing before we get down to coding.
4
+
5
+
A code is error-prone. You are quite likely to have errors... Oh what I'm talking? You are *absolutely* going to make errors, at least if you're a human, not a [robot](https://en.wikipedia.org/wiki/Bender_(Futurama)).
6
+
7
+
But in the browser, a user doesn't see the errors by default. So, if something goes wrong in the script, we won't see what's broken and can't fix it.
8
+
9
+
To see errors and get a lot of other useful information about scripts, browsers have embedded "developer tools".
10
+
11
+
**It is recommended to use Chrome or Firefox for the development.**
12
+
13
+
Other browsers also provide developer tools, but are usually in a "catching-up" position, compared to Chrome/Firefox which are the best.
14
+
15
+
If there is an error in the certain browser only, then we can use it's developer tools, but usually -- Chrome/Firefox.
16
+
17
+
Developer tools are really powerful, there are many features. On this stage let's just look how to open them, look at errors and run JavaScript commands.
18
+
19
+
[cut]
20
+
21
+
## Google Chrome
22
+
23
+
Open the page [bug.html](bug.html).
24
+
25
+
There's an error in the JavaScript code on it. It's hidden from a regular visitor's eyes, so let's open developer tools to see it.
26
+
27
+
Press the key `key:F12` or, if you're on Mac, then `key:Cmd+Opt+J`.
28
+
29
+
The developer tools will open on the Console tab by default.
30
+
31
+
It looks somewhat like this:
32
+
33
+
34
+
35
+
The exact look depends on your Chrome version. It changes from time to time, but should be similar.
36
+
37
+
- Here we can see the red-colored error message. In this case the script contains a "lalala" command, which was put there just because it is unknown.
38
+
- On the right, there is a clickable link to the source `bug.html:12` with the line number where the error has occured.
39
+
40
+
Below the error message there is a blue `>` symbol. It marks a "command line" where we can type JavaScript commands and press enter to run them (`key:Shift+Enter` to input multiline commands).
41
+
42
+
Now we can see errors and that's enough for the start. We'll be back to developer tools later and cover debugging more in-depth in the chapter <info:debugging-chrome>.
43
+
44
+
45
+
## Firefox, Edge and others
46
+
47
+
Most other browsers use `key:F12` to open developer tools.
48
+
49
+
The look & feel of them is quite similar, once we know how to use one of them (can start with Chrome), can easily switch to another.
50
+
51
+
## Safari
52
+
53
+
Safari (if you use Mac, not Windows/Linux) is a little bit special here. We need to enable the "Develop menu" first.
54
+
55
+
There's a checkbox for that at the bottom of the "Advanced" pane of the preferences:
56
+
57
+
58
+
59
+
Now `key:Cmd+Opt+C` can toggle the console. Also note that the new top menu item has appeared with many useful options.
60
+
61
+
## Summary
62
+
63
+
- Developer tools allow us to see errors, run commands, examine variables and much more.
64
+
- They can be opened with `key:F12` for most browsers under Windows. Chrome for Mac needs `key:Cmd+Opt+J`, Safari: `key:Cmd+Opt+C` (need to enable first).
65
+
66
+
Now we have the environment ready. In the next section we get down to JavaScript.
Copy file name to clipboardExpand all lines: 1-js/2-first-steps/01-hello-world/article.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ In this chapter we'll create a simple script and see it working.
7
7
## The "script" tag
8
8
9
9
```smart header="What if I want to move faster?"
10
-
In the case if the reader has developed with JavaScript already or has a lot of experience in another language, he can skip detailed explanatins and jump to <info:javascript-specials>. There he can find an essense of important features.
10
+
In the case if you've developed with JavaScript already or have a lot of experience in another language, you can skip detailed explanatins and jump to <info:javascript-specials>. There you can find an essense of important features.
11
11
12
12
If you have enough time and want to learn things in details then read on :)
Copy file name to clipboardExpand all lines: 1-js/2-first-steps/02-external-script/article.md
+30-30Lines changed: 30 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -90,7 +90,7 @@ For example, in the code below -- until all rabbits are counted, the bottom `<p>
90
90
91
91
The behavior is called "synchronous". Usually it causes no problems, but there's an important consequence.
92
92
93
-
**If the script is external, then until the browser executes it, it can't show the page below.**
93
+
**If a script is external, then until the browser downloads and executes it, a visitor has to wait.**
94
94
95
95
So, in this document, until `big.js` loads and executes, the `<body>` content is hidden:
96
96
@@ -107,21 +107,22 @@ So, in this document, until `big.js` loads and executes, the `<body>` content is
107
107
</html>
108
108
```
109
109
110
-
The question is -- do we really want to hide the body until the script finishes?
110
+
The question is -- do we really want the visitor to wait until the script finishes?
111
111
112
112
Most of time, we don't.
113
113
114
114
Sometimes, a script may contain a very important code that really must be loaded before the rest of the page is parsed (and the scripts below executed). But that's only sometimes.
115
115
116
-
Usually a visitor should see the page content while the script is loading.
116
+
Usually a visitor should be able to see the page while the script is loading. That's especially true for sites with an important content (like the tutorial) -- even if some interfaces are yet inactive (scripts not loaded yet), the visitor can read the text and navigate.
117
117
118
118
There are situations when such blocking is even dangerous. For example, when we attach a script from the banner system, or a 3rd-party integration code.
119
119
120
120
Like this:
121
121
122
122
```html run height=100
123
-
Wait. The text belown will shown up only after the script executes.
123
+
Wait. The text below will shown up only after the script executes.
@@ -135,8 +136,8 @@ Our first attempt could be to put all such scripts to the bottom of the `<body>`
135
136
136
137
But the solution is not perfect:
137
138
138
-
1. The script won't start loading until the whole page loads. If the page is large, then the delay may be significant. We'd like the browser to start loading a script early, but still do not block the page.
139
-
2. If there is more than one script at the bottom of the page, and the first script is slow, then the second one will have to wait for it. Browser executes only one `<script>` tag in one moment. So scripts queue one after another. That's not always welcome: ads and web analytics scripts should run immediately as they load.
139
+
1. The script won't start loading until the HTML loads. If the HTML is large, then the delay may be significant. We'd like the browser to start loading a script early, but still do not block the page.
140
+
2. If there are many scripts at the bottom of the page, then they queue up. Browser executes only one `<script>` tag in one moment. Please note that it tries to downloads scripts in parallel (for better network utilization), but the execution order is still strictly one after another. So, the first script can block the rest if it's slow. That's not always welcome: some scripts, like ads and web analytics scripts should run independantly and immediately as they load, not block each other.
140
141
141
142
And here come the attributes `async` and `defer`.
142
143
@@ -147,38 +148,27 @@ The `defer` attribute.
147
148
: The script with `defer` also executes asynchronously, like async. But there are two essential differences:
148
149
149
150
1. The browser guarantees to keep the relative order of "deferred" scripts.
150
-
2. A "deferred" script always executes after HTML-document is fully loaded.
151
-
152
-
We'll discuss them more in-depth further in this chapter.
153
-
154
-
```smart header="Either `async` or `defer`"
155
-
We can't use both `defer` and `async` on a single script. If we do that, `async` takes precedence, `defer` is ignored.
156
-
```
151
+
2. A "deferred" script always executes after the HTML-document is fully loaded.
157
152
158
-
```warn header="Attributes `async/defer` are only for external scripts"
159
-
The attributes `async/defer` work only when set on a script with `src`.
160
-
161
-
On a script without `src` like <code><script>...</script></code>, they will be ignored.
162
-
```
163
153
164
154
Let's modify the "blocking script" example that we've seen before, adding `async`:
165
155
166
156
```html run height=100
167
157
Wait. The text belown will shown up only after the script executes.
168
158
159
+
<!-- This banner script take some time to load... But nobody cares. -->
Now if we run it, we'll see that the whole document is displayed immediately, and the external script runs when it loads.
175
166
176
-
## Defer vs Async
167
+
Let's see more examples with `defer` and `async` to clearly understand the similarities and the differences.
177
168
178
-
Please note that there is one similarity and two differences between `defer` and `async`.
169
+
Both attributes allow the browser to show the page without waiting for the script to load. But...
179
170
180
-
1. **Both attributes allow the browser to show the page without waiting for the script to load.**
181
-
2. **Deferred scripts keep the relative order, while async scripts do not.**
171
+
1. Deferred scripts keep the relative order, while async scripts do not.
182
172
183
173
For example, in the code below (with `async`) there are two scripts. The one which loads first will run first.
184
174
@@ -198,7 +188,7 @@ Please note that there is one similarity and two differences between `defer` and
198
188
199
189
This feature of "deferred" scripts is important when `2.js` relies on the result of `1.js` and we must be sure that the order is determined.
200
190
201
-
3. **A script with `defer` always waits for the HTML-document to fully load. The `async` script runs immediately as it loads.**
191
+
2. A script with `defer` always waits for the HTML-document to fully load. The `async` script runs immediately as it loads.
202
192
203
193
For instance, when the document is large, like:
204
194
@@ -212,25 +202,35 @@ Please note that there is one similarity and two differences between `defer` and
212
202
213
203
...Here `async.js` executes when it loads -- possibly, before the document is fully loaded. In contrast, `defer.js` always waits for the full document to be ready.
214
204
215
-
The choice between `defer` and `async` here depends on our intentions. Sometimes a script doesn't need the document at all (like a web counter), so it should execute ASAP. In this case `async` is superb.
205
+
So, if a script doesn't need the rest of the document (like a web counter), then `async` is superb. And in another case a script may need the whole document to do some work with it. Then `defer` is preferable.
206
+
207
+
208
+
```smart header="Either `async` or `defer`"
209
+
We can't use both `defer` and `async` on a single script. If we do that, `async` takes precedence, `defer` is ignored.
210
+
```
211
+
212
+
```warn header="Attributes `async/defer` are only for external scripts"
213
+
The attributes `async/defer` work only when set on a script with `src`.
214
+
215
+
On a script without `src` like <code><script>...</script></code>, they will be ignored.
216
+
```
216
217
217
-
And in another case a script may need the whole document to do some work with it. Then `defer` is preferable.
218
218
219
219
## Summary
220
220
221
221
- Scripts in an external file can be inserted on the page via `<script src="path"></script>`.
222
-
- Normally, the browser doesn't show the document after the script until it executes. Unless the script has `async` or `defer` attributes.
222
+
- The browser doesn't show the content below the script until it executes. Unless the script has `async` or `defer` attributes.
223
223
- Both `async` and `defer` allow the browser to start script loading and then continue to parse/show the page. They only work on external scripts.
224
224
- The difference is that `defer` keeps the relative script order and always executes after the document is fully loaded. In contrast, `async` script executes when it loads, without any conditions.
225
225
226
226
Before inserting an external `<script src="…">` tag, we should always consider the side-effect of blocking the page rendering. Especially if it's a 3rd-party script. And if we don't want that, then `defer/async` can come in handy.
227
227
228
228
````smart header="Running ahead..."
229
-
For an advanced reader who knows that new tags can be added on page dynamically, we'd like to note that dynamic `<script>` tags behave as `async`. In other words, they run as they load.
229
+
For an advanced reader who already knows how to add new tags on the page using DOM: dynamic `<script>` tags behave as `async`. In other words, they run as they load, independantly.
230
230
231
-
But we can change that. If we set `script.async = false`, then such scripts are run in the load of insertion.
231
+
But we can adjust that. If we set `script.async = false`, then such scripts are run in the load of insertion. That's a way to keep the relative order for dynamically added tags.
232
232
233
-
The code example:
233
+
For example:
234
234
```js
235
235
function addScript(src){
236
236
let script = document.createElement('script');
@@ -246,6 +246,6 @@ addScript('2.js'); // but execute in the order of insertion
246
246
addScript('3.js'); // that is: 1 -> 2 -> 3
247
247
```
248
248
249
-
We'll cover page dynamic tags and page manipulation in detail later, in the second part of the tutorial.
249
+
We'll surely cover dynamic tags and page manipulation in detail later, in the second part of the tutorial.
0 commit comments