- Dịch vụ GOV.UK phải hoạt động theo nguyên tắc ưu tiên HTML để người dùng có thể hoàn thành các tác vụ cốt lõi bất kể trình duyệt, thiết bị hay tình trạng kết nối, và mọi dịch vụ của chính phủ đều được yêu cầu áp dụng progressive enhancement
- HTML có khả năng chịu lỗi vì vẫn tiếp tục phân tích cú pháp và bỏ qua markup không biết, nên ngay cả trên trình duyệt cũ hoặc trang có một phần lỗi, khả năng cao vẫn giữ được điều hướng và chức năng cơ bản
- CSS và JavaScript là các lớp mong manh hơn: với CSS, toàn bộ tập luật có thể bị bỏ qua khi gặp selector không được hỗ trợ; với JavaScript, lỗi cú pháp hoặc lỗi API không được hỗ trợ có thể làm dừng việc thực thi phần mã còn lại
- JavaScript nên được dùng để nâng cao HTML và CSS thay vì thay thế chức năng cốt lõi; ngay cả tính năng tự động hoàn thành cũng nên được đặt trên các phần tử cơ bản như
<select>để khi lỗi xảy ra người dùng vẫn có thể tiếp tục thao tác - Các framework JavaScript phía client và SPA có thể tạo thêm gánh nặng về hiệu năng, khả năng truy cập và bảo trì, nên không cần thiết cho các dịch vụ chủ yếu dựa trên GOV.UK Design System thay vì UI phức tạp
Các nguyên tắc cơ bản của progressive enhancement
- Một dịch vụ chất lượng phải được xây dựng theo cách vững chắc, và progressive enhancement là cách tiếp cận giúp website và ứng dụng hoạt động được từ HTML trước tiên
- Chỉ sau khi đã tạo được hành vi cơ bản bằng HTML mới thêm các lớp như CSS và JavaScript
- Mọi dịch vụ của chính phủ đều phải tuân theo progressive enhancement; nguyên tắc này vẫn giữ nguyên ngay cả khi một phần của dịch vụ hoặc dịch vụ cấp trên cần JavaScript
- Lợi ích thu được từ progressive enhancement gồm:
- Dịch vụ trở nên vững chắc hơn và có chất lượng cao hơn
- Khả năng hoạt động bất kể trình duyệt hay thiết bị cao hơn
- Chức năng cơ bản nhất vẫn chạy và đáp ứng nhu cầu cốt lõi của người dùng
- Khuyến khích các thực hành tốt như semantic markup, qua đó cải thiện khả năng truy cập
- Người dùng có thiết bị hạn chế hoặc kết nối yếu cũng dễ sử dụng dịch vụ hơn
- Khi dùng giải pháp COTS hoặc giao dịch vụ cho nhà cung cấp bên ngoài, nên cân nhắc đưa progressive enhancement vào các yêu cầu của chiến lược mua sắm
Bắt đầu từ HTML
- Dịch vụ của chính phủ phải hoạt động được chỉ với HTML
- Ví dụ về các dịch vụ phải hoạt động chỉ với HTML gồm:
- Dịch vụ giao dịch như biểu mẫu để người dùng cung cấp thông tin cho chính phủ
- Dịch vụ dạng smart answers, ví dụ Registering a birth abroad
- Website thiên về nội dung như foreign travel advice của GOV.UK
- Theo thiết kế, lớp HTML có khả năng chịu lỗi
- Trình duyệt sẽ bỏ qua markup mà nó không hiểu và tiếp tục phân tích cú pháp trong chừng mực có thể
- Ngay cả khi HTML có bug hoặc dùng tính năng chỉ có trên trình duyệt mới, trình duyệt cũ vẫn có khả năng tải được dịch vụ
- Người dùng phải có thể điều hướng dịch vụ chỉ với HTML
- Cần dùng semantic markup đúng và tổ chức thứ tự nguồn và cấu trúc tài liệu một cách logic
Cách dùng CSS
- CSS có thể được dùng để tạo kiểu cho dịch vụ trông giống GOV.UK
- Lớp CSS có khả năng chịu lỗi tương đối
- Trình duyệt sẽ bỏ qua từng khai báo mà nó không hiểu
- Nếu dùng thuộc tính chỉ có trên trình duyệt mới thì chỉ khai báo đó có thể bị bỏ qua
- Tuy nhiên, khi trình duyệt gặp selector mà nó không hiểu, nó có thể bỏ qua toàn bộ tập luật
- CSS có thể không tải được vì nhiều lý do
- Để trang vẫn hiển thị đúng ngay cả khi JavaScript không tải được, nên tránh các kỹ thuật như CSS-in-JS
Cách dùng JavaScript
- JavaScript có thể được dùng để thêm các yếu tố tương tác vào dịch vụ
- Lớp JavaScript không có khả năng chịu lỗi
- Nếu dùng cú pháp hoặc gọi API mà trình duyệt của người dùng không hỗ trợ thì sẽ phát sinh lỗi
- Khi có lỗi, phần JavaScript còn lại sẽ không được thực thi
- Nếu thiết kế dịch vụ mà không tính đến khả năng này, người dùng có thể không sử dụng được dịch vụ
- Những cách giúp tăng khả năng JavaScript chạy đúng trên nhiều trình duyệt gồm:
- Dùng feature detection cho API của trình duyệt
- Thêm polyfill cho các tính năng trình duyệt mới
- Transpile JavaScript sang cú pháp phổ biến mà các trình duyệt mục tiêu có thể hiểu
- Dùng kiểm thử tự động hoặc linter
- Kiểm thử thủ công định kỳ, bao gồm cả trên thiết bị cũ hoặc hiệu năng thấp
- Transpile và polyfill có thể làm tăng đáng kể kích thước JavaScript
- Cần cân nhắc các đánh đổi liên quan
- Vì mức độ sử dụng trình duyệt thay đổi theo thời gian, các quyết định này cần được xem xét lại định kỳ
- Khi có thể, JavaScript nên nâng cao HTML và CSS vốn đã cung cấp cùng chức năng cốt lõi
- Tự động hoàn thành có thể được xây dựng bằng cách nâng cao phần tử
<select>hoặc phần tử cơ bản tương tự - Ngay cả khi JavaScript lỗi, người dùng vẫn có thể tiếp tục thực hiện tác vụ cần thiết
- Tự động hoàn thành có thể được xây dựng bằng cách nâng cao phần tử
Các lựa chọn thay thế cho JavaScript và kênh bổ sung
- Nếu cho rằng dịch vụ chỉ có thể được xây dựng bằng JavaScript, trước tiên nên xem liệu một giải pháp đơn giản hơn làm bằng HTML và CSS có thể đáp ứng nhu cầu người dùng hay không
- Nếu muốn cung cấp biểu đồ tương tác bằng JavaScript, có thể cân nhắc các lựa chọn thay thế sau:
- Hiển thị dữ liệu dưới dạng bảng
- Cho phép xuất dữ liệu để phân tích trong ứng dụng khác
- Render sẵn biểu đồ thành hình ảnh
- Nếu không thể cung cấp chức năng cốt lõi của dịch vụ mà không dùng JavaScript, cần chuẩn bị cách để người dùng sử dụng dịch vụ qua kênh khác
- Điện thoại
- Đến trực tiếp văn phòng
Framework JavaScript phía client
- Nếu dịch vụ chủ yếu được tạo từ các component của GOV.UK Design System và không có UI phức tạp thì không cần framework JavaScript phía client
- Các component của GOV.UK Design System có kèm cách đưa JavaScript vào dịch vụ mà không cần framework
- JavaScript framework phía client có thể hữu ích khi xây dựng UI phức tạp, nhưng đồng thời cũng có thể đưa vào nhiều vấn đề
- Các vấn đề có thể phát sinh khi dùng framework gồm:
- Làm tăng kích thước toàn bộ codebase và đẩy xử lý sang phía client, gây vấn đề hiệu năng cho người dùng mạng chậm hoặc thiết bị cấu hình thấp
- Khiến dự án phụ thuộc vào mã bên thứ ba mà nhà phát triển không kiểm soát, nên việc theo kịp thay đổi của framework có thể đòi hỏi chỉnh sửa lớn trong dịch vụ
- Nếu framework dần mất phổ biến theo thời gian, có thể khó tìm người có kỹ năng cần thiết để bảo trì
- Nếu dùng JavaScript framework thì cần đáp ứng các điều kiện sau:
- Phải có bằng chứng để biện minh JavaScript mang lại lợi ích gì cho người dùng
- Phải hiểu và có thể giảm thiểu các tác động tiêu cực
- Phải cân nhắc liệu lợi ích có lớn hơn các vấn đề tiềm ẩn hay không
- Chỉ nên dùng framework cho những phần UI không thể tạo chỉ bằng HTML và CSS
- Mỗi phần của UI nên được thiết kế thành component riêng biệt
- Khi tách component, nếu JavaScript không tải được thì chỉ component đó lỗi, còn phần còn lại của trang vẫn tải bình thường
- JavaScript chỉ nên được dùng để nâng cao HTML và CSS, và ngay cả khi lỗi người dùng vẫn phải sử dụng được dịch vụ
Vì sao CSS và JavaScript có thể thất bại
- CSS và JavaScript có thể không tải hoặc không chạy vì nhiều lý do
- Lỗi mạng tạm thời
- Extension trình duyệt bên thứ ba như trình chặn quảng cáo
- Nhà cung cấp bên thứ ba bị downtime khi dùng mạng phân phối nội dung
- Lỗi tra cứu DNS
- Bug phát sinh từ bản cập nhật trình duyệt
- Bug trong JavaScript bên thứ ba được cố ý chạy trên cùng trang
- Firewall doanh nghiệp tại các tổ chức lớn như ngân hàng hoặc cơ quan chính phủ chặn, loại bỏ hoặc thay đổi nội dung
- Nhà mạng di động thay đổi nội dung để giảm thời gian tải và băng thông sử dụng
- Firewall cá nhân hoặc phần mềm antivirus thay đổi hoặc chặn nội dung
- Trên kết nối không an toàn, nhà cung cấp Internet chèn mã riêng vào trang và mã đó xung đột với mã của dịch vụ
- Một số người dùng có thể chủ động tắt tính năng của trình duyệt
- Dịch vụ phải tôn trọng lựa chọn của người dùng và vẫn cho phép họ tiếp tục sử dụng
Vì sao nên tránh single-page application (SPA)
- Không nên xây dựng dịch vụ thành single-page application (SPA)
- SPA là cách mà việc tải trang trong dịch vụ được JavaScript xử lý thay vì trình duyệt
- SPA hầu như không mang lại lợi ích và có thể làm giảm khả năng truy cập
- Người dùng công nghệ hỗ trợ có thể không nhận ra cùng một thay đổi ngữ cảnh đã xảy ra khi chuyển sang trang mới
- Có thể không xử lý được focus khi chuyển trang
- Người dùng có thể không điều hướng được bằng nút quay lại và tiến tới của trình duyệt
- Người dùng có thể không phục hồi được sau các lỗi như mất kết nối mạng
Tiêu chí kiểm thử
- Nếu một số component của dịch vụ phụ thuộc nhiều vào JavaScript hoặc JavaScript framework, cần xác nhận rằng chúng:
- Hoạt động trên nhiều trình duyệt và thiết bị khác nhau
- Hoạt động cùng công nghệ hỗ trợ
- Được kiểm thử để đảm bảo hiệu năng tốt
- Nếu có thể, nên dùng kiểm thử khả năng truy cập để xác nhận các component đó hoạt động đúng trong dịch vụ
1 bình luận
Ý kiến trên Hacker News
“Nếu dùng framework JavaScript, bạn phải có khả năng biện minh bằng lý do xác đáng rằng việc dùng JavaScript mang lại lợi ích gì cho người dùng” — thôi nào, mọi người bình tĩnh chút đi
Một tiêu chí tốt là: nếu ứng dụng có thể hoạt động theo kiểu ưu tiên ngoại tuyến như ứng dụng desktop, thì làm thành ứng dụng một trang cũng ổn
Ví dụ như Photopea, Google Docs/Sheets, tldraw; trong những trường hợp này, nó có thể nhanh nhạy và tốt hơn ứng dụng trình duyệt nhiều trang
Làm vậy sẽ loại bỏ các nhược điểm lớn nhất: chuyển trang và nhu cầu có kết nối Internet
Nhưng nếu ứng dụng cần kết nối Internet và nhiều trang, thì tốt hơn nên để trình duyệt xử lý điều hướng theo cách chống chịu lỗi tốt
Nếu cần thứ gì đó giống GUI desktop khi ngoại tuyến hoặc trên nhiều hệ điều hành, ứng dụng một trang có lợi thế; còn nếu chỉ muốn làm website, ứng dụng một trang có thể không phải lựa chọn tối ưu
Bản thân ứng dụng một trang và độ phức tạp để tạo ra nó là hai chuyện khác nhau
Tôi bắt đầu làm web khi còn là trẻ con vào thập niên 90. Tôi còn không biết CSS hay JS là gì; với tôi JS chỉ là thứ script ma thuật để sao chép-dán cho cái gì đó nhấp nháy
Sau này tôi làm các site động bằng PHP cho doanh nghiệp địa phương, và lúc đó cũng học được phần nào JS và CSS
Rồi tôi bỏ phát triển web vì ghét việc tốn quá nhiều thời gian để khiến mọi thứ chạy được trên những trình duyệt tệ hại như IE6
Tôi rời xa gần 6 năm rồi quay lại khoảng năm 2015, vì nhận ra máy chủ web sẽ hữu ích cho công việc mình đang làm
Nhưng tôi sốc khi thấy thế giới đã quên rất nhiều điều từng biết về HTML và CSS
Ngày xưa người ta tạo nhiều stylesheet cho site, trước hết làm cho nó chạy được khi không có JS rồi mới thêm JS như một lớp cải tiến; cách làm đó đã bị lãng quên
Tôi cũng thấy các lập trình viên web thực hiện toàn bộ xác thực form chỉ bằng JS và không làm gì trên máy chủ; đáng ngạc nhiên là đến giờ chuyện này vẫn phổ biến
Tôi không rõ mẫu thông dụng “máy chủ xác thực, còn JS chỉ hiển thị kết quả” ở đâu nữa. Có vẻ mọi người hoặc triển khai trùng lặp, hoặc hoàn toàn không xác thực phía máy chủ
Sau khi thấy những điều đó, tôi không còn ấn tượng với những gì người ta làm trên web nữa. Đó không còn là web mà tôi biết, chỉ là “ứng dụng” viết bằng JS, và việc chủ trương ưu tiên web là một trận chiến đang thua
Hồi nhỏ tôi bắt đầu với HTML 3.2/XHTML và CSS, vài năm sau làm Django + jQuery rồi bị cuốn sang mảng hạ tầng
Khoảng một năm trước tôi làm việc cùng một đội phát triển web và xem họ làm gì, nhưng tôi không còn hiểu gì nữa
Độ phức tạp quá choáng ngợp; có vẻ phần lớn thời gian được dùng để quản lý độ phức tạp như giảm thời gian build, xử lý vấn đề phụ thuộc, xử lý các lỗi TypeScript kỳ quặc, xử lý lỗi ở nhiều component
Thời Django+jQuery, trọng tâm vẫn là thứ người dùng có thể nhìn thấy và sử dụng
Tất nhiên tuyệt đối không thể tin client, nên sau đó vẫn phải xác thực lại trên máy chủ
Giảm tải máy chủ là việc hữu ích
Lời khuyên thì hay, nhưng các câu như “người dùng công nghệ hỗ trợ không thể nhận biết cùng một thay đổi ngữ cảnh khi chuyển sang trang mới”, “không xử lý được focus khi chuyển trang”, “không thể điều hướng bằng nút quay lại/tiến của trình duyệt”, “không thể phục hồi sau lỗi khi mất kết nối mạng” — nói nghiêm ngặt thì không hẳn đúng nhỉ
Nhiều, có lẽ là đa số, ứng dụng một trang chỉ không để tâm đến chúng; nhưng trong ứng dụng một trang vẫn có thể triển khai các thứ này
Ngay khi bước vào lãnh địa ứng dụng một trang, để quay lại mức tương đương, bạn phải tái phát minh rất nhiều bánh xe, hoặc thay các tính năng native bằng bản thay thế bằng JS
Hãy nghĩ đến form nhiều trang: có bao nhiêu ứng dụng một trang lưu toàn bộ vào bộ nhớ rồi cuối cùng mới gửi một request duy nhất?
Nếu không có JS, backend hẳn sẽ lưu trạng thái của từng bước để sau này quay lại form hoặc refresh cũng không bị mất
Website HTML mặc định đã hoạt động tốt với các giá trị mặc định, vậy tại sao phải ép người ta dùng thứ rác rưởi đó
Nếu người dùng không cho phép chỉnh sửa lịch sử điều hướng sau đó, thì chỉ còn một lựa chọn
Đó là tạo lịch sử trình duyệt đúng cách vào thời điểm lịch sử được ghi
Ước gì toàn bộ Internet làm theo lời khuyên này
Cái cũ lại trở thành cái mới
Chẳng phải nên ưu tiên giải pháp đơn giản nhất có thể hơn thứ đang thịnh hành hôm nay sao
Không phải ai cũng như vậy chỉ vì phần còn lại của ngành say mê JS
Tại sao danh sách này không có Linux?
https://www.gov.uk/service-manual/technology/designing-for-d...
Câu trả lời nghiêm túc hơn nhưng cùng mạch đó là vì có hàng chục bản phân phối, và nếu tính cả các fork thuộc họ Mozilla trong đó thì trình duyệt cũng phải cỡ chục cái
Có thể chọn một bản phân phối/trình duyệt được công nhận, nhưng tập người dùng của riêng lựa chọn đó sẽ cực kỳ nhỏ
Ngay cả Ubuntu, theo các con số có thể suy ra từ chỉ số phụ trợ, cũng có vẻ chỉ chiếm khoảng 1% thị phần hệ điều hành desktop
Hỏi nghiêm túc thì, nhìn các bình luận có vẻ mọi người thích cách tiếp cận này
Vậy tại sao xu hướng chung lại đi theo hướng dùng các framework như React và JavaScript, đôi khi còn không cần thiết?
Nhẹ, bố cục gọn gàng, accessibility tốt, và nhìn chung chỉ dùng JavaScript ở mức tối thiểu hoặc thậm chí không có vẫn chạy được
Ngược lại, tôi không thích hầu hết các ứng dụng single-page. Chúng phá vỡ nhiều chức năng trình duyệt được kỳ vọng, vô dụng nếu không có JavaScript, và thường tải đủ thứ dependency nặng nề từ nhiều website bên thứ ba
Nhưng thứ người dùng thích và thứ lập trình viên thích cũng như có thể làm nhanh thường rất khác nhau
Khi một thứ được chấp nhận như tiêu chuẩn ngành, quyết định đi theo dòng chảy là an toàn
Thêm nữa, không ai làm developer relations cho HTML/CSS/JS thuần cả
Tìm kiếm cách làm gì đó thì gần như toàn ra nội dung liên quan đến framework
Nếu bạn viết một chương trình chạy trên máy tính của mình, bạn phải tự trả chi phí đó, và ít nhất phải giải thích với bộ phận tài chính vì sao chi phí cloud tăng 5%
Nhưng nếu bạn chạy phần mềm trên thiết bị của người khác, như lập trình viên frontend, thì gần như không có chi phí
Tín hiệu tiêu cực phải đi qua các kênh như báo cáo của người dùng, ticket hỗ trợ, có thể là bài đăng trên Twitter, và quá trình đó có nhiều thiên lệch chọn mẫu nên rất dễ không thấy được toàn cảnh
Rốt cuộc tất cả là vấn đề incentive
Web đang thay thế các thick client truyền thống, mà các client đó cũng từng giả định có kết nối mạng khá ổn định và thông số nền tảng nhất định
Hệ thống chính phủ, dù không phổ biến, vẫn phải chạy được trên mẫu số chung thấp nhất
Startup công nghệ ban đầu chỉ cần 1 khách hàng là có thể tồn tại, và khi mở rộng quy mô họ có thể tin rằng các yêu cầu của mình nhìn chung sẽ trở nên phổ biến
Thật ra tôi nghĩ chính vì là lập trình viên frontend nên họ ghét cách này. Nếu không thì gần như chẳng còn frontend nào để phát triển nữa
Cách tôi cố theo cũng là hướng này. Cung cấp HTML kèm dữ liệu đã được lấy sẵn từ server, xử lý những gì có thể làm ở client ngay trên client để giảm lượt đi-về server, tạo layout responsive bằng CSS tối thiểu và dùng JS thuần
Nếu cần thì tách thành các trang web riêng là được
Nhưng có vẻ với đồng nghiệp, chỉ vì dùng HTML, CSS và JS thuần mà nghe như thứ gì đó kỳ lạ và lỗi thời
Thực ra chẳng thiếu gì cả
Bài viết cũng nói rằng cứ mù quáng chỉ dùng phía server không phải là kỹ nghệ phần mềm tốt
Cần chú ý rằng họ nói “có thể gây vấn đề”, chứ không nói “gây vấn đề”
Các framework JavaScript phía client có thể hữu ích khi xây dựng dịch vụ có giao diện người dùng phức tạp, nhưng chúng làm tăng kích thước tổng thể của codebase và đẩy xử lý sang client, có thể tạo ra vấn đề hiệu năng cho người dùng có mạng chậm hoặc thiết bị yếu
Chúng cũng có thể khiến dịch vụ phụ thuộc vào mã bên thứ ba mà lập trình viên không kiểm soát, và có thể đòi hỏi những thay đổi lớn trong dịch vụ để theo kịp thay đổi của framework
Nếu framework mất độ phổ biến, cũng có thể khó tìm người bảo trì
Nếu dùng JavaScript framework, cần biện minh bằng bằng chứng xem nó đem lại lợi ích gì cho người dùng, hiểu và giảm thiểu tác động tiêu cực, đồng thời cân nhắc liệu lợi ích có lớn hơn các vấn đề tiềm tàng hay không
Ngoài ra chỉ nên dùng cho những phần giao diện người dùng không thể xây bằng HTML và CSS, và thiết kế từng phần thành component riêng
Khi tách component, nếu việc tải JavaScript thất bại thì chỉ component đó hỏng, còn phần còn lại của trang vẫn tải như bình thường