Tìm hiểu về modules trong Node.js. Tại sao lại có nhiều loại modules như vậy?

Tìm hiểu về modules trong Node.js. Tại sao lại có nhiều loại modules như vậy?

Tin ngắn hàng ngày dành cho bạn
  • Từ lâu rồi suy nghĩ làm thế nào để tăng sự hiện diện thương hiệu, cũng như người dùng cho blog. Nghĩ đi nghĩ lại thì chỉ có cách chia sẻ lên mạng xã hội hoặc trông chờ họ tìm kiếm, cho đến khi...

    In cái áo này được cái tắc đường khỏi phải lăn tăn, càng đông càng vui vì hàng trăm con mắt nhìn thấy cơ mà 🤓

    (Có tác dụng thật nha 🤭)

    » Xem thêm
  • Một vòng của sự phát triển nhiều dự án khá là thú vị. Tóm tắt lại trong 3 bước: Thấy một cái gì đó phức tạp -> Làm cho nó đơn giản đi -> Thêm thắt tính năng cho đến khi nó phức tạp... -> Quay trở lại vòng lặp mới.

    Tại sao lại như vậy? Để mình lấy 2 ví dụ cho các bạn thấy.

    Markdown ra đời với mục tiêu tạo ra một định dạng văn bản thô "dễ viết, dễ đọc, dễ dàng chuyển thành một dạng gì đó như HTML". Vì thời đó chẳng ai đủ kiên nhẫn mà vừa ngồi viết vừa thêm định dạng cho văn bản hiển thị ở trên web như thế nào. Ấy vậy mà giờ đây người ta đang "nhồi nhét" hoặc tạo ra các biến thể dựa trên markdown để bổ sung thêm nhiều định dạng mới đến mức... chẳng nhớ nổi hết cú pháp.

    React cũng là một ví dụ. Từ thời PHP, việc khát khao tạo ra một cái gì đó tách biệt hẳn giao diện người dùng và phần xử lý logic chính của ứng dụng thành 2 phần riêng biệt cho dễ đọc, dễ viết. Kết quả là các thư viện UI/UX phát triển rất mạnh mẽ, mang lại khả năng tương tác với người dùng rất tốt, còn phần logic ứng dụng thì nằm ở một máy chủ riêng biệt. Bộ đôi Front-end, Back-end cũng từ đấy mà thịnh hành, không thể thiếu anh bồi bàn REST API. Ấy vậy mà giờ đây React trông cũng không khác biệt gì so với PHP là mấy, kéo theo là cả Vue, Svelte... lại cùng quy tất cả về một mối.

    Cơ mà không phải vòng lặp là xấu, ngược lại vòng lặp này mang tính tiến hoá nhiều hơn là "cải lùi". Nhiều khi lại tạo ra được cái hay hơi cái cũ thế là người ta lại dựa trên cái hay đó để tiếp tục lặp. Nói cách khác là chắc lọc tinh hoa từng tí một tí một á 😁

    » Xem thêm
  • Song song với các dự án chính thức thì thi thoảng mình vẫn thấy các dự án "bên lề" nhằm tối ưu hoặc cải tiến ngôn ngữ theo khía cạnh nào đó. Ví dụ nature-lang/nature là một dự án hướng tới cải tiến Go, mang lại một số thay đổi nhằm giúp cho việc sử dụng Go trở nên thân thiện hơn.

    Nhìn lại mới thấy hao hao JavaScript 😆

    » Xem thêm

Vấn đề

Khi viết ứng dụng Vue.js hay React.js, bạn thường hay sử dụng cú pháp import để sử dụng một component hay một module nào đó. Còn với các ứng dụng Node.js thuần JS sẽ thường dùng require:

const fs = require('fs'); // CommonJS
// hay
import { Component } from 'React'; // ES6 module

Hoặc đôi khi bạn cũng có thể bắt gặp trường hợp khai báo module bằng cách sử dụng cú pháp của AMD (Asynchronous Module Definition) như ở dưới đây:

define(['jquery'] , function ($) {
    return function () {};
});

Từ những ví dụ trên, đã bao giờ các bạn thắc mắc tại sao có lúc lại dùng được import, có lúc lại dùng require hay thậm chí tại sao khi bắt đầu viết một ứng dụng Node.js lại không thể sử dụng cú pháp import một cách bình thường?

// file index.js
import * as fs from "fs";
fs.mkdir('/temp/temp', () => console.log("success"));

Khởi chạy:

$ node index.js
(node:2912) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.  
/Users/hoaitx/index.js:1
import * as fs from "fs";
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at wrapSafe (internal/modules/cjs/loader.js:931:16)
    at Module._compile (internal/modules/cjs/loader.js:979:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1035:10)
    at Module.load (internal/modules/cjs/loader.js:879:32)
    at Function.Module._load (internal/modules/cjs/loader.js:724:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)
    at internal/main/run_main_module.js:17:47

Thì một lỗi sẽ được trả ra như ở trên! Vậy sự khác biệt giữa chúng là gì và tại sao lại có những sự khác biệt đó? Bài viết dưới đây hy vọng sẽ giúp các bạn giải đáp được những thắc mắc ở trên.

1. CommonJS và AMD

Cho những ai chưa biết thì require là cú pháp của CommonJS, chúng được sử dụng để làm hệ thống modules cho Node.js từ những ngày đầu. Mục tiêu của CommonJS là đưa ra một hệ thống module cho các ứng dụng Node.js. Bởi ngay từ đầu Node.js ra đời thì Javascript vẫn chưa có một hệ thống module chính thức nào cho ngôn ngữ này. Một đặc tính của CommonJS là chúng được thiết kế để "tải" các module một cách đồng bộ và điều này thực sự không tốt cho mô hình trình duyệt (browser), khi mà các module được tải đồng bộ sẽ khiến hiệu năng tải trang bị giảm đi đáng kể.

Trái lại với CommonJS thì AMD được thiết kế để phù hợp hơn với môi trường trình duyệt. RequireJS là một triển khai tiêu biểu của AMD. Tính năng mới trong AMD là define() cho phép khai báo các phụ thuộc của một module nó trước khi được tải.

define('module/id/string', ['module', 'dependency', 'array'], 
function(module, factory function) {
    return ModuleContents;  
});

Việc tải module trong AMD có thể thực hiện một cách bất đồng bộ sẽ khiến cho hiệu năng tải trang được cải thiện hơn so với việc tải đồng bộ.

AMD modules

Tóm lại, CommonJS và AMD là các đặc tả module Javascript có các cách triển khai khác nhau. CommonJS được sử dụng nhiều hơn ở ứng dụng phía máy chủ (Node.js) còn AMD được sử dụng nhiều hơn ở ứng dụng phía máy khách (trình duyệt).

AMD thuở ban đầu là một đặc tả dự thảo cho định dạng module trong của CommonJS, nhưng không đạt được sự đồng thuận của cộng đồng phát triển thế nên nó được chuyển sang nhóm amdjs. Các tranh luận chủ yếu xoay quanh việc tìm ra định dạng nào là tốt hơn, và cuối cùng CommonJS được tạo ra cho sự phát triển ứng dụng phía máy chủ vì tính chất đồng bộ của nó và AMD phù hợp hơn cho phát triển phía máy khách (trình duyệt) với tính chất không đồng bộ. *Tham khảo*.

2. ES6 Module (ESM)

Và từ khi ES6 được giới thiệu, lúc này nó đã mang đến hệ thống module chính thức cho Javascript. Vậy thì mọi thứ về module đã được giải quyết? Cú pháp của ESM chủ yếu xoay quanh importexport các từ khoá:

import * as fs from "fs"; // import
export * from "fs"; // export

ECMAScript (ES) cũng chỉ là một đặc tả và việc áp dụng những đặc tả đó là do các nhà phát triển phần mềm (trình duyệt web, Node.js...), hay thậm chí có những ứng dụng cũ hơn đã bị ngưng cập nhật (trình duyệt IE) và chúng hoàn toàn không có khả năng để xử lý những tính năng mới nhất của ES. Chính vì thế, hiện nay chúng ta đã có khá nhiều công cụ hỗ trợ cho việc chạy mã JS ở các phiên bản Node.js, trình duyệt cũ hơn. Điều đó giúp cho chúng ta không cần quá quan tâm về việc sử dụng những cú pháp mới hơn của ES.

Một số công cụ như Babel, Webpack có tích hợp công cụ hỗ trợ chúng ta chuyển đổi mã từ ES6 trở đi thành mã ES5 mà đa số trình duyệt cũ có thể hiểu được.

Để bắt kịp xu thế, Node.js đã cập nhật việc hỗ trợ ESM từ phiên bản v12 LTS tuy nhiên cho đến hiện tại (v14 LTS) ESM vẫn đang là tính năng được thực nghiệm.
Có một số cách để "hợp thức hoá" việc sử dụng ESM trong các phiên bản Node.js từ 12 trở lên, bao gồm:

  • Đặt tên file có phần mở rộng .mjs
  • Thêm thuộc tính "type" có giá trị là "module" trong file package.json
  • Hoặc sử dụng flag --input-type trong command.
// file index.mjs
import * as fs from "fs";
fs.mkdir('/temp/temp', () => console.log("success"));
$ node index.mjs
(node:3933) ExperimentalWarning: The ESM module loader is experimental.  
success

3. Tổng kết

CommonJS và AMD đã những đặc tả về module đã ra đời từ trước khi ESM được giới thiệu kể từ ES6. ESM mới thực sự là hàng "chính chủ", nhưng sự phổ biến của CommonJS đã khiến cho nó trở thành module mặc định của Node.js.

Ngày nay, với sự phát triển của các công cụ hỗ trợ dịch mã từ ES cao hơn xuống ES thấp hơn khiến cho việc viết mã Javascript như đang dùng cú pháp mới nhưng đằng sau nó là mã đã được dịch về phiên bản ES cũ hơn để tương thích với hầu hết trình duyệt, Node.js phiên bản cũ hơn.

Cao cấp
Hello

Tôi & khao khát "chơi chữ"

Bạn đã thử viết? Và rồi thất bại hoặc chưa ưng ý? Tại 2coffee.dev chúng tôi đã có quãng thời gian chật vật với công việc viết. Đừng nản chí, vì giờ đây chúng tôi đã có cách giúp bạn. Hãy bấm vào để trở thành hội viên ngay!

Bạn đã thử viết? Và rồi thất bại hoặc chưa ưng ý? Tại 2coffee.dev chúng tôi đã có quãng thời gian chật vật với công việc viết. Đừng nản chí, vì giờ đây chúng tôi đã có cách giúp bạn. Hãy bấm vào để trở thành hội viên ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (0)

Nội dung bình luận...