1 điểm bởi GN⁺ 2024-09-30 | 1 bình luận | Chia sẻ qua WhatsApp

Cách xây dựng frontend vững chắc: cải tiến lũy tiến

  • Bắt đầu với HTML

    • Dịch vụ của chính phủ phải vẫn hoạt động chỉ với HTML
    • Lớp HTML có khả năng chịu lỗi, nên vẫn có thể hoạt động trên các trình duyệt cũ
    • Cần dùng semantic markup đúng cách và tổ chức cấu trúc tài liệu một cách hợp lý
  • Sử dụng CSS

    • Có thể dùng CSS để tạo kiểu cho dịch vụ
    • Lớp CSS có khả năng chịu lỗi vì có thể bỏ qua từng khai báo riêng lẻ
    • Nên tránh các kỹ thuật như 'CSS-in-JS'
  • Sử dụng JavaScript

    • JavaScript được dùng để thêm các yếu tố tương tác
    • Lớp JavaScript không có khả năng chịu lỗi và có thể phát sinh lỗi
    • Có thể tăng khả năng tương thích thông qua phát hiện tính năng cho browser API, bổ sung polyfill, transpiling, v.v.
    • JavaScript nên đóng vai trò bổ trợ cho HTML và CSS
  • Các lựa chọn thay thế cho JavaScript

    • Cần cân nhắc các giải pháp đơn giản có thể đáp ứng nhu cầu người dùng mà không cần JavaScript
    • Các lựa chọn thay thế gồm hiển thị bảng dữ liệu, xuất dữ liệu, và dựng sẵn biểu đồ dưới dạng hình ảnh
  • Sử dụng framework JavaScript phía client

    • Nếu không phải giao diện người dùng phức tạp thì nên tránh dùng framework
    • Khi dùng framework, có thể phát sinh các vấn đề như tăng kích thước codebase, vấn đề hiệu năng và phụ thuộc vào mã của bên thứ ba
    • Nếu dùng framework thì nên thiết kế từng giao diện người dùng thành các component riêng biệt
  • Lý do CSS hoặc JavaScript không được tải hoặc không chạy

    • Nguyên nhân có thể là lỗi mạng, tiện ích mở rộng trình duyệt, thời gian ngừng hoạt động của nhà cung cấp bên thứ ba, lỗi tra cứu DNS, hoặc bug do cập nhật trình duyệt
    • Một số người dùng có thể cố ý tắt các tính năng của trình duyệt
  • Ứng dụng một trang (SPA)

    • Không nên xây dựng dịch vụ dưới dạng ứng dụng một trang
    • SPA làm giảm khả năng truy cập, đồng thời có thể gây ra các vấn đề như xử lý focus khi chuyển trang, không thể dùng nút quay lại/tiến tới
  • Kiểm thử dịch vụ

    • Các thành phần phụ thuộc nhiều vào JavaScript hoặc framework JavaScript phải hoạt động trên nhiều trình duyệt và thiết bị khác nhau
    • Cần kiểm thử về khả năng truy cập
  • Nghiên cứu tình huống và hướng dẫn liên quan

    • Lý do nên dùng cải tiến lũy tiến
    • Thiết kế cho nhiều loại thiết bị
    • Cách kiểm thử hiệu năng frontend
    • Hiểu về WCAG 2.2

Tóm tắt của GN⁺

  • Cải tiến lũy tiến là phương pháp xây dựng website theo thứ tự HTML, CSS, rồi JavaScript
  • Phương pháp này giúp tăng khả năng chịu lỗi của dịch vụ và giúp nó hoạt động trên nhiều trình duyệt, thiết bị khác nhau
  • JavaScript nên đóng vai trò bổ trợ và cần cân nhắc các giải pháp thay thế
  • Nên tránh ứng dụng một trang do các vấn đề về khả năng truy cập
  • Việc kiểm thử dịch vụ phải bảo đảm khả năng truy cập trong nhiều môi trường khác nhau

1 bình luận

 
GN⁺ 2024-09-30
Ý kiến trên Hacker News
  • Khi sử dụng framework JavaScript, cần phải chứng minh được nó mang lại lợi ích gì cho người dùng

    • Nếu là ứng dụng có thể hoạt động như app desktop ngay cả khi ngoại tuyến, thì nên xây dựng dưới dạng ứng dụng một trang (SPA)
    • Ví dụ như Photopea, Google Docs/Sheets, tldraw
    • Nếu là ứng dụng cần kết nối Internet và có nhiều trang, thì nên để trình duyệt xử lý việc điều hướng
  • Những nhược điểm thường được chỉ ra của SPA

    • Người dùng công nghệ hỗ trợ có thể không nhận ra sự thay đổi ngữ cảnh khi chuyển trang
    • Không xử lý được focus khi chuyển trang
    • Không thể sử dụng nút quay lại và tiến tới của trình duyệt
    • Không thể khôi phục sau lỗi khi kết nối mạng bị ngắt
    • Tuy nhiên, các vấn đề này vẫn có thể được giải quyết ngay cả trong SPA
  • Ước gì toàn bộ Internet đều làm theo lời khuyên này

  • Nên ưu tiên các giải pháp đơn giản

  • Tò mò vì sao Linux không có trong danh sách

  • Có vẻ nhiều người thích cách tiếp cận này

    • Tò mò vì sao xu hướng phổ biến lại là sử dụng JavaScript và các framework như React một cách không cần thiết
  • Sử dụng HTML và dữ liệu được tải sẵn từ máy chủ, còn những gì có thể làm ở phía client thì xử lý ở phía client

    • Dùng CSS tối thiểu và JavaScript thuần
    • Có thể trông lỗi thời trong mắt đồng nghiệp, nhưng không bỏ lỡ điều gì
  • Nhiều SPA có vấn đề, nhưng không phải mọi SPA đều có vấn đề

    • Các ví dụ như VitePress và SolidJS cho thấy chúng hoạt động tốt
    • Hầu như không có ai không dùng JS
    • Ngay cả trên thiết bị cấu hình thấp cũng không có vấn đề trong việc xử lý JS
    • Vấn đề về khả năng truy cập không liên quan đến việc có dùng SPA hay không
    • Svelte thậm chí còn tích hợp cả tính năng cảnh báo về khả năng truy cập
  • Kết xuất phía máy chủ cũng không phải lúc nào cũng tốt

    • Cần thận trọng khi sử dụng framework JavaScript phía client
    • Codebase sẽ lớn hơn, và do có nhiều việc phải xử lý ở phía client nên có thể phát sinh vấn đề hiệu năng
    • Có thể trở nên phụ thuộc vào mã của bên thứ ba nên khó bảo trì hơn
    • Khi sử dụng framework JavaScript, cần phải chứng minh được nó mang lại lợi ích gì cho người dùng
    • Cần nhận thức được các tác động tiêu cực và có thể giảm thiểu chúng
    • Chỉ nên dùng framework cho những phần không thể xây dựng chỉ bằng HTML và CSS
    • Nên thiết kế từng phần giao diện người dùng như các component riêng biệt
    • Ngay cả khi JavaScript không được tải, phần còn lại của trang vẫn phải tải bình thường