Series này gồm 4 phần chính:

• Phần 1: Giai đoạn trước 2005 – JavaScript là cái thứ chi chi
• Phần 2: Giai đoạn 2005-2010 – Thời đại của jQuery
• Phần 3.1: Giai đoạn 2010-2014 – JS Framework trỗi dậy
• Phần 3.2: Giai đoạn 2010-2014 – NodeJS náo loạn giới front-end
• Phần 4.1: Giai đoạn 2014 đến nay – NodeJS, BabelJS, Webpack, ReactJS – Tứ đại thiên vương (tạm thời) của JS
• Phần 4.2: Web front-end hiện đại có gì hot

Ở phần trước, chúng ta đã tìm hiểu về sự ra đời của khái niệm Client Side Rendering, sự xuất hiện của những JS framework phổ biến như AngularJS, EmberJS, BackboneJS.

Ở phần này, chúng ta sẽ nói về NodeJS và công cụ của giới front-end trong giao đoạn 2010-2014.

Cùng tìm hiểu tại sao NodeJS – một thứ dùng để “viết JavaScript ở phía back-end” lại được dùng vào các dự án front-end nhé!

NodeJS là cái chi chi?

Muốn tìm hiểu về sự ra đời của NodeJS, các bạn có thể xem lại JS Truyền Kì phần 2 nhé.

Có thể tạm hiểu NodeJS là một runtime environment, cho phép ta viết JS ở phía server.

Từ trước đến này, JavaScript chỉ có thể chạy ở trong trình duyệt. JavaScript chỉ có thể làm những thứ trình duyệt có thể làm như: Chỉnh sửa HTML, gửi nhận HTTP Request.

Thế nhưng, với NodeJS, ta có thể dùng JavaScript để làm những điều sau:

• Làm việc trực tiếp với hệ điều hành: Đọc/ghi file, lắng nghe kết nối tới các port
• Nhận dữ liệu, ghi dữ liệu ra command line
• Phân tách code thành các module rõ ràng, không “dồn đống” như JavaScript ở client side.

Tại sao lại dùng NodeJS ở front-end?

Ừm, NodeJS mạnh thật đấy, cho nó nằm ở back-end đi. Vậy tại sao ta lại dùng NodeJS ở front-end để làm gì?

Ở bài trước, mình đã nói về 5 vấn đề mà dân front-end cần xử lý ở giai đoạn này là:

• Package Management
• Module/Dependency Management
• Testing
• Code Transformation
• Task Runner

Đối với dân developer tụi mình, cách tốt nhất để giải quyết vấn đề chính là … đẻ ra một vấn đề mới hơn, nhầm, là viết tool để giải quyết vấn đề đó!

Mà dân front-end thì rành ngôn ngữ gì nhất nè? Dĩ nhiên là JavaScript rồi. Thế là NodeJS được dân front-end sử dụng để viết tool cho giới front-end dùng luôn!

Có thể nói, JavaScript framework và NodeJS tooling chính là 2 nhân tố chính gây nên cuộc cách mạng trong cộng đồng front-end (và làm JavaScript đã rối nay càng rối).

Tổng quan về tool cộ của front-end

Dân chơi front-end có rất nhiều “tool cộ” để giải quyết vấn đề của mình. Chỉ cần đọc xong phần này, bạn có thể hiểu tổng quan về những tool này cùng những vấn đề mà chúng giải quyết.

Toàn bộ những tool mình nhắc đến trong bài đều được viết bằng NodeJS. Do vậy, dự án nào dùng những tool này thì dĩ nhiên phải cài NodeJS vào rồi.

Note: Mình chỉ lướt sơ qua thôi nhé, chớ đi sâu vào chi tiết thì mỗi tool cũng đủ viết hết 1 bài blog đó.

1. Package Management

Ngày xưa, mỗi khi cần thêm thư viện gì đó, chúng ta làm như sau:

1. Google tìm trang chủ của thư viện đó
2. Tải file JavaScript và CSS của thư viện đó về máy
3. Include vào HTML (Hoặc dán link cdn vào HTML)

Cách này có một số giới hạn:

• Ta phải cho toàn bộ những thư viện (không hề nhẹ) này vào source control.
• Mỗi lần cần tạo project mới phải copy toàn bộ qua
• Đôi khi các thư viện phụ thuộc vào nhau, phải bỏ đúng thứ tự
• Việc update, quản lý version rất khó khăn, ta phải tải file mới về đè file cũ, sửa reference trong HTML

Bower là một package manager cho front-end, ra đời năm 2012. Với bower, khi cần tải một package, ta chỉ việc gõ

bower install <package>

Bower sẽ tự động lo vụ tải về, lưu những package đã tải vào bower.json để restore lại khi cần.

Để tìm hiểu thêm về cơ chế hoạt động của Packager Manager, các bạn có thể xem lại bài viết “Developer cần biết gì về Package Manager” nhé!

2. Module/Dependency Management

Một nhược điểm chết người, chết cha chết mẹ, của JavaScript là … nó không có namespace hay module gì sất.

Do không có module, việc quản lý dependency giữa các thành phần trong code rất khó khăn. Ta phải đảm bảo các file được đặt đúng thứ tự, mỗi file không được tạo ra global variable vì sẽ ảnh hưởng đến file khác.

Một số chuẩn cho module của JS ra đời:

• AMD (Asynchonous Module Definition)
• CommonJS (NodeJS implement 1 phần chuẩn này),
• ES2015 Modules

Dựa theo những chuẩn này, một số thư viện & tool ra đời, giúp ta có thể phân tách code JavaScript thành module cho dễ quản lý. Các tool này được gọi chung là module bundler hoặc module loader.:

• RequireJS (2011) – Hỗ trợ chuẩn AMD
• Browserfy (2011) – Hỗ trợ 1 phần chuẩn CommonJS, tương tự NodeJS
• Webpack (2012)

3. Code transformation

Trước đây, source code JS với CSS thế nào thì ta bỏ vào browser y như vậy. Tuy nhiên, với sự ra đời của LESS, TypeScript, CoffeeScript, ta cần một số tool để biến LESS thành CSS, biến TypeScript thành JavaScript.

Ngoài ra, để optimize tốc độ tải ở front-end, ta phải thực hiện bundle (gom nhiều file lại thành 1 file) và minify (bỏ khoảng trắng, đổi tên biến cho ngắn).

Nổi bật nhất trong giai đoạn này là LESS, SASS, TypeScript. BabelJS thì mãi đến cuối 2014 mới xuất hiện.

4. Testing

Đến giai đoạn này, logic ở front-end cũng đã phức tạp không kém back-end. Nhờ có chia code thành nhiều module, có dependency injection (AngularJS) nên việc mock, test cũng đơn giản hơn.

Hai testing framework phổ biến hồi ấy là Mocha và Jasmine (giờ vẫn còn phổ biến nha), gần đây thì có thêm Jest của Facebook nữa.

5. Task Runner

Với đủ thứ tool cộ đã cài đặt sẵn, một dự án front-end trở nên phức tạp hơn rất nhiều.

Thông thường, muốn chạy code của một dự án, ta làm những việc sau:

1. Chạy Unit Test
2. Chạy Linter
3. Optmize lại font, file ảnh
4. Xóa file CSS, JS cũ
5. Tranform code LESS sang CSS, ES6 sang ES5 v…v
6. Bundle & Minify CSS và JavaScript
7. Build file HTML cuối cùng
8. Mở browser lên, hiển thị trang web để bắt đầu test và code

Những task này rất rườm rà, nhiều khê, mang tính chất lặp đi lặp lại. Do vậy, chúng ta sử dụng task runner để tự động hóa.

Có thể nói, task runner chính là xương sống của một dự án front-end. Có task runner ta mới có thể setup code transform, code minify, unit test.

Hai Task Runner được sử dụng nhiều nhất ở thời kì này là:

• Grunt – Ra đời ngày 11/01/2012
• Gulp – Ra đời ngày 18/07/2013

Gulp được dùng nhiều hơn Grunt vì … mới hơn, đơn giản hơn, nhanh hơn và dễ config hơn.

Tạm kết

Phù, sau một hồi dài ngoằng thì chúng ta đi được hơn nửa chặng đường lịch sử của JavaScript và front-end rồi!

Đến đây chắc bạn đọc cũng váng đầu hoa mắt với đống tool cộ JavaScript của giới front-end rồi, nên mình tạm dừng bài viết tại đây.

Ở phần sau (chắc là phần cuối), mình sẽ giới thiệu những framework mới nhất, những tool và best practice mới nhất mà giới front-end hiện tại đang sử dụng nhé!

 

Bonus: Bạn đầu tiên đọc đúng tên các công nghệ trong tấm hình này, comment bên dưới sẽ được quyền request mình viết bài theo chủ đề (trong khả năng của mình) nha.

 

P/S: Cho bạn nào chưa biết thì Bootstrap cũng ra đời vào khoảng thời gian này, tầm giữa năm 2011 nhé!

Bootstrap cung cấp 1 số style, component, icon có sẵn nên rất đẹp và tiện lợi. Nhà nhà thích bootstrap, người người dùng Bootstrap,

Trước khi có Bootstrap, trang nào không có design cũng đều xấu xấu tởm tởm. Sau khi có bootstrap, trang nào không có design đều đỡ xấu hơn, nhưng nhìn là biết ngay dùng Bootstrap.