fixes

1-js/13-modules/02-import-export/article.md

@@ -103,7 +103,7 @@ Well, there are few reasons.
     export function becomeSilent() { ... }
     ```
 
-    Now if we in fact need only one of them in our project:
+    Now if we only use one of `lib.js` functions in our project:
     ```js
     // 📁 main.js
     import {sayHi} from './lib.js';
@@ -218,8 +218,7 @@ export default function(user) { // no function name
 export default ['Jan', 'Feb', 'Mar','Apr', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'];
 ```
 
-That's fine, because `export default` is only one per file, so `import` always knows what to import.
+That's fine, because `export default` is only one per file. Contrary to that, omitting a name for named imports would be an error:
- Contrary to that, omitting a name for named imports would be an error:
 
 ```js
 export class { // Error! (non-default export needs a name)
@@ -229,9 +228,9 @@ export class { // Error! (non-default export needs a name)
 
 ### "Default" alias
 
-The "default" word is a kind of "alias" for the default export, for scenarios when we need to reference it somehow.
+The "default" keyword is used as an "alias" for the default export, for standalone exports and other scenarios when we need to reference it.
 
-For example, if we already have a function declared, that's how to `export default` it:
+For example, if we already have a function declared, that's how to `export default` it (separately from the definition):
 
 ```js
 function sayHi(user) {
@@ -278,7 +277,7 @@ new User('John');
 
 ### Should I use default exports?
 
-One should be careful about using default exports, because they are somewhat more different to maintain.
+One should be careful about using default exports, because they are more difficult to maintain.
 
 Named exports are explicit. They exactly name what they import, so we have that information from them, that's a good thing.
 
@@ -286,12 +285,15 @@ Also, named exports enforce us to use exactly the right name to import:
 
 ```js
 import {User} from './user.js';
+// import {MyUser} won't work, the name must be {User}
 ```
 
-For default exports, we need to create a name on our own:
+For default exports, we always choose the name when importing:
 
 ```js
-import MyUser from './user.js'; // could be import Anything..., and it'll work
+import User from './user.js'; // works
+import MyUser from './user.js'; // works too
+// could be import Anything..., and it'll be work
 ```
 
 So, there's a little bit more freedom that can be abused, so that team members may use different names for the same thing.
@@ -409,16 +411,18 @@ Import:
   - `import {default as x} from "mod"`
 - Everything:
   - `import * as obj from "mod"`
-- Only fetch/evaluate the module, don't import:
+- Import the module (it runs), but do not assign it to a variable:
   - `import "mod"`
 
-We can put import/export statements below or after other code, that doesn't matter.
+We can put import/export statements at the top or at the bottom of a script, that doesn't matter.
 
 So this is technically fine:
 ```js
 sayHi();
 
-import {sayHi} from './say.js'; // import at the end of the file
+// ...
+
+import {sayHi} from './say.js'; // import at the end of the script
 ```
 
 In practice imports are usually at the start of the file, but that's only for better convenience.

2-ui/2-events/01-introduction-browser-events/article.md

@@ -160,9 +160,9 @@ button.onclick = sayThanks;
 button.onclick = sayThanks();
 ```
 
-If we add brackets, then `sayThanks()` --  will be the *result* of the function execution, so `onclick` in the last code becomes `undefined` (the function returns nothing). That won't work.
+If we add parentheses, `sayThanks()` --  is a function call. So the last line actually takes the *result* of the function execution, that is `undefined` (as the function returns nothing), and assigns it to `onclick`. That doesn't work.
 
-...But in the markup we do need the brackets:
+...But in the markup we do need the parentheses:
 
 ```html
 <input type="button" id="button" onclick="sayThanks()">
@@ -351,7 +351,7 @@ Some properties of `event` object:
 : Event type, here it's `"click"`.
 
 `event.currentTarget`
-: Element that handled the event. That's exactly the same as `this`, unless you bind `this` to something else, and then `event.currentTarget` becomes useful.
+: Element that handled the event. That's exactly the same as `this`, unless the handler is an arrow function, or its `this` is bound to something else, then `event.currentTarget` becomes useful.
 
 `event.clientX / event.clientY`
 : Window-relative coordinates of the cursor, for mouse events.