From ea50b975eecd749ea5da2316a6ba01c89330a5db Mon Sep 17 00:00:00 2001
From: Prasit Tongpradit <prasit_tongpradit@windowslive.com>
Date: Sat, 18 Apr 2026 12:37:57 +0700
Subject: [PATCH] docs: translate modules section (3 articles)

---
 1-js/13-modules/01-modules-intro/article.md   | 314 +++++++++---------
 .../01-modules-intro/say.view/say.js          |   2 +-
 .../01-modules-intro/scopes.view/hello.js     |   2 +-
 1-js/13-modules/02-import-export/article.md   | 240 +++++++------
 .../03-modules-dynamic-imports/article.md     |  54 ++-
 .../say.view/index.html                       |   8 +-
 .../say.view/say.js                           |   6 +-
 1-js/13-modules/index.md                      |   2 +-
 8 files changed, 312 insertions(+), 316 deletions(-)

diff --git a/1-js/13-modules/01-modules-intro/article.md b/1-js/13-modules/01-modules-intro/article.md
index 5ad70d151..74d8b1781 100644
--- a/1-js/13-modules/01-modules-intro/article.md
+++ b/1-js/13-modules/01-modules-intro/article.md
@@ -1,75 +1,75 @@
 
-# Modules, introduction
+# โมดูล — บทนำ
 
-As our application grows bigger, we want to split it into multiple files, so called "modules". A module may contain a class or a library of functions for a specific purpose.
+แอปที่ใหญ่ขึ้นเรื่อยๆ จัดการยังไงดี? แตกโค้ดออกเป็นหลายไฟล์ไง — ไฟล์พวกนี้แหละที่เรียกว่า "โมดูล" แต่ละโมดูลอาจเก็บคลาส หรือชุดฟังก์ชันที่ทำงานด้านใดด้านหนึ่งโดยเฉพาะ
 
-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.
+ย้อนไปไกลๆ JavaScript ไม่มี module syntax ในตัวภาษาเลย แต่ก็ไม่ใช่ปัญหา เพราะสมัยนั้นสคริปต์เล็กและง่ายมาก ไม่มีความจำเป็น
 
-But eventually scripts became more and more complex, so the community invented a variety of ways to organize code into modules, special libraries to load modules on demand.
+แต่พอสคริปต์โตขึ้นเรื่อยๆ ชุมชน developer ก็เลยประดิษฐ์ระบบจัดการโมดูลกันเอง — มีหลายแบบด้วย ทั้งไลบรารีพิเศษสำหรับโหลดโมดูลตามต้องการ
 
-To name some (for historical reasons):
+ระบบโมดูลที่เคยดังในอดีต (เล่าไว้เพื่อความรู้):
 
-- [AMD](https://en.wikipedia.org/wiki/Asynchronous_module_definition) -- one of the most ancient module systems, initially implemented by the library [require.js](https://requirejs.org/).
-- [CommonJS](https://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.
+- [AMD](https://en.wikipedia.org/wiki/Asynchronous_module_definition) -- หนึ่งในระบบโมดูลที่เก่าแก่ที่สุด เริ่มต้นจากไลบรารี [require.js](https://requirejs.org/)
+- [CommonJS](https://wiki.commonjs.org/wiki/Modules/1.1) -- ระบบโมดูลที่สร้างขึ้นมาสำหรับ Node.js โดยเฉพาะ
+- [UMD](https://github.com/umdjs/umd) -- อีกระบบหนึ่งที่พยายามเป็น universal รองรับทั้ง AMD และ CommonJS
 
-Now these all slowly became 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. So we'll study the modern JavaScript modules from now on.
+ระบบโมดูลในตัวภาษา JavaScript มาตรงๆ ในปี 2015 และค่อยๆ พัฒนามาเรื่อยๆ จนตอนนี้บราวเซอร์หลักๆ และ Node.js รองรับหมดแล้ว เราจะเรียนแบบ modern นี้เลย
 
-## What is a module?
+## โมดูลคืออะไร?
 
-A module is just a file. One script is one module. As simple as that.
+โมดูลก็คือไฟล์ธรรมดาๆ นั่นเอง — หนึ่งสคริปต์ หนึ่งโมดูล แค่นั้นเอง
 
-Modules can load each other and use special directives `export` and `import` to interchange functionality, call functions of one module from another one:
+โมดูลโหลดกันเองได้ และใช้ `export` กับ `import` ในการรับส่งฟังก์ชันระหว่างกัน:
 
-- `export` keyword labels variables and functions that should be accessible from outside the current module.
-- `import` allows the import of functionality from other modules.
+- `export` — ติดป้ายให้ตัวแปรหรือฟังก์ชันที่ต้องการให้ไฟล์อื่นเรียกใช้ได้
+- `import` — ดึงสิ่งที่ export ไว้มาใช้ในโมดูลนี้
 
-For instance, if we have a file `sayHi.js` exporting a function:
+ตัวอย่าง ไฟล์ `sayHi.js` export ฟังก์ชันออกมา:
 
 ```js
 // 📁 sayHi.js
 export function sayHi(user) {
-  alert(`Hello, ${user}!`);
+  alert(`สวัสดี, ${user}!`);
 }
 ```
 
-...Then another file may import and use it:
+...แล้วไฟล์อื่น import มาใช้ได้เลย:
 
 ```js
 // 📁 main.js
 import {sayHi} from './sayHi.js';
 
 alert(sayHi); // function...
-sayHi('John'); // Hello, John!
+sayHi('John'); // สวัสดี, John!
 ```
 
-The `import` directive loads the module by path `./sayHi.js` relative to the current file, and assigns exported function `sayHi` to the corresponding variable.
+`import` โหลดโมดูลจาก path `./sayHi.js` ที่นับจากไฟล์ปัจจุบัน แล้วเอาฟังก์ชัน `sayHi` ที่ export ไว้มาใส่ตัวแปร
 
-Let's run the example in-browser.
+ลองรันตัวอย่างในบราวเซอร์ดูกัน
 
-As modules support special keywords and features, we must tell the browser that a script should be treated as a module, by using the attribute `<script type="module">`.
+เนื่องจากโมดูลมี keyword และฟีเจอร์พิเศษ เราต้องบอกบราวเซอร์ว่านี่คือ module script โดยใส่ attribute `<script type="module">` ด้วย
 
-Like this:
+แบบนี้:
 
 [codetabs src="say" height="140" current="index.html"]
 
-The browser automatically fetches and evaluates the imported module (and its imports if needed), and then runs the script.
+บราวเซอร์จะโหลดและรันโมดูลที่ import มาให้เองโดยอัตโนมัติ (รวมถึง import ซ้อนด้วยถ้ามี)
 
-```warn header="Modules work only via HTTP(s), not locally"
-If you try to open a web-page locally, via `file://` protocol, you'll find that `import/export` directives don't work. Use a local web-server, such as [static-server](https://www.npmjs.com/package/static-server#getting-started) or use the "live server" capability of your editor, such as VS Code [Live Server Extension](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer) to test modules.
+```warn header="โมดูลใช้ได้แค่ผ่าน HTTP(s) เท่านั้น ไม่ใช่เปิดไฟล์ตรงๆ"
+ถ้าลองเปิดหน้าเว็บผ่าน `file://` โดยตรง จะพบว่า `import/export` ใช้ไม่ได้ ต้องรันผ่าน web server เล็กๆ เช่น [static-server](https://www.npmjs.com/package/static-server#getting-started) หรือใช้ฟีเจอร์ "live server" ของ editor เช่น [Live Server Extension](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer) ใน VS Code
 ```
 
-## Core module features
+## ฟีเจอร์หลักของโมดูล
 
-What's different in modules, compared to "regular" scripts?
+โมดูลต่างจากสคริปต์ธรรมดายังไงล่ะ?
 
-There are core features, valid both for browser and server-side JavaScript.
+มีจุดต่างหลักๆ ที่ใช้ได้ทั้งบราวเซอร์และ Node.js
 
-### Always "use strict"
+### ใช้ "use strict" เสมอ
 
-Modules always work in strict mode. E.g. assigning to an undeclared variable will give an error.
+โมดูลรัน strict mode ตลอด เช่น ถ้าพยายามกำหนดค่าให้ตัวแปรที่ยังไม่ได้ประกาศ จะได้ error ทันที
 
 ```html run
 <script type="module">
@@ -77,32 +77,32 @@ Modules always work in strict mode. E.g. assigning to an undeclared variable wil
 </script>
 ```
 
-### 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.
+แต่ละโมดูลมีสโคประดับบนสุดเป็นของตัวเอง — ตัวแปรและฟังก์ชันที่ประกาศในโมดูลหนึ่ง ไฟล์อื่นมองไม่เห็น
 
-In the example below, two scripts are imported, and `hello.js` tries to use `user` variable declared in `user.js`. It fails, because it's a separate module (you'll see the error in the console):
+ตัวอย่างด้านล่างนี้ นำ script สอง script เข้ามา แล้ว `hello.js` พยายามใช้ตัวแปร `user` จาก `user.js` แต่ทำไม่ได้ เพราะเป็นคนละโมดูล (ดู error ใน console):
 
 [codetabs src="scopes" height="140" current="index.html"]
 
-Modules should `export` what they want to be accessible from outside and `import` what they need.
+โมดูลต้อง `export` สิ่งที่ต้องการให้ภายนอกเข้าถึง และ `import` สิ่งที่ต้องการใช้
 
-- `user.js` should export the `user` variable.
-- `hello.js` should import it from `user.js` module.
+- `user.js` ต้อง export ตัวแปร `user` ออกมา
+- `hello.js` ต้อง import จาก `user.js`
 
-In other words, with modules we use import/export instead of relying on global variables.
+พูดง่ายๆ คือ แทนที่จะพึ่งตัวแปร global เราใช้ import/export แทน
 
-This is the correct variant:
+นี่คือแบบที่ถูก:
 
 [codetabs src="scopes-working" height="140" current="hello.js"]
 
-In the browser, if we talk about HTML pages, independent top-level scope also exists for each `<script type="module">`.
+ในบราวเซอร์ ถ้าพูดถึงหน้า HTML แต่ละ `<script type="module">` ก็มีสโคประดับบนสุดแยกของตัวเองด้วย
 
-Here are two scripts on the same page, both `type="module"`. They don't see each other's top-level variables:
+สอง script ในหน้าเดียวกัน ต่างก็เป็น `type="module"` ก็มองไม่เห็นตัวแปรของกันและกัน:
 
 ```html run
 <script type="module">
-  // The variable is only visible in this module script
+  // ตัวแปรนี้มองเห็นได้แค่ใน module script นี้เท่านั้น
   let user = "John";
 </script>
 
@@ -114,45 +114,43 @@ Here are two scripts on the same page, both `type="module"`. They don't see each
 ```
 
 ```smart
-In the browser, we can make a variable window-level global by explicitly assigning it to a `window` property, e.g. `window.user = "John"`. 
+ถ้าจำเป็นต้องทำให้ตัวแปรเป็น global จริงๆ ในบราวเซอร์ก็ทำได้ด้วยการกำหนดค่าให้ `window` โดยตรง เช่น `window.user = "John"`
 
-Then all scripts will see it, both with `type="module"` and without it. 
+script ทุกตัวจะเห็นมัน ทั้งแบบ `type="module"` และแบบปกติ
 
-That said, making such global variables is frowned upon. Please try to avoid them.
+แต่พูดตรงๆ เลย ท่านี้ไม่แนะนำ ควรหลีกเลี่ยงถ้าทำได้
 ```
 
-### A module code is evaluated only the first time when imported
+### โค้ดของโมดูลรันแค่ครั้งเดียวตอน import ครั้งแรก
 
-If the same module is imported into multiple other modules, its code is executed only once, upon the first import. Then its exports are given to all further importers.
+ถ้า import โมดูลเดียวกันจากหลายที่ โค้ดในโมดูลนั้นรันแค่ครั้งเดียว — ตอน import ครั้งแรก จากนั้น export ที่สร้างไว้จะแชร์ไปให้ทุกคนที่ import ต่อมา
 
-The one-time evaluation has important consequences, that we should be aware of. 
+เรื่องนี้มีผลที่ต้องระวัง ลองดูตัวอย่างกัน
 
-Let's see a couple of 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:
+ถ้าโค้ดในโมดูลมี side-effect เช่น แสดงข้อความ การ import หลายครั้งจะทริกเกอร์แค่ครั้งแรกเท่านั้น:
 
 ```js
 // 📁 alert.js
-alert("Module is evaluated!");
+alert("โมดูล evaluate แล้ว!");
 ```
 
 ```js
-// Import the same module from different files
+// Import โมดูลเดียวกันจากหลายไฟล์
 
 // 📁 1.js
-import `./alert.js`; // Module is evaluated!
+import `./alert.js`; // โมดูล evaluate แล้ว!
 
 // 📁 2.js
-import `./alert.js`; // (shows nothing)
+import `./alert.js`; // (ไม่แสดงอะไร)
 ```
 
-The second import shows nothing, because the module has already been evaluated.
+การ import ครั้งที่สองไม่แสดงอะไร เพราะโมดูล evaluate ไปแล้ว
 
-There's a rule: top-level module code should be used for initialization, creation of module-specific internal data structures. If we need to make something callable multiple times - we should export it as a function, like we did with `sayHi` above.
+กฎง่ายๆ คือ: โค้ดระดับบนสุดของโมดูลเหมาะสำหรับ initialization หรือสร้างโครงสร้างข้อมูลภายใน ถ้าต้องการให้เรียกซ้ำได้หลายครั้ง ให้ export เป็นฟังก์ชัน เหมือนที่ทำกับ `sayHi` ข้างบน
 
-Now, let's consider a deeper example.
+ทีนี้ลองดูตัวอย่างที่ลึกขึ้น
 
-Let's say, a module exports an object:
+สมมติโมดูล export ออบเจ็กต์ออกมา:
 
 ```js
 // 📁 admin.js
@@ -161,9 +159,9 @@ export let admin = {
 };
 ```
 
-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.
+ถ้า import โมดูลนี้จากหลายไฟล์ โมดูลรันแค่ครั้งเดียว สร้างออบเจ็กต์ `admin` ทีเดียว แล้วส่งต่อให้ทุกคนที่ import
 
-All importers get exactly the one and only `admin` object:
+ทุกคนได้ `admin` ออบเจ็กต์อันเดียวกันทั้งหมด:
 
 ```js
 // 📁 1.js
@@ -175,38 +173,38 @@ import {admin} from './admin.js';
 alert(admin.name); // Pete
 
 *!*
-// Both 1.js and 2.js reference the same admin object
-// Changes made in 1.js are visible in 2.js
+// 1.js และ 2.js ต่างอ้างอิงถึง admin object อันเดียวกัน
+// การแก้ไขใน 1.js มองเห็นได้ใน 2.js
 */!*
 ```
 
-As you can see, when `1.js` changes the `name` property in the imported `admin`, then `2.js` can see the new `admin.name`.
+เห็นไหม? พอ `1.js` แก้พร็อพเพอร์ตี้ `name` ใน `admin` ที่ import มา `2.js` ก็เห็นค่าใหม่นั้นด้วย
 
-That's exactly because the module is executed only once. Exports are generated, and then they are shared between importers, so if something changes the `admin` object, other importers will see that.
+เหตุผลก็เพราะโมดูลรันครั้งเดียว — export สร้างขึ้นมาครั้งหนึ่งแล้วแชร์ ใครแก้ `admin` ทุกคนก็เห็นการเปลี่ยนแปลงนั้น
 
-**Such behavior is actually very convenient, because it allows us to *configure* modules.**
+**พฤติกรรมแบบนี้มีประโยชน์มาก เพราะให้เรา *configure* โมดูลได้**
 
-In other words, a module can provide a generic functionality that needs a setup. E.g. authentication needs credentials. Then it can export a configuration object expecting the outer code to assign to it.
+โมดูลหนึ่งอาจให้ฟังก์ชันการทำงานทั่วไปที่ต้องตั้งค่าก่อนใช้ เช่น ระบบ authentication ที่ต้องการ credentials แล้ว export config object ออกมาให้โค้ดภายนอกมาตั้งค่า
 
-Here's the classical pattern:
-1. A module exports some means of configuration, e.g. a configuration object.
-2. On the first import we initialize it, write to its properties. The top-level application script may do that.
-3. Further imports use the module.
+รูปแบบที่คลาสสิคมากๆ:
+1. โมดูล export ช่องทางสำหรับตั้งค่า เช่น config object
+2. ตอน import ครั้งแรก เราใส่ค่าเข้าไปในพร็อพเพอร์ตี้ — ปกติ application script ระดับบนสุดจะทำ
+3. การ import ต่อๆ มาใช้โมดูลได้เลย
 
-For instance, the `admin.js` module may provide certain functionality (e.g. authentication), but expect the credentials to come into the `config` object from outside:
+ตัวอย่าง `admin.js` ให้ฟังก์ชัน authentication แต่รอรับ credentials จากภายนอกผ่าน `config`:
 
 ```js
 // 📁 admin.js
 export let config = { };
 
 export function sayHi() {
-  alert(`Ready to serve, ${config.user}!`);
+  alert(`พร้อมรับใช้, ${config.user}!`);
 }
 ```
 
-Here, `admin.js` exports the `config` object (initially empty, but may have default properties too).
+`admin.js` export ออบเจ็กต์ `config` ออกมา (ตอนแรกว่างเปล่า แต่จะมี default properties ก็ได้)
 
-Then in `init.js`, the first script of our app, we import `config` from it and set `config.user`:
+แล้วใน `init.js` ซึ่งเป็น script แรกของแอป เรา import `config` มาแล้วกำหนดค่า `config.user`:
 
 ```js
 // 📁 init.js
@@ -214,38 +212,38 @@ import {config} from './admin.js';
 config.user = "Pete";
 ```
 
-...Now the module `admin.js` is configured. 
+...ตอนนี้ `admin.js` configure เรียบร้อย
 
-Further importers can call it, and it correctly shows the current user:
+ไฟล์อื่นที่ import มาทีหลังก็เรียกใช้ได้ แล้วแสดง user ที่ตั้งไว้ถูกต้อง:
 
 ```js
 // 📁 another.js
 import {sayHi} from './admin.js';
 
-sayHi(); // Ready to serve, *!*Pete*/!*!
+sayHi(); // พร้อมรับใช้, *!*Pete*/!*!
 ```
 
 
 ### import.meta
 
-The object `import.meta` contains the information about the current module.
+ออบเจ็กต์ `import.meta` เก็บข้อมูลเกี่ยวกับโมดูลปัจจุบัน
 
-Its content depends on the environment. In the browser, it contains the URL of the script, or a current webpage URL if inside HTML:
+เนื้อหาขึ้นอยู่กับ environment ในบราวเซอร์จะเก็บ URL ของ script หรือ URL ของหน้า HTML ถ้าเป็น inline script:
 
 ```html run height=0
 <script type="module">
-  alert(import.meta.url); // script URL
-  // for an inline script - the URL of the current HTML-page
+  alert(import.meta.url); // URL ของ script
+  // สำหรับ inline script — URL ของหน้า HTML ปัจจุบัน
 </script>
 ```
 
-### In a module, "this" is undefined
+### ใน module, this เป็น undefined
 
-That's kind of a minor feature, but for completeness we should mention it.
+จุดนี้เล็กน้อยหน่อย แต่ก็ควรรู้ไว้
 
-In a module, top-level `this` is undefined.
+ใน module, `this` ระดับบนสุดจะเป็น undefined
 
-Compare it to non-module scripts, where `this` is a global object:
+ต่างจาก script ธรรมดาที่ `this` คือ global object:
 
 ```html run height=0
 <script>
@@ -257,66 +255,68 @@ Compare it to non-module scripts, where `this` is a global object:
 </script>
 ```
 
-## Browser-specific features
+## ฟีเจอร์เฉพาะของบราวเซอร์
 
-There are also several browser-specific differences of scripts with `type="module"` compared to regular ones.
+ยังมีความแตกต่างอีกหลายจุดระหว่าง `type="module"` กับ script ธรรมดาในบราวเซอร์
 
-You may want to skip this section for now if you're reading for the first time, or if you don't use JavaScript in a browser.
+ถ้าเพิ่งอ่านครั้งแรก หรือยังไม่ได้ใช้ JavaScript ในบราวเซอร์ ข้ามส่วนนี้ไปก่อนก็ได้
 
-### Module scripts are deferred
+### Module script โหลดแบบ deferred
 
-Module scripts are *always* deferred, same effect as `defer` attribute (described in the chapter [](info:script-async-defer)), for both external and inline scripts.
+Module script เป็น deferred *เสมอ* — เหมือนกับการใส่ attribute `defer` (ดูเพิ่มใน <info:script-async-defer>) ใช้ได้ทั้ง external และ inline script
 
-In other words:
-- downloading external module scripts `<script type="module" src="...">` doesn't block HTML processing, they load in parallel with other resources.
-- module scripts wait until the HTML document is fully ready (even if they are tiny and load faster than HTML), and then run.
-- relative order of scripts is maintained: scripts that go first in the document, execute first.
+พูดง่ายๆ คือ:
+- การดาวน์โหลด external module script `<script type="module" src="...">` ไม่บล็อก HTML ให้โหลดคู่กันไปได้เลย
+- module script รอจนกว่า HTML document จะโหลดเสร็จสมบูรณ์ก่อน (แม้ script ตัวเองเล็กมากและโหลดเร็วกว่า HTML ก็ตาม)
+- ลำดับของ script ยังรักษาไว้ — script ที่อยู่ก่อนในเอกสารรันก่อน
 
-As a side effect, module scripts always "see" the fully loaded HTML-page, including HTML elements below them.
+ผลพลอยได้คือ module script "มองเห็น" HTML ทั้งหน้าที่โหลดเสร็จแล้ว รวมถึง element ที่อยู่ด้านล่างด้วย
 
-For instance:
+ตัวอย่าง:
 
 ```html run
 <script type="module">
 *!*
-  alert(typeof button); // object: the script can 'see' the button below
+  alert(typeof button); // object: script มองเห็น button ด้านล่างได้
 */!*
-  // as modules are deferred, the script runs after the whole page is loaded
+  // เพราะ module เป็น deferred script จึงรันหลังจาก page โหลดเสร็จ
 </script>
 
-Compare to regular script below:
+เปรียบกับ script ธรรมดาด้านล่าง:
 
 <script>
 *!*
-  alert(typeof button); // button is undefined, the script can't see elements below
+  alert(typeof button); // button คือ undefined, script มองไม่เห็น element ด้านล่าง
 */!*
-  // regular scripts run immediately, before the rest of the page is processed
+  // script ธรรมดารันทันที ก่อนที่ส่วนที่เหลือของหน้าจะถูกประมวลผล
 </script>
 
 <button id="button">Button</button>
 ```
 
-Please note: the second script actually runs before the first! So we'll see `undefined` first, and then `object`.
+สังเกตว่า: script ตัวที่สองรันก่อนตัวแรกด้วยซ้ำ เราจะเห็น `undefined` ก่อน แล้วจึง `object`
+
+เพราะ module เป็น deferred จึงรอให้ document ประมวลผลก่อน ส่วน script ธรรมดารันทันที เลยเห็น output ของมันก่อน
 
-That's because modules are deferred, so we wait for the document to be processed. The regular script runs immediately, so we see its output first.
+ข้อควรระวัง: หน้า HTML จะแสดงให้เห็นก่อน แล้ว JavaScript module ค่อยรันทีหลัง
 
-When using modules, we should be aware that the HTML page shows up as it loads, and JavaScript modules run after that, so the user may see the page before the JavaScript application is ready. Some functionality may not work yet. We should put "loading indicators", or otherwise ensure that the visitor won't be confused by that.
+ผู้ใช้อาจเห็นหน้าเว็บก่อนที่ JavaScript พร้อมใช้งาน เลยควรใส่ "loading indicator" หรือจัดการบางอย่างเพื่อไม่ให้ผู้ใช้งง
 
-### Async works on inline scripts
+### async ทำงานได้กับ inline script
 
-For non-module scripts, the `async` attribute only works on external scripts. Async scripts run immediately when ready, independently of other scripts or the HTML document.
+สำหรับ script ธรรมดา attribute `async` ใช้ได้แค่กับ external script เท่านั้น Async script รันทันทีที่พร้อม ไม่สนใจ script อื่นหรือ HTML document
 
-For module scripts, it works on inline scripts as well.
+สำหรับ module script ใช้ได้กับ inline script ด้วย
 
-For example, the inline script below has `async`, so it doesn't wait for anything.
+ตัวอย่าง inline script ด้านล่างใส่ `async` ไว้ เลยไม่รอใคร
 
-It performs the import (fetches `./analytics.js`) and runs when ready, even if the HTML document is not finished yet, or if other scripts are still pending.
+จะ import (โหลด `./analytics.js`) แล้วรันทันทีที่พร้อม แม้ HTML document ยังไม่เสร็จ หรือ script อื่นยังค้างอยู่ก็ตาม
 
-That's good for functionality that doesn't depend on anything, like counters, ads, document-level event listeners.
+เหมาะสำหรับฟังก์ชันที่ไม่ขึ้นอยู่กับอะไร เช่น ตัวนับ โฆษณา event listener ระดับ document
 
 ```html
-<!-- all dependencies are fetched (analytics.js), and the script runs -->
-<!-- doesn't wait for the document or other <script> tags -->
+<!-- โหลด dependency ทั้งหมด (analytics.js) แล้วรัน script -->
+<!-- ไม่รอ document หรือ <script> tag อื่น -->
 <script *!*async*/!* type="module">
   import {counter} from './analytics.js';
 
@@ -326,93 +326,93 @@ That's good for functionality that doesn't depend on anything, like counters, ad
 
 ### External scripts
 
-External scripts that have `type="module"` are different in two aspects:
+External script ที่มี `type="module"` ต่างออกไป 2 จุด:
 
-1. External scripts with the same `src` run only once:
+1. External script ที่มี `src` เดียวกัน รันแค่ครั้งเดียว:
     ```html
-    <!-- the script my.js is fetched and executed only once -->
+    <!-- script my.js จะถูกโหลดและรันแค่ครั้งเดียว -->
     <script type="module" src="my.js"></script>
     <script type="module" src="my.js"></script>
     ```
 
-2. External scripts that are fetched from another origin (e.g. another site) require [CORS](mdn:Web/HTTP/CORS) headers, as described in the chapter <info:fetch-crossorigin>. In other words, if a module script is fetched from another origin, the remote server must supply a header `Access-Control-Allow-Origin` allowing the fetch.
+2. External script ที่โหลดจาก origin อื่น (เช่น เว็บไซต์อื่น) ต้องมี header [CORS](mdn:Web/HTTP/CORS) ตามที่อธิบายไว้ในบท <info:fetch-crossorigin> พูดง่ายๆ คือถ้า module script โหลดจาก origin อื่น server ฝั่งนั้นต้องส่ง header `Access-Control-Allow-Origin` มาด้วย
     ```html
-    <!-- another-site.com must supply Access-Control-Allow-Origin -->
-    <!-- otherwise, the script won't execute -->
+    <!-- another-site.com ต้องส่ง Access-Control-Allow-Origin มาด้วย -->
+    <!-- ไม่งั้น script จะไม่รัน -->
     <script type="module" src="*!*http://another-site.com/their.js*/!*"></script>
     ```
 
-    That ensures better security by default.
+    ท่านี้ช่วยเพิ่มความปลอดภัยแบบ default
 
-### No "bare" modules allowed
+### ห้ามใช้ "bare" module
 
-In the browser, `import` must get either a relative or absolute URL. Modules without any path are called "bare" modules. Such modules are not allowed in `import`.
+ในบราวเซอร์ `import` ต้องได้รับ URL แบบ relative หรือ absolute เท่านั้น โมดูลที่ไม่มี path เลยเรียกว่า "bare" module ซึ่งใช้ใน `import` ไม่ได้
 
-For instance, this `import` is invalid:
+ตัวอย่าง `import` แบบนี้ใช้ไม่ได้:
 ```js
 import {sayHi} from 'sayHi'; // Error, "bare" module
-// the module must have a path, e.g. './sayHi.js' or wherever the module is
+// โมดูลต้องมี path เช่น './sayHi.js' หรือ path เต็มๆ
 ```
 
-Certain environments, like Node.js or bundle tools allow bare modules, without any path, as they have their own ways for finding modules and hooks to fine-tune them. But browsers do not support bare modules yet.
+บาง environment อย่าง Node.js หรือ bundle tool รองรับ bare module ได้ เพราะมีระบบหา module เป็นของตัวเอง แต่บราวเซอร์ยังไม่รองรับ
 
 ### Compatibility, "nomodule"
 
-Old browsers do not understand `type="module"`. Scripts of an unknown type are just ignored. For them, it's possible to provide a fallback using the `nomodule` attribute:
+บราวเซอร์เก่าๆ ไม่เข้าใจ `type="module"` script ที่มี type ที่ไม่รู้จักจะข้ามไปเฉยๆ เพื่อรองรับบราวเซอร์พวกนี้ ใช้ attribute `nomodule` เป็น fallback ได้:
 
 ```html run
 <script type="module">
-  alert("Runs in modern browsers");
+  alert("รันบนบราวเซอร์ modern");
 </script>
 
 <script nomodule>
-  alert("Modern browsers know both type=module and nomodule, so skip this")
-  alert("Old browsers ignore script with unknown type=module, but execute this.");
+  alert("บราวเซอร์ modern รู้จักทั้ง type=module และ nomodule เลยข้ามอันนี้")
+  alert("บราวเซอร์เก่าไม่รู้จัก type=module เลยข้าม แต่มารันอันนี้แทน");
 </script>
 ```
 
 ## 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.
+ในงาน real-world นั้น browser module แบบ raw ๆ ไม่ค่อยได้ใช้โดยตรง ส่วนใหญ่จะ bundle ไฟล์ทั้งหมดด้วยเครื่องมืออย่าง [Webpack](https://webpack.js.org/) แล้วค่อย deploy ขึ้น 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.
+ข้อดีของ bundler คือควบคุมการ resolve โมดูลได้ละเอียดขึ้น รองรับ bare module และอีกเยอะเลย เช่น CSS/HTML modules ด้วย
 
-Build tools do the following:
+Build tool ทำงานประมาณนี้:
 
-1. Take a "main" module, the one intended to be put in `<script type="module">` in HTML.
-2. Analyze its dependencies: imports and then imports of imports etc.
-3. Build a single file with all modules (or multiple files, that's tunable), replacing native `import` calls with bundler functions, so that it works. "Special" module types like HTML/CSS modules are also supported.
-4. In the process, other transformations and optimizations may be applied:
-    - 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/).
-    - The resulting file is minified (spaces removed, variables replaced with shorter names, etc).
+1. รับ "main" module ที่จะใส่ใน `<script type="module">` ใน HTML
+2. วิเคราะห์ dependency: import และ import ของ import ต่อไปเรื่อยๆ
+3. สร้างไฟล์เดียวรวมโมดูลทั้งหมด (หรือหลายไฟล์ ปรับได้) โดยแทนที่ `import` แบบ native ด้วยฟังก์ชันของ bundler รองรับโมดูลชนิดพิเศษอย่าง HTML/CSS module ด้วย
+4. ระหว่างนั้นอาจมีการ transform และ optimize ด้วย:
+    - ลบโค้ดที่ไม่มีทางถูกเรียกออก
+    - ลบ export ที่ไม่ได้ใช้ ("tree-shaking")
+    - ลบ statement ที่ใช้ตอน development เช่น `console` และ `debugger`
+    - แปลง JavaScript ที่เขียนด้วย syntax ใหม่สุดๆ ให้เป็น syntax เก่าที่ทำงานเหมือนกัน ผ่าน [Babel](https://babeljs.io/)
+    - minify ไฟล์ผลลัพธ์ (ลบช่องว่าง เปลี่ยนชื่อตัวแปรให้สั้น ฯลฯ)
 
-If we use bundle tools, then as scripts are bundled together into a single file (or few files), `import/export` statements inside those scripts are replaced by special bundler functions. So the resulting "bundled" script does not contain any `import/export`, it doesn't require `type="module"`, and we can put it into a regular script:
+พอใช้ bundle tool แล้ว script ทั้งหมดรวมเป็นไฟล์เดียว (หรือไม่กี่ไฟล์) statement `import/export` ภายในก็แทนที่ด้วยฟังก์ชันของ bundler สคริปต์ที่ได้ออกมาจะไม่มี `import/export` เลย ไม่ต้องการ `type="module"` ใส่เป็น script ธรรมดาได้เลย:
 
 ```html
-<!-- Assuming we got bundle.js from a tool like Webpack -->
+<!-- สมมติว่าได้ bundle.js มาจาก Webpack -->
 <script src="bundle.js"></script>
 ```
 
-That said, native modules are also usable. So we won't be using Webpack here: you can configure it later.
+แต่ native module ก็ยังใช้ได้นะ ในที่นี้เราจะไม่ใช้ Webpack — ค่อยไปตั้งค่าเองทีหลังได้
 
-## Summary
+## สรุป
 
-To summarize, the core concepts are:
+สรุป concept หลักๆ:
 
-1. A module is a file. To make `import/export` work, browsers need `<script type="module">`. Modules have several differences:
-    - Deferred by default.
-    - Async works on inline scripts.
-    - To load external scripts from another origin (domain/protocol/port), CORS headers are needed.
-    - Duplicate external scripts are ignored.
-2. Modules have their own, local top-level scope and interchange functionality via `import/export`.
-3. Modules always `use strict`.
-4. Module code is executed only once. Exports are created once and shared between importers.
+1. โมดูลคือไฟล์ ต้องการ `<script type="module">` ในบราวเซอร์เพื่อให้ `import/export` ทำงาน โมดูลมีจุดต่างหลายอย่าง:
+    - เป็น deferred แบบ default
+    - `async` ทำงานได้กับ inline script
+    - การโหลด external script จาก origin อื่น (domain/protocol/port) ต้องมี CORS headers
+    - External script ที่ซ้ำกันจะข้ามไป
+2. โมดูลมีสโคประดับบนสุดของตัวเอง และรับส่งฟังก์ชันผ่าน `import/export`
+3. โมดูลใช้ `use strict` เสมอ
+4. โค้ดในโมดูลรันแค่ครั้งเดียว export ถูกสร้างครั้งเดียวแล้วแชร์ให้ทุก import
 
-When we use modules, each module implements the functionality and exports it. Then we use `import` to directly import it where it's needed. The browser loads and evaluates the scripts automatically.
+เวลาใช้โมดูล แต่ละโมดูลจัดการฟังก์ชันของตัวเองแล้ว export ออกมา เราก็ `import` ตรงๆ ในที่ที่ต้องการ บราวเซอร์โหลดและ evaluate ให้เองอัตโนมัติ
 
-In production, people often use bundlers such as [Webpack](https://webpack.js.org) to bundle modules together for performance and other reasons.
+ใน production มักใช้ bundler อย่าง [Webpack](https://webpack.js.org) เพื่อ performance และเหตุผลอื่นๆ
 
-In the next chapter we'll see more examples of modules, and how things can be exported/imported.
+บทถัดไปเราจะดูตัวอย่างโมดูลเพิ่มเติม และวิธี export/import แบบต่างๆ
diff --git a/1-js/13-modules/01-modules-intro/say.view/say.js b/1-js/13-modules/01-modules-intro/say.view/say.js
index 198a3be6d..8e63d415a 100644
--- a/1-js/13-modules/01-modules-intro/say.view/say.js
+++ b/1-js/13-modules/01-modules-intro/say.view/say.js
@@ -1,3 +1,3 @@
 export function sayHi(user) {
-  return `Hello, ${user}!`;
+  return `สวัสดี, ${user}!`;
 }
diff --git a/1-js/13-modules/01-modules-intro/scopes.view/hello.js b/1-js/13-modules/01-modules-intro/scopes.view/hello.js
index 714aafa1f..740d78a3a 100644
--- a/1-js/13-modules/01-modules-intro/scopes.view/hello.js
+++ b/1-js/13-modules/01-modules-intro/scopes.view/hello.js
@@ -1 +1 @@
-alert(user); // no such variable (each module has independent variables)
+alert(user); // ไม่มีตัวแปรนี้ (แต่ละโมดูลมีตัวแปรแยกจากกัน)
diff --git a/1-js/13-modules/02-import-export/article.md b/1-js/13-modules/02-import-export/article.md
index 1b5649c69..40d2d7913 100644
--- a/1-js/13-modules/02-import-export/article.md
+++ b/1-js/13-modules/02-import-export/article.md
@@ -1,23 +1,23 @@
 # Export and Import
 
-Export and import directives have several syntax variants.
+คำสั่ง export และ import มีรูปแบบ syntax ให้เลือกใช้หลายแบบ
 
-In the previous article we saw a simple use, now let's explore more examples.
+บทที่แล้วเราดูตัวอย่างง่ายๆ ไปแล้ว คราวนี้มาลงรายละเอียดกันให้ครบ
 
-## Export before declarations
+## Export ก่อน declaration
 
-We can label any declaration as exported by placing `export` before it, be it a variable, function or a class.
+วางคำว่า `export` ไว้หน้า declaration ใดก็ได้ — จะเป็นตัวแปร ฟังก์ชัน หรือคลาสก็โอเค
 
-For instance, here all exports are valid:
+เช่น ตัวอย่างข้างล่างนี้ export ได้ทุกแบบเลย:
 
 ```js
-// export an array
+// export อาร์เรย์
 *!*export*/!* let months = ['Jan', 'Feb', 'Mar','Apr', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'];
 
-// export a constant
+// export ค่าคงที่
 *!*export*/!* const MODULES_BECAME_STANDARD_YEAR = 2015;
 
-// export a class
+// export คลาส
 *!*export*/!* class User {
   constructor(name) {
     this.name = name;
@@ -25,26 +25,24 @@ 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). It's still a function declaration, albeit exported.
+````smart header="ไม่ต้องใส่ semicolon หลัง export class/function"
+สังเกตว่า `export` ที่วางไว้หน้าคลาสหรือฟังก์ชัน ไม่ได้ทำให้มันกลายเป็น [function expression](info:function-expressions) นะ มันยังเป็น function declaration อยู่ แค่ export ออกไปด้วยเท่านั้น
 
-Most JavaScript style guides don't recommend semicolons after function and class declarations.
+style guide ของ JavaScript ส่วนใหญ่ไม่แนะนำให้ใส่ semicolon หลัง function หรือ class declaration
 
-That's why there's no need for a semicolon at the end of `export class` and `export function`:
+เพราะฉะนั้น `export class` และ `export function` ก็ไม่ต้องใส่ semicolon ท้ายบรรทัดเหมือนกัน:
 
 ```js
 export function sayHi(user) {
   alert(`Hello, ${user}!`);
-} *!* // no ; at the end */!*
+} *!* // ไม่มี ; ท้ายบรรทัด */!*
 ```
 
 ````
 
-## Export apart from declarations
+## Export แยกออกจาก declaration
 
-Also, we can put `export` separately.
-
-Here we first declare, and then export:
+อีกวิธีคือประกาศก่อน แล้วค่อย export ทีหลัง
 
 ```js
 // 📁 say.js
@@ -57,15 +55,15 @@ function sayBye(user) {
 }
 
 *!*
-export {sayHi, sayBye}; // a list of exported variables
+export {sayHi, sayBye}; // รายการฟังก์ชันที่จะ export
 */!*
 ```
 
-...Or, technically we could put `export` above functions as well.
+...หรือจะวาง `export` ไว้เหนือฟังก์ชันก็ได้เหมือนกัน
 
 ## Import *
 
-Usually, we put a list of what to import in curly braces `import {...}`, like this:
+ปกติเราจะระบุรายชื่อที่จะ import ใน curly braces แบบนี้:
 
 ```js
 // 📁 main.js
@@ -77,7 +75,7 @@ sayHi('John'); // Hello, John!
 sayBye('John'); // Bye, John!
 ```
 
-But if there's a lot to import, we can import everything as an object using `import * as <obj>`, for instance:
+แต่ถ้ามีของที่จะ import เยอะมาก จะ import ทุกอย่างเป็นออบเจ็กต์เดียวด้วย `import * as <obj>` ก็ได้:
 
 ```js
 // 📁 main.js
@@ -89,24 +87,24 @@ say.sayHi('John');
 say.sayBye('John');
 ```
 
-At first sight, "import everything" seems such a cool thing, short to write, why should we ever explicitly list what we need to import?
+มองผิวเผินก็ดูเจ๋งดีนะ — เขียนน้อย import ได้ทั้งหมด แล้วทำไมต้องระบุรายชื่อให้ยุ่งยากล่ะ?
 
-Well, there are few reasons.
+จริงๆ แล้วมีเหตุผลอยู่สองข้อ
 
-1. Explicitly listing what to import gives shorter names: `sayHi()` instead of `say.sayHi()`.
-2. Explicit list of imports gives better overview of the code structure: what is used and where. It makes code support and refactoring easier.
+1. ระบุชื่อที่ import ชัดๆ จะได้ชื่อสั้นกว่า: `sayHi()` แทน `say.sayHi()`
+2. มีรายชื่อ import ชัดเจน ทำให้เห็นภาพรวมของโค้ดได้ดีขึ้น — รู้ว่าใช้อะไรบ้าง ใช้ที่ไหน ช่วยให้แก้โค้ดและ refactor ง่ายขึ้นด้วย
 
-```smart header="Don't be afraid to import too much"
-Modern build tools, such as [webpack](https://webpack.js.org/) and others, bundle modules together and optimize them to speedup loading. They also remove unused imports.
+```smart header="ไม่ต้องกังวลว่า import เยอะเกินไป"
+build tool สมัยใหม่อย่าง [webpack](https://webpack.js.org/) จะ bundle โมดูลและ optimize ให้อัตโนมัติ รวมถึงตัด import ที่ไม่ได้ใช้ออกด้วย
 
-For instance, if you `import * as library` from a huge code library, and then use only few methods, then unused ones [will not be included](https://github.com/webpack/webpack/tree/main/examples/harmony-unused#examplejs) into the optimized bundle.
+เช่น ถ้าเรา `import * as library` จาก library ขนาดใหญ่ แล้วใช้แค่ไม่กี่เมธอด เมธอดที่ไม่ได้ใช้ [จะไม่รวม](https://github.com/webpack/webpack/tree/main/examples/harmony-unused#examplejs) เข้าไปใน bundle สุดท้าย
 ```
 
 ## Import "as"
 
-We can also use `as` to import under different names.
+ใช้ `as` เปลี่ยนชื่อตอน import ได้
 
-For instance, let's import `sayHi` into the local variable `hi` for brevity, and import `sayBye` as `bye`:
+เช่น import `sayHi` แล้วเก็บไว้ในตัวแปร `hi` เพื่อให้ชื่อสั้นลง และ import `sayBye` เป็น `bye`:
 
 ```js
 // 📁 main.js
@@ -120,9 +118,9 @@ bye('John'); // Bye, John!
 
 ## Export "as"
 
-The similar syntax exists for `export`.
+ฝั่ง `export` ก็มีวิธีเดียวกัน
 
-Let's export functions as `hi` and `bye`:
+export ฟังก์ชันออกไปในชื่อ `hi` และ `bye`:
 
 ```js
 // 📁 say.js
@@ -130,7 +128,7 @@ Let's export functions as `hi` and `bye`:
 export {sayHi as hi, sayBye as bye};
 ```
 
-Now `hi` and `bye` are official names for outsiders, to be used in imports:
+ทีนี้ `hi` และ `bye` กลายเป็นชื่อทางการที่ฝั่งผู้ใช้จะเห็นตอน import:
 
 ```js
 // 📁 main.js
@@ -142,95 +140,95 @@ say.*!*bye*/!*('John'); // Bye, John!
 
 ## Export default
 
-In practice, there are mainly two kinds of modules.
+ในทางปฏิบัติ โมดูลมักมีอยู่สองแบบ
 
-1. Modules that contain a library, pack of functions, like `say.js` above.
-2. Modules that declare a single entity, e.g. a module `user.js` exports only `class User`.
+1. โมดูลที่รวมฟังก์ชันหลายตัวเป็น library เดียว เช่น `say.js` ด้านบน
+2. โมดูลที่ export สิ่งเดียว เช่น `user.js` ที่ export แค่ `class User`
 
-Mostly, the second approach is preferred, so that every "thing" resides in its own module.
+แนวทางที่สองนิยมกันมากกว่า เพราะแต่ละ "สิ่ง" ก็อยู่ในโมดูลของตัวเอง
 
-Naturally, that requires a lot of files, as everything wants its own module, but that's not a problem at all. Actually, code navigation becomes easier if files are well-named and structured into folders.
+แน่นอนว่าต้องสร้างไฟล์เยอะหน่อย แต่ถ้าตั้งชื่อดีและจัดโครงสร้างโฟลเดอร์ชัดเจน การ navigate โค้ดจะง่ายกว่ามาก
 
-Modules provide a special `export default` ("the default export") syntax to make the "one thing per module" way look better.
+โมดูลมี syntax พิเศษชื่อ `export default` สำหรับรูปแบบ "หนึ่งโมดูล หนึ่งสิ่ง" โดยเฉพาะ
 
-Put `export default` before the entity to export:
+วาง `export default` ไว้หน้าสิ่งที่จะ export:
 
 ```js
 // 📁 user.js
-export *!*default*/!* class User { // just add "default"
+export *!*default*/!* class User { // แค่เพิ่ม "default"
   constructor(name) {
     this.name = name;
   }
 }
 ```
 
-There may be only one `export default` per file.
+ในแต่ละไฟล์มี `export default` ได้แค่ตัวเดียว
 
-...And then import it without curly braces:
+...แล้ว import มาใช้โดยไม่ต้องใส่ curly braces:
 
 ```js
 // 📁 main.js
-import *!*User*/!* from './user.js'; // not {User}, just User
+import *!*User*/!* from './user.js'; // ไม่ใช่ {User} แต่เป็น User
 
 new User('John');
 ```
 
-Imports without curly braces look nicer. A common mistake when starting to use modules is to forget curly braces at all. So, remember, `import` needs curly braces for named exports and doesn't need them for the default one.
+Import โดยไม่มี curly braces ดูสะอาดตากว่า ข้อผิดพลาดที่เจอบ่อยตอนเริ่มใช้โมดูลคือลืม curly braces ไปเลย จำไว้ว่า `import` ต้องมี curly braces สำหรับ named export แต่ default export ไม่ต้องใส่
 
 | Named export | Default export |
 |--------------|----------------|
 | `export class User {...}` | `export default class User {...}` |
 | `import {User} from ...` | `import User from ...`|
 
-Technically, we may have both default and named exports in a single module, but in practice people usually don't mix them. A module has either named exports or the default one.
+จริงๆ แล้วมีทั้ง default และ named export ในโมดูลเดียวกันได้ แต่ในทางปฏิบัติคนส่วนใหญ่ไม่ผสมกัน โมดูลจะเลือกใช้อย่างใดอย่างหนึ่ง
 
-As there may be at most one default export per file, the exported entity may have no name.
+เนื่องจากไฟล์นึงมี default export ได้แค่ตัวเดียว สิ่งที่ export ออกไปไม่จำเป็นต้องมีชื่อก็ได้
 
-For instance, these are all perfectly valid default exports:
+เช่น ตัวอย่างข้างล่างนี้เป็น default export ที่ถูกต้องทั้งหมด:
 
 ```js
-export default class { // no class name
+export default class { // ไม่มีชื่อคลาส
   constructor() { ... }
 }
 ```
 
 ```js
-export default function(user) { // no function name
+export default function(user) { // ไม่มีชื่อฟังก์ชัน
   alert(`Hello, ${user}!`);
 }
 ```
 
 ```js
-// export a single value, without making a variable
+// export ค่าเดียว โดยไม่ต้องสร้างตัวแปร
 export default ['Jan', 'Feb', 'Mar','Apr', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'];
 ```
 
-Not giving a name is fine, because there is only one `export default` per file, so `import` without curly braces knows what to import.
+ไม่มีชื่อก็โอเค เพราะในไฟล์นึงมี `export default` ได้แค่ตัวเดียว `import` โดยไม่มี curly braces จึงรู้ว่าต้อง import อะไร
 
-Without `default`, such an export would give an error:
+แต่ถ้าไม่มี `default` จะ error ทันที:
 
 ```js
-export class { // Error! (non-default export needs a name)
+export class { // Error! (named export ต้องมีชื่อ)
   constructor() {}
 }
 ```
 
-### The "default" name
+### ชื่อ "default"
 
-In some situations the `default` keyword is used to reference the default export.
+บางสถานการณ์ใช้ keyword `default` อ้างอิงถึง default export ได้
 
-For example, to export a function separately from its definition:
+เช่น export ฟังก์ชันแยกออกจากนิยามฟังก์ชัน:
 
 ```js
 function sayHi(user) {
   alert(`Hello, ${user}!`);
 }
 
-// same as if we added "export default" before the function
+// เหมือนกับใส่ "export default" ไว้หน้าฟังก์ชัน
 export {sayHi as default};
 ```
 
-Or, another situation, let's say a module `user.js` exports one main "default" thing, and a few named ones (rarely the case, but it happens):
+หรืออีกกรณี สมมติโมดูล `user.js` export สิ่งหลักเป็น default แล้วยังมี named export เพิ่มด้วย (พบได้ไม่บ่อย แต่ก็มี):
 
 ```js
 // 📁 user.js
@@ -245,7 +243,7 @@ export function sayHi(user) {
 }
 ```
 
-Here's how to import the default export along with a named one:
+วิธี import default export พร้อมกับ named export:
 
 ```js
 // 📁 main.js
@@ -254,38 +252,38 @@ import {*!*default as User*/!*, sayHi} from './user.js';
 new User('John');
 ```
 
-And, finally, if importing everything `*` as an object, then the `default` property is exactly the default export:
+และถ้า import ทุกอย่างด้วย `*` เป็นออบเจ็กต์ พร็อพเพอร์ตี้ `default` จะเป็น default export นั้นเอง:
 
 ```js
 // 📁 main.js
 import * as user from './user.js';
 
-let User = user.default; // the default export
+let User = user.default; // default export
 new User('John');
 ```
 
-### A word against default exports
+### ข้อเสียของ default export
 
-Named exports are explicit. They exactly name what they import, so we have that information from them; that's a good thing.
+Named export บอกชัดว่า import อะไร เพราะชื่อมันตายตัว — ข้อดีชัดเจน
 
-Named exports force us to use exactly the right name to import:
+Named export บังคับให้ใช้ชื่อที่ถูกต้องตอน import:
 
 ```js
 import {User} from './user.js';
-// import {MyUser} won't work, the name must be {User}
+// import {MyUser} ไม่ได้ ต้องใช้ {User} เท่านั้น
 ```
 
-...While for a default export, we always choose the name when importing:
+...แต่ default export ตั้งชื่อเองได้ตอน import:
 
 ```js
-import User from './user.js'; // works
-import MyUser from './user.js'; // works too
-// could be import Anything... and it'll still work
+import User from './user.js'; // โอเค
+import MyUser from './user.js'; // โอเคเหมือนกัน
+// จะ import Anything... ก็ยังได้
 ```
 
-So team members may use different names to import the same thing, and that's not good.
+เพราะอย่างนี้ คนในทีมอาจใช้ชื่อต่างกันในการ import สิ่งเดียวกัน — ไม่ดีแน่
 
-Usually, to avoid that and keep the code consistent, there's a rule that imported variables should correspond to file names, e.g:
+วิธีที่ทีมส่วนใหญ่ใช้แก้ปัญหานี้คือกำหนดกฎว่าชื่อตัวแปรที่ import ต้องตรงกับชื่อไฟล์:
 
 ```js
 import User from './user.js';
@@ -294,13 +292,13 @@ import func from '/path/to/func.js';
 ...
 ```
 
-Still, some teams consider it a serious drawback of default exports. So they prefer to always use named exports. Even if only a single thing is exported, it's still exported under a name, without `default`.
+บางทีมถือว่านี่เป็นข้อเสียร้ายแรงของ default export จนเลือกใช้ named export ตลอด แม้จะ export สิ่งเดียวก็ยังใส่ชื่อไว้โดยไม่ใช้ `default`
 
-That also makes re-export (see below) a little bit easier.
+แนวทางนี้ยังทำให้การ re-export (ดูด้านล่าง) ง่ายขึ้นด้วย
 
 ## Re-export
 
-"Re-export" syntax `export ... from ...` allows to import things and immediately export them (possibly under another name), like this:
+syntax `export ... from ...` ช่วยให้ import มาแล้ว export ต่อได้ทันที (จะเปลี่ยนชื่อด้วยก็ได้):
 
 ```js
 export {sayHi} from './say.js'; // re-export sayHi
@@ -308,11 +306,11 @@ export {sayHi} from './say.js'; // re-export sayHi
 export {default as User} from './user.js'; // re-export default
 ```
 
-Why would that be needed? Let's see a practical use case.
+ใช้ทำอะไรล่ะ? ลองดูกรณีที่ใช้งานจริง
 
-Imagine, we're writing a "package": a folder with a lot of modules, with some of the functionality exported outside (tools like NPM allow us to publish and distribute such packages, but we don't have to use them), and many modules are just "helpers", for internal use in other package modules.
+สมมติเรากำลังเขียน "package" — โฟลเดอร์ที่มีโมดูลเยอะมาก บางโมดูล export ฟีเจอร์ออกไปให้คนอื่นใช้ (เหมือน NPM package แต่ไม่จำเป็นต้อง publish) และอีกหลายโมดูลเป็นแค่ "helper" ใช้งานภายใน package เท่านั้น
 
-The file structure could be like this:
+โครงสร้างไฟล์อาจหน้าตาแบบนี้:
 ```
 auth/
     index.js
@@ -326,56 +324,56 @@ auth/
         ...
 ```
 
-We'd like to expose the package functionality via a single entry point.
+เราต้องการให้คนอื่น import ผ่านจุดเดียว
 
-In other words, a person who would like to use our package, should import only from the "main file" `auth/index.js`.
+พูดง่ายๆ คือคนที่จะใช้ package นี้ ควร import จาก "ไฟล์หลัก" `auth/index.js` เท่านั้น
 
-Like this:
+แบบนี้:
 
 ```js
 import {login, logout} from 'auth/index.js'
 ```
 
-The "main file", `auth/index.js` exports all the functionality that we'd like to provide in our package.
+`auth/index.js` จะ export ทุกฟีเจอร์ที่ต้องการเปิดให้ใช้งาน
 
-The idea is that outsiders, other programmers who use our package, should not meddle with its internal structure, search for files inside our package folder. We export only what's necessary in `auth/index.js` and keep the rest hidden from prying eyes.
+ไอเดียคือคนภายนอกไม่ควรต้องไปยุ่งกับโครงสร้างภายใน ไปค้นหาไฟล์ใน package โดยตรง เรา export แค่ที่จำเป็นใน `auth/index.js` แล้วซ่อนส่วนที่เหลือไว้
 
-As the actual exported functionality is scattered among the package, we can import it into `auth/index.js` and export from it:
+เนื่องจากฟีเจอร์กระจายอยู่ตามโมดูลต่างๆ เราก็ import มาที่ `auth/index.js` แล้ว export ต่อ:
 
 ```js
 // 📁 auth/index.js
 
-// import login/logout and immediately export them
+// import login/logout แล้ว export ออกไปทันที
 import {login, logout} from './helpers.js';
 export {login, logout};
 
-// import default as User and export it
+// import default เป็น User แล้ว export
 import User from './user.js';
 export {User};
 ...
 ```
 
-Now users of our package can `import {login} from "auth/index.js"`.
+ตอนนี้คนใช้ package เรา `import {login} from "auth/index.js"` ได้เลย
 
-The syntax `export ... from ...` is just a shorter notation for such import-export:
+syntax `export ... from ...` เป็นแค่ shorthand ของ import-export แบบข้างบน:
 
 ```js
 // 📁 auth/index.js
 // re-export login/logout
 export {login, logout} from './helpers.js';
 
-// re-export the default export as User
+// re-export default export เป็น User
 export {default as User} from './user.js';
 ...
 ```
 
-The notable difference of `export ... from` compared to `import/export` is that re-exported modules aren't available in the current file. So inside the above example of `auth/index.js` we can't use re-exported `login/logout` functions.
+ข้อแตกต่างสำคัญของ `export ... from` เทียบกับ import/export ธรรมดาคือ โมดูลที่ re-export ออกไปจะ**ใช้งานในไฟล์ปัจจุบันไม่ได้** ใน `auth/index.js` ด้านบน เราเรียกฟังก์ชัน `login/logout` ที่ re-export ออกไปตรงนั้นไม่ได้
 
-### Re-exporting the default export
+### Re-export default export
 
-The default export needs separate handling when re-exporting.
+การ re-export default export ต้องจัดการแยกต่างหาก
 
-Let's say we have `user.js` with the `export default class User` and would like to re-export it:
+สมมติมี `user.js` ที่มี `export default class User` แล้วต้องการ re-export:
 
 ```js
 // 📁 user.js
@@ -384,71 +382,71 @@ export default class User {
 }
 ```
 
-We can come across two problems with it:
+มีปัญหาที่เจอได้สองข้อ:
 
-1. `export User from './user.js'` won't work. That would lead to a syntax error.
+1. `export User from './user.js'` ไม่ได้ — เป็น syntax error
 
-    To re-export the default export, we have to write `export {default as User}`, as in the example above.
+    ต้องเขียน `export {default as User}` ตามตัวอย่างด้านบน
 
-2. `export * from './user.js'` re-exports only named exports, but ignores the default one.
+2. `export * from './user.js'` re-export เฉพาะ named export แต่ข้าม default ไป
 
-    If we'd like to re-export both named and default exports, then two statements are needed:
+    ถ้าต้องการ re-export ทั้ง named และ default ต้องเขียนสองบรรทัด:
     ```js
-    export * from './user.js'; // to re-export named exports
-    export {default} from './user.js'; // to re-export the default export
+    export * from './user.js'; // re-export named exports
+    export {default} from './user.js'; // re-export default export
     ```
 
-Such oddities of re-exporting a default export are one of the reasons why some developers don't like default exports and prefer named ones.
+ความยุ่งยากพวกนี้คือหนึ่งในเหตุผลที่นักพัฒนาหลายคนไม่ชอบ default export และเลือกใช้ named export แทน
 
-## Summary
+## สรุป
 
-Here are all types of `export` that we covered in this and previous articles.
+นี่คือ `export` ทุกรูปแบบที่เราพูดถึงในบทนี้และบทก่อนหน้า
 
-You can check yourself by reading them and recalling what they mean:
+ลองอ่านดูแล้วนึกว่าแต่ละแบบทำงานยังไง:
 
-- Before declaration of a class/function/..:
+- วางไว้หน้า declaration ของ class/function/...:
   - `export [default] class/function/variable ...`
-- Standalone export:
+- export แบบแยกออกมา:
   - `export {x [as y], ...}`.
 - Re-export:
   - `export {x [as y], ...} from "module"`
-  - `export * from "module"` (doesn't re-export default).
-  - `export {default [as y]} from "module"` (re-export default).
+  - `export * from "module"` (ไม่ re-export default)
+  - `export {default [as y]} from "module"` (re-export default)
 
 Import:
 
-- Importing named exports:
+- Import named exports:
   - `import {x [as y], ...} from "module"`
-- Importing the default export:
+- Import default export:
   - `import x from "module"`
   - `import {default as x} from "module"`
-- Import all:
+- Import ทั้งหมด:
   - `import * as obj from "module"`
-- Import the module (its code runs), but do not assign any of its exports to variables:
+- Import โมดูล (รันโค้ด) แต่ไม่รับค่า export ใดๆ:
   - `import "module"`
 
-We can put `import/export` statements at the top or at the bottom of a script, that doesn't matter.
+วาง `import/export` ไว้บนสุดหรือล่างสุดของ script ก็ได้ ไม่มีผลต่างกัน
 
-So, technically this code is fine:
+เช่น โค้ดแบบนี้ก็โอเค:
 ```js
 sayHi();
 
 // ...
 
-import {sayHi} from './say.js'; // import at the end of the file
+import {sayHi} from './say.js'; // import ที่ท้ายไฟล์
 ```
 
-In practice imports are usually at the start of the file, but that's only for more convenience.
+ในทางปฏิบัตินิยมวาง import ไว้บนสุดเพื่อความสะดวก
 
-**Please note that import/export statements don't work if inside `{...}`.**
+**จุดสำคัญ: `import/export` ใช้ภายใน `{...}` ไม่ได้**
 
-A conditional import, like this, won't work:
+import แบบมีเงื่อนไขแบบนี้จะไม่ทำงาน:
 ```js
 if (something) {
-  import {sayHi} from "./say.js"; // Error: import must be at top level
+  import {sayHi} from "./say.js"; // Error: import ต้องอยู่ระดับบนสุด
 }
 ```
 
-...But what if we really need to import something conditionally? Or at the right time? Like, load a module upon request, when it's really needed?
+...แล้วถ้าต้องการ import ตามเงื่อนไขจริงๆ ล่ะ? หรือ import ตอนที่ต้องการเท่านั้น? เช่น โหลดโมดูลเมื่อมีคนร้องขอ?
 
-We'll see dynamic imports in the next article.
+เรื่อง dynamic import จะพูดถึงในบทถัดไป
diff --git a/1-js/13-modules/03-modules-dynamic-imports/article.md b/1-js/13-modules/03-modules-dynamic-imports/article.md
index e48144a3e..78353b3ec 100644
--- a/1-js/13-modules/03-modules-dynamic-imports/article.md
+++ b/1-js/13-modules/03-modules-dynamic-imports/article.md
@@ -1,61 +1,59 @@
 # Dynamic imports
 
-Export and import statements that we covered in previous chapters are called "static". The syntax is very simple and strict.
+คำสั่ง import และ export ที่เราคุ้นเคยกันมาตลอด เรียกว่า "static" — เขียนตอนไหนก็ตายตัวตอนนั้น ไม่เปลี่ยนแปลงตาม runtime
 
-First, we can't dynamically generate any parameters of `import`.
-
-The module path must be a primitive string, can't be a function call. This won't work:
+ข้อจำกัดแรกคือ path ของโมดูลต้องเป็น string ตรงๆ เรียกฟังก์ชันแทนไม่ได้:
 
 ```js
-import ... from *!*getModuleName()*/!*; // Error, only from "string" is allowed
+import ... from *!*getModuleName()*/!*; // Error รับแค่ string เท่านั้น
 ```
 
-Second, we can't import conditionally or at run-time:
+ข้อจำกัดที่สองคือ ใส่ใน if หรือบล็อกอื่นๆ ก็ไม่ได้:
 
 ```js
 if(...) {
-  import ...; // Error, not allowed!
+  import ...; // Error ใช้แบบนี้ไม่ได้!
 }
 
 {
-  import ...; // Error, we can't put import in any block
+  import ...; // Error ใส่ import ในบล็อกใดๆ ไม่ได้
 }
 ```
 
-That's because `import`/`export` aim to provide a backbone for the code structure. That's a good thing, as code structure can be analyzed, modules can be gathered and bundled into one file by special tools, unused exports can be removed ("tree-shaken"). That's possible only because the structure of imports/exports is simple and fixed.
+เหตุผลที่เป็นแบบนี้คือ `import`/`export` ออกแบบมาเพื่อให้โครงสร้างโค้ดชัดเจนและคาดเดาได้ ทำให้ tools พิเศษวิเคราะห์โค้ดได้ รวมโมดูลเป็นไฟล์เดียวได้ และตัด export ที่ไม่ใช้ออกได้ (เรียกว่า "tree-shaking") ทั้งหมดนี้ทำได้เพราะโครงสร้างของ import/export ไม่เปลี่ยนแปลง
 
-But how can we import a module dynamically, on-demand?
+แต่ถ้าต้องการโหลดโมดูลแบบ on-demand ตามสถานการณ์ล่ะ?
 
-## The import() expression
+## นิพจน์ import()
 
-The `import(module)` expression loads the module and returns a promise that resolves into a module object that contains all its exports. It can be called from any place in the code.
+`import(module)` โหลดโมดูลแล้วคืนค่าเป็น promise ที่ resolve เป็นออบเจ็กต์ของโมดูล ซึ่งมีทุก export อยู่ครบ — เรียกจากที่ไหนในโค้ดก็ได้
 
-We can use it dynamically in any place of the code, for instance:
+ตัวอย่างการใช้แบบ dynamic:
 
 ```js
-let modulePath = prompt("Which module to load?");
+let modulePath = prompt("จะโหลดโมดูลไหนดี?");
 
 import(modulePath)
   .then(obj => <module object>)
-  .catch(err => <loading error, e.g. if no such module>)
+  .catch(err => <โหลดพัง เช่น ไม่พบโมดูลที่ระบุ>)
 ```
 
-Or, we could use `let module = await import(modulePath)` if inside an async function.
+หรือถ้าอยู่ใน async function ก็ใช้ `let module = await import(modulePath)` ได้เลย
 
-For instance, if we have the following module `say.js`:
+สมมติเรามีโมดูล `say.js` แบบนี้:
 
 ```js
 // 📁 say.js
 export function hi() {
-  alert(`Hello`);
+  alert(`สวัสดี`);
 }
 
 export function bye() {
-  alert(`Bye`);
+  alert(`ลาก่อน`);
 }
 ```
 
-...Then dynamic import can be like this:
+...dynamic import ก็เขียนได้แบบนี้:
 
 ```js
 let {hi, bye} = await import('./say.js');
@@ -64,35 +62,35 @@ hi();
 bye();
 ```
 
-Or, if `say.js` has the default export:
+แต่ถ้า `say.js` ใช้ default export:
 
 ```js
 // 📁 say.js
 export default function() {
-  alert("Module loaded (export default)!");
+  alert("โหลดโมดูลแล้ว (export default)!");
 }
 ```
 
-...Then, in order to access it, we can use `default` property of the module object:
+...เราเข้าถึงมันผ่านพร็อพเพอร์ตี้ `default` ของออบเจ็กต์โมดูล:
 
 ```js
 let obj = await import('./say.js');
 let say = obj.default;
-// or, in one line: let {default: say} = await import('./say.js');
+// หรือเขียนบรรทัดเดียว: let {default: say} = await import('./say.js');
 
 say();
 ```
 
-Here's the full example:
+ลองดูตัวอย่างเต็มๆ:
 
 [codetabs src="say" current="index.html"]
 
 ```smart
-Dynamic imports work in regular scripts, they don't require `script type="module"`.
+Dynamic imports ใช้ได้กับ script ธรรมดาทั่วไป ไม่จำเป็นต้องใส่ `script type="module"` เลย
 ```
 
 ```smart
-Although `import()` looks like a function call, it's a special syntax that just happens to use parentheses (similar to `super()`).
+แม้ว่า `import()` จะหน้าตาเหมือนเรียกฟังก์ชัน แต่จริงๆ แล้วเป็น syntax พิเศษที่ใช้วงเล็บเฉยๆ (คล้ายกับ `super()`)
 
-So we can't copy `import` to a variable or use `call/apply` with it. It's not a function.
+เพราะฉะนั้นเอา `import` ไปเก็บในตัวแปร หรือใช้ `call/apply` ไม่ได้นะ — มันไม่ใช่ฟังก์ชัน
 ```
diff --git a/1-js/13-modules/03-modules-dynamic-imports/say.view/index.html b/1-js/13-modules/03-modules-dynamic-imports/say.view/index.html
index 80909cf94..0c0f1b81a 100644
--- a/1-js/13-modules/03-modules-dynamic-imports/say.view/index.html
+++ b/1-js/13-modules/03-modules-dynamic-imports/say.view/index.html
@@ -2,9 +2,9 @@
 <script>
   async function load() {
     let say = await import('./say.js');
-    say.hi(); // Hello!
-    say.bye(); // Bye!
-    say.default(); // Module loaded (export default)!
+    say.hi(); // สวัสดี!
+    say.bye(); // ลาก่อน!
+    say.default(); // โหลดโมดูลแล้ว (export default)!
   }
 </script>
-<button onclick="load()">Click me</button>
+<button onclick="load()">คลิกที่นี่</button>
diff --git a/1-js/13-modules/03-modules-dynamic-imports/say.view/say.js b/1-js/13-modules/03-modules-dynamic-imports/say.view/say.js
index cff234b7c..a7bcb0e17 100644
--- a/1-js/13-modules/03-modules-dynamic-imports/say.view/say.js
+++ b/1-js/13-modules/03-modules-dynamic-imports/say.view/say.js
@@ -1,11 +1,11 @@
 export function hi() {
-  alert(`Hello`);
+  alert(`สวัสดี`);
 }
 
 export function bye() {
-  alert(`Bye`);
+  alert(`ลาก่อน`);
 }
 
 export default function() {
-  alert("Module loaded (export default)!");
+  alert("โหลดโมดูลแล้ว (export default)!");
 }
diff --git a/1-js/13-modules/index.md b/1-js/13-modules/index.md
index 78fb060e8..5566d00f8 100644
--- a/1-js/13-modules/index.md
+++ b/1-js/13-modules/index.md
@@ -1,2 +1,2 @@
 
-# Modules
+# โมดูล