- Một số nhà phát triển cho rằng framework SPA (React, AngularJS, v.v.) là yếu tố thiết yếu để phát triển ứng dụng chất lượng cao
- Tuy nhiên, ngay cả trước thời SPA, các ứng dụng dựa trên MPA vẫn đã mang lại trải nghiệm người dùng rất tốt
- Tôi đã thử phát triển một nền tảng quan sát dựa trên MPA, lấy dữ liệu làm trung tâm bằng HTMX, và với các tối ưu hóa phù hợp, MPA render phía máy chủ cũng có thể mang lại hiệu năng và trải nghiệm người dùng xuất sắc
Những ngộ nhận và sự thật liên quan đến MPA
Ngộ nhận 1: MPA chậm khi chuyển trang
- Vấn đề: theo mặc định, trình duyệt sẽ tải lại JavaScript và CSS mỗi lần chuyển trang
- Giải pháp:
- Dùng các thư viện như PJAX, Turbolinks, HTMX Boost để chỉ thay phần HTML body
- Có thể dùng service worker để cải thiện việc cache trang và xử lý request
- Ví dụ: khi áp dụng service worker, thời gian DOMContentLoaded giảm từ 2,9 giây xuống 500ms
Cách triển khai service worker
- Tạo file
sw.js: viết script quản lý cache và request mạng
- Định nghĩa danh sách file cần cache: chỉ định các tài nguyên chính như HTML, CSS, JS
- Thiết lập chiến lược cache: cache lâu dài tài sản tĩnh hoặc cập nhật theo chu kỳ
Ngộ nhận 2: MPA không thể hoạt động offline và không thể lưu request để khôi phục khi mạng trở lại
- Có thể dùng service worker để ứng dụng vẫn hoạt động ngay cả khi offline
- Tận dụng Workbox:
- Cache request khi mạng lỗi và thử lại trong vòng tối đa 24 giờ
- Thiết lập offline handler để cung cấp nội dung thay thế khi có request
Ngộ nhận 3: MPA sẽ bị nhấp nháy màn hình khi chuyển trang
- Giải pháp:
- Dùng service worker và preload API để trì hoãn việc vẽ màn hình cho đến khi tài nguyên sẵn sàng
- Từ sau năm 2019, trình duyệt xử lý chuyển đổi trong cùng domain mà không còn nhấp nháy
Ngộ nhận 4: MPA không thể triển khai hiệu ứng chuyển trang đẹp mắt
- SPA nổi tiếng với animation chuyển trang, nhưng trình duyệt cũng đã bắt đầu hỗ trợ điều này
- Trong Chrome 126, có thể triển khai animation chuyển tài liệu chéo chỉ bằng CSS
- Liên kết demo
Ngộ nhận 5: Với HTMX hay MPA, mọi thao tác người dùng đều được xử lý trên server
- HTMX được thiết kế để chỉ xử lý một phần tác vụ ở server
- Khi cần, có thể bổ sung tính năng tương tác phía client bằng WebComponents hoặc framework JavaScript
- Cũng có thể chỉ áp dụng cách làm kiểu SPA cho một số component cụ thể
Ngộ nhận 6: DOM manipulation chậm, vì vậy cần dùng React/Virtual DOM
- Virtual DOM chỉ tạo ra khác biệt về hiệu năng trong các ứng dụng cực kỳ phức tạp
- Trong phần lớn ứng dụng thông thường, thao tác trực tiếp với DOM đã đủ nhanh
- Tài liệu tham khảo: "Virtual DOM is pure Overhead"
Ngộ nhận 7: Ngay cả tính năng tương tác nhỏ cũng cần JavaScript
- Với công nghệ trình duyệt hiện đại, có thể triển khai nhiều tính năng mà không cần JavaScript
- Có thể triển khai chức năng bật/tắt bằng checkbox HTML và CSS
- Kết hợp HTMX để tải dữ liệu bất đồng bộ khi click
Ngộ nhận cuối cùng: Không có SPA thì mã phía client sẽ biến thành spaghetti code
- Ngay cả trong thời kỳ spaghetti code, rất nhiều phần mềm hiệu quả vẫn đã được phát triển
- Ở giai đoạn MVP ban đầu, cấu trúc đơn giản đôi khi lại có lợi hơn
Kết luận
- Tính đến năm 2024, trình duyệt đã tiến bộ rất nhiều khi tích hợp những gì học được từ cuộc cách mạng SPA
- Chỉ với các công cụ trình duyệt cơ bản (HTML, CSS, JavaScript), vẫn có thể xây dựng ứng dụng tương tác và hoạt động được khi offline
- Hãy tin vào tiềm năng của trình duyệt và thử tận dụng nó thêm một lần nữa
8 bình luận
Nếu từng làm dự án với những lập trình viên năng lực bình thường thì sẽ nhận ra ngay câu chuyện này viển vông đến mức nào. Có vẻ người viết bài này либо là đang làm việc giữa toàn thiên tài, либо là làm một mình... (nhìn cách giờ còn nhắc tới AngularJS lỗi thời cũng đủ thấy rồi). Với lại, phát triển phần mềm đâu phải chỉ được làm bởi thiên tài.
Có người sẽ hạ thấp điều đó là “chỉ tụ tập với nhau theo nhóm”, nhưng từ trước đến nay, thay đổi luôn được tạo ra bởi những con người bình thường.
Càng đọc kiểu này lại càng khiến tôi nghĩ rằng htmx tuyệt đối không nên được chấp nhận.
Đây là một chủ đề dạo gần đây cứ liên tục được nhắc đến.
Có một video trong đó Rich Harris đã chia sẻ quan điểm của mình về chủ đề này từ vài năm trước.
https://www.youtube.com/watch?v=860d8usGC0o&t=635s
Nếu nhớ không nhầm thì có thể tóm lại là: các cách cập nhật dựa trên partial HTML có khả năng tạo ra sự không nhất quán giữa giao diện và dữ liệu.
Bạn vẫn còn tin vào đặc tả trình duyệt sao...?
Nói cho đúng thì, tôi nghĩ SPA là một phương pháp phát triển ứng dụng ít phụ thuộc hơn vào cách trình duyệt vận hành.
Đúng là trình duyệt đã theo kịp khá nhiều những khả năng tuyệt vời của SPA, và điều đó trông có vẻ hợp hơn với phương thức giao tiếp ban đầu được thiết kế cho HTTP, nhưng có lẽ cũng là vì Chrome đã có vị thế gần như độc quyền trong thế giới trình duyệt nên mới có được dư địa như vậy... Tôi không biết liệu chuyện này có kéo dài được bao lâu, dù là dư địa hay thị phần...
Nếu là kiểu thao tác DOM từ phía server dựa trên websocket như
phoenix liveviewthì đó là một paradigm khác.Khi thử dùng
htmx, tôi thấy việc server phải trả về các mảnh HTML bị chia nhỏ không thật sự dễ chịu cho lắm.Đặc biệt ở phần CSS, nếu gán class rồi trả xuống thì từ phía server không thể biết được CSS nào đang được dùng trên giao diện, nên trên thực tế có cảm giác gần như đang ép dùng CSS dùng chung.
Vài năm trước tôi từng thử xây dựng một UI khá phức tạp bằng Phoenix LiveView, nhưng việc triển khai các tương tác đơn giản lại quá rắc rối, và vì mỗi LiveView được xử lý bởi một tiến trình Elixir riêng nên việc tương tác với component bên cạnh rất khó. Cuối cùng tôi đã bỏ cuộc và quay lại với React.
Tôi thấy liveview giống như tương lai vậy…
LiveView cũng phụ thuộc khá nhiều vào mạng, nên nếu máy chủ ở xa khiến ping cao, hoặc ở các khu vực như thế giới thứ ba nơi hạ tầng internet không tốt, thì đây là một điểm yếu khá lớn.
Ý kiến trên Hacker News
Có ý kiến thắc mắc vì sao bài viết không đề cập đến cách tận dụng bộ nhớ đệm của trình duyệt để quản lý các tài sản CSS và JS tĩnh. Trước đây khi xây dựng một trang mua sắm theo kiểu MPA, việc chuyển trang hầu như không thể nhận ra
Cũng có người cho rằng phát triển web thời PHP và jQuery là năng suất nhất. Có ý kiến băn khoăn liệu mô hình cũ có thể còn năng suất hơn các công nghệ hiện đại như React hay không. Các trang lớn như Amazon hay Steam vẫn được xây dựng theo cách render HTML trên máy chủ rồi bổ sung JS
Có ý kiến yêu cầu giải thích chiến lược service worker tốt hơn ở điểm nào so với các header bộ nhớ đệm HTTP truyền thống. Dù có thể giảm số vòng khứ hồi mạng, nhưng vẫn tạo cảm giác như đang phát minh lại toàn bộ chỉ vì một tối ưu nhỏ
Tiêu đề "You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths" tạo cảm giác câu kéo nhấp chuột vì phần ý nghĩa bị lược đi
Điều nguy hiểm nhất trong lập trình là sự nhàm chán của lập trình viên và sự thiếu hiểu biết về quá khứ
Có ý kiến không hiểu vì sao lại tồn tại sự phân đôi giữa phía máy chủ và phía máy khách (SPA) trong thời đại máy chủ web Node.js. Có người đặt câu hỏi liệu có thể khởi tạo phần lớn công việc trên máy chủ, rồi tuần tự hóa sang máy khách để nó hoạt động như một SPA hay không
Có xu hướng xem SPA và MPA như hai phe đối lập, nhưng cũng có thể phân biệt giữa cách sử dụng ngăn xếp web một cách tự nhiên và cách làm kiểu "hack". SPA hiện là cách làm kiểu hack, nhưng trước đây từng có CGI, Java applet, Flash... Những cách làm kiểu hack đóng vai trò mở rộng giới hạn của phương pháp tự nhiên
Trước cả việc quyết định công nghệ, nhiều nhà phát triển thường hiểu sai về thứ mình đang xây dựng. Nếu không cần mức độ tương tác cao, thì trong đa số trường hợp chỉ cần framework phía máy chủ là đủ
Có phản biện đối với huyền thoại "không phải ứng dụng một trang thì không thể làm ứng dụng web tương tác". SPA cung cấp khả năng kiểm soát nhiều hơn và giúp giảm khả năng phải làm lại một phần mã nguồn
Tiêu đề trên HN mang tính công kích hơn tiêu đề thật. Đây là một bài luận do Tony Alaribe trình bày tại BigSkyDevCon, bàn về các kỹ thuật giúp ứng dụng web không dựa trên SPA trở nên nhanh và mượt. Bài viết giới thiệu các kỹ thuật mới, và có người cho rằng đây là bài trình bày hay nhất tại hội nghị