diff --git a/1-js/10-modules/01-modules-intro/article.md b/1-js/10-modules/01-modules-intro/article.md
new file mode 100644
index 00000000..c67c0c1d
--- /dev/null
+++ b/1-js/10-modules/01-modules-intro/article.md
@@ -0,0 +1,318 @@
+
+# Modules, the introduction
+
+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.
+
+But eventually scripts became more and more complex, so the community invented a variety of ways to organize code into modules.
+
+For instance:
+
+- [AMD](https://en.wikipedia.org/wiki/Asynchronous_module_definition) -- one of the most ancient module systems, initially implemented by the library [require.js](http://requirejs.org/).
+- [CommonJS](http://wiki.commonjs.org/wiki/Modules/1.1) -- the module system created for Node.JS server.
+- [UMD](https://github.com/umdjs/umd) -- one more module system, suggested as a universal one, compatible with AMD and CommonJS.
+
+Now all these slowly become a part of history, but we still can find them in old scripts. The language-level module system appeared in the standard in 2015, gradually evolved since then, and is now supported by all major browsers and in Node.js.
+
+## What is a module?
+
+A module is just a file, a single script, as simple as that.
+
+Directives `export` and `import` allow to interchange functionality between modules:
+
+- `export` keyword labels variables and functions that should be accessible from outside the file.
+- `import` allows to import functionality from other modules.
+
+For instance, if we have a file `sayHi.js` exporting a function:
+
+```js
+// π sayHi.js
+export function sayHi(user) {
+ alert(`Hello, ${user}!`);
+}
+```
+
+...Then another file may import and use it:
+
+```js
+// π main.js
+import {sayHi} from './sayHi.js';
+
+alert(sayHi); // function...
+sayHi('John'); // Hello, John!
+```
+
+## Modules in the browser
+
+In this tutorial we concentrate on the language itself, but we use browser as the demo environment, so let's see how modules work in the browser.
+
+To use modules, we must set the attribute `
+ ```
+
+ That ensures better security by default.
+
+2. External scripts with same `src` run only once:
+ ```html
+
+
+
+ ```
+
+3. Module scripts are *always* deferred, same effect as `defer` attribute (described in the chapter [](info:onload-ondomcontentloaded)), for both external and inline scripts.
+
+ In other words:
+ - external module scripts `
+
+
+
+
+ ```
+
+ So, when we're using modules, we should be aware that HTML-document can show up before the Javascript application is ready. Certain 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.
+
+4. Async attribute `
+ ```
+
+Also, in the browser, in scripts (not in HTML), `import` must get either a relative or absolute URL. So-called "bare" modules (without path) are not allowed.
+
+For instance, this `import` is invalid:
+```js
+import {sayHi} from 'sayHi'; // Error, "bare" module
+// must be './sayHi.js' or wherever the module is
+```
+
+Certain environments, like Node.js or bundle tools allow bare modules, as they have own ways for finding modules and hooks to fine-tune them. But browsers do not support bare modules yet.
+
+### Build tools
+
+In real-life, browser modules are rarely used in their "raw" form. Usually, we bundle them together with a special tool such as [Webpack](https://webpack.js.org/) and deploy to the production server.
+
+One of the benefits of using bundlers -- they give more control over how modules are resolved, allowing bare modules and much more, like CSS/HTML modules.
+
+Build tools do the following:
+
+1. Take a "main" module, the one intended to be put in `
+
+
+```
+
+If we use bundle tools, then as modules are bundled together, their `import/export` statements are replaced by special bundler calls, so the resulting build does not require `type="module"`, and we can put it into a regular script:
+
+```html
+
+
+```
+
+
+## Core module features
+
+In the previous section we covered browser-specific features. Now it should be easy to start using modules in the browser.
+
+There are other module features, not bound to the host environment, valid both for browser and Node.js.
+
+### Always "use strict"
+
+Modules always `use strict`. E.g. assigning to an undeclared variable will give an error.
+
+```html run
+
+```
+
+Here we can see it in the browser, but the same is true for any module.
+
+### Module-level scope
+
+Each module has its own top-level scope. In other words, top-level variables and functions from a module are not seen in other scripts. Modules are expected to `export` what they want to be accessible from outside.
+
+Independant top-level scope exists for `
+
+
+```
+
+If we really need to share the variable, we can explicitly assign it to `window.user`. But that's an exception requiring a good reason.
+
+### A module code is evaluated only the first time when imported
+
+If a same module is imported into multiple other places, it's code is executed only the first time, then exports are given to all importers.
+
+That has important consequences. Let's see that on examples.
+
+First, if executing a module code brings side-effects, like showing a message, then importing it multiple times will trigger it only once -- the first time:
+
+```js
+// π alert.js
+alert("Module is evaluated!");
+```
+
+```js
+// Import the same module from different files
+
+// π 1.js
+import `./alert.js`; // Module is evaluated!
+
+// π 2.js
+import `./alert.js`; // (nothing)
+```
+
+In practice, top-level module code is mostly used for initialization. We create data structures, pre-fill them, and if we want something to be reusable -- export it.
+
+Now, a more advanced example.
+
+Let's say, a module exports an object:
+
+```js
+// π admin.js
+export let admin = {
+ name: "John"
+};
+```
+
+If this module is imported from multiple files, the module is only evaluated the first time, `admin` object is created, and then passed to all further importers.
+
+All importers get exactly the one and only `admin` object:
+
+```js
+// π 1.js
+import {admin} from './admin.js';
+admin.name = "Pete";
+
+// π 2.js
+import {admin} from './admin.js';
+alert(admin.name); // Pete
+
+*!*
+// Both 1.js and 2.js imported the same object
+// Changes made in 1.js are visible in 2.js
+*/!*
+```
+
+So, let's reiterate -- the module is executed only once. Exports are generated, and then they are shared between importers, so if something changes the `admin` object, other modules will see that .
+
+Such behavior is great for modules that require configuration. We can set required properties on the first import, and then in further imports it's ready.
+
+For instance, `admin.js` module may provide certain functionality, but expect the credentials to come into the `admin` object from outside:
+
+```js
+// π admin.js
+export let admin = { };
+
+export function sayHi() {
+ alert(`Ready to serve, ${admin.name}!`);
+}
+```
+
+Now, in `init.js`, the first script of our app, we set `admin.name`. Then everyone will see it, including calls made from inside `admin.js` itself:
+
+```js
+// π init.js
+import {admin} from './admin.js';
+admin.name = "Pete";
+```
+
+```js
+// π other.js
+import {admin, sayHi} from './admin.js';
+
+alert(admin.name); // *!*Pete*/!*
+
+sayHi(); // Ready to serve, *!*Pete*/!*!
+```
+
+## Summary
+
+To summarize, the core concepts are:
+
+1. A module is a file. To make `import/export` work, browsers need `
+
+
+