Cách xây dựng một trang web ưu tiên HTML và tăng gấp đôi số người dùng chỉ sau một đêm

 (mohkohn.co.uk)
1 điểm bởi GN⁺ 4 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Cách tiếp cận ưu tiên HTML giúp biểu mẫu đăng ký dịch vụ công hoạt động ngay cả khi không có JavaScript, để người dùng vẫn có thể hoàn tất đăng ký trên thiết bị, trình duyệt và mạng yếu
  • Ứng dụng React cũ bị gỡ xuống chỉ sau 3 ngày vì khiếu nại của khách hàng; các vấn đề gồm loading spinner, trạng thái JavaScript toàn cục, vấn đề truy cập và cách lưu ảnh vướng giới hạn 5MB của localStorage
  • Triển khai mới dựa trên Astro, biến mỗi bước của biểu mẫu thành một trang riêng và lưu dữ liệu gửi lên cùng tệp tải lên vào phiên backend theo từng bước để tránh mất dữ liệu nhập
  • Việc kiểm tra biểu mẫu được xử lý bằng web component bao bọc cơ chế kiểm tra HTML tích hợp sẵn của trình duyệt, và sử dụng cấu trúc nâng cao dần: nếu thất bại thì chuyển sang kiểm tra mặc định của trình duyệt rồi tới kiểm tra của API backend
  • Sau khi phát hành, số người hoàn tất biểu mẫu đã tăng gấp đôi; đồng thời cho thấy những người dùng rời bỏ do lỗi JavaScript không bị các gói phân tích dựa trên JavaScript ghi nhận

Bối cảnh vấn đề và lần thử trước thất bại

  • Khách hàng là một công ty tiện ích, và việc đăng ký dịch vụ có thể thực hiện qua biểu mẫu ASP cũ trên website hoặc qua quy trình thủ công
  • Quy trình thủ công tốn kém hơn cho công ty, và trong bối cảnh độc quyền có điều tiết, nếu mức hài lòng của khách hàng giảm dưới 96% thì có thể bị phạt tới hàng triệu bảng Anh
  • Đã có hai lần thử trước đó để giải quyết vấn đề nhưng đều thất bại; ở lần gần nhất, các nhà thầu từ quốc gia khác đã xây dựng một ứng dụng React
  • Ứng dụng React bị gỡ khỏi public chỉ 3 ngày sau khi ra mắt trực tuyến vì khiếu nại của khách hàng
  • Ứng dụng đó trộn lẫn loading spinner với trạng thái JavaScript toàn cục và không đáp ứng khả năng truy cập
  • Tải ảnh lên là chức năng cốt lõi của biểu mẫu, nhưng họ lại cố lưu ảnh và toàn bộ dữ liệu biểu mẫu trong localStorage vốn có giới hạn 5MB

Tiêu chí chọn hướng ưu tiên HTML

  • Trang web mới được xây dựng bằng Astro và áp dụng kiến trúc ưu tiên HTML
  • JavaScript chỉ được dùng bên trong web component, đóng vai trò cải thiện dần một website vẫn hoạt động bình thường ngay cả khi không có JavaScript
  • Dịch vụ công phải hoạt động trên mọi thiết bị có thể
  • Nó cũng phải hoạt động ngay cả khi kết nối kém
  • Dữ liệu biểu mẫu đã nhập một lần tuyệt đối không được biến mất
  • Trường hợp của Terence Eden cho thấy các trang HTML đơn giản của GOV.UK vẫn cho phép đọc thông tin về trợ cấp nhà ở ngay cả trên trình duyệt PlayStation Portable chậm và thường xuyên thiếu bộ nhớ
  • Các trang GOV.UK được viết bằng HTML đơn giản, thiết kế nhẹ và phải hoạt động được cả trên những trình duyệt tệ nhất

Cấu trúc biểu mẫu và cách bảo toàn dữ liệu

  • Mỗi phiên của biểu mẫu phải có một ID duy nhất
  • Ở mọi bước của form wizard, dữ liệu gửi lên và tệp tải lên đều phải được lưu ở backend
  • Người dùng phải có thể hoàn tất biểu mẫu ngay cả khi không có JavaScript
  • Người dùng cũng phải có thể hoàn tất biểu mẫu trên những trình duyệt web cũ và hiệu năng thấp
  • Khả năng truy cập phải đáp ứng tiêu chuẩn WCAG, và nhóm đặt mục tiêu AA thay vì AAA
  • JavaScript và CSS hiện đại nên được dùng để cải thiện trải nghiệm
  • Trong cấu trúc cuối cùng, mỗi bước của form wizard trở thành một trang riêng, và khi người dùng bấm Next thì biểu mẫu được gửi đi
  • Nếu API xác định dữ liệu hợp lệ, trình duyệt sẽ được chuyển hướng tới bước tiếp theo
  • Gửi biểu mẫu rồi chuyển hướng là một mẫu ứng dụng web cũ, và đã có một sự hồi sinh hiện đại nhỏ nhờ Remix
  • Dịch vụ này không phải một ứng dụng hiển thị dữ liệu thời gian thực mà là một biểu mẫu lớn, nên cách gửi 20MB JavaScript trước khi render là không phù hợp

Kiểm tra biểu mẫu và nâng cao dần

  • Kiểm tra biểu mẫu và render lỗi biểu mẫu thường bị các nhóm xử lý như một lĩnh vực phải tiêu tốn nhiều nhân-tháng vì các thư viện kiểm tra của React
  • Trình duyệt vốn đã có sẵn hệ thống kiểm tra, và có thể tận dụng nó với ít công sức hơn so với các bản bắt chước chất lượng thấp cần quản lý thư viện riêng
  • HTML web component được triển khai là một custom element đơn giản bao bọc HTML hiện có
  • Web component này không dùng shadow DOM và hầu như không render HTML bên trong JavaScript
  • Component bao bọc biểu mẫu HTML và lấy cơ chế kiểm tra HTML để hiển thị theo cách hiện đại hơn
  • Nó chặn tooltip popup kiểm tra HTML và đặt lỗi vào phần tử aria-describedby liên kết với trường
  • Hiện nay, việc dùng aria-errormessage được khuyến nghị
  • Khi đầu vào trở nên hợp lệ trong lúc nhập, lỗi kiểm tra sẽ được xóa, sau đó đánh giá lại tại thời điểm blur và gửi biểu mẫu
  • Trải nghiệm người dùng này được cung cấp với dung lượng dưới 1KB, và nếu thất bại thì quay về kiểm tra mặc định của trình duyệt
  • Nếu cả kiểm tra mặc định của trình duyệt cũng thất bại, API backend sẽ xử lý việc kiểm tra
  • Các vấn đề kiểm tra được thông báo ở thời điểm sớm nhất mà trình duyệt của người dùng cho phép, và dù thất bại vẫn luôn có trải nghiệm fallback chấp nhận được
  • Sau đó, một phiên bản mới của web component đã được viết lại từ đầu để dùng phổ biến hơn, có tên là validation-enhancer
  • Ví dụ sử dụng cho thấy validation-enhancer bao bọc biểu mẫu HTML, đồng thời tận dụng nguyên trạng input type="email", required và aria-errormessage

Email

Submit

Kết quả sau phát hành và kết luận

  • Sau khi phát hành, số người hoàn tất biểu mẫu đã tăng gấp đôi
  • Nhóm phân tích không biết những người dùng này đến từ đâu
  • Các gói phân tích dựa trên JavaScript không nhìn thấy những người dùng rời bỏ vì lỗi JavaScript
  • Cách tiếp cận duy trì phiên backend và tuyệt đối không để mất dữ liệu người dùng đã phát huy hiệu quả
  • Có một trường hợp người dùng hoàn tất biểu mẫu sau khi bắt đầu được một tháng
  • Sau khi công việc hợp đồng kết thúc, người kế nhiệm phản ứng rằng cấu trúc luôn hoạt động cả khi không có JavaScript khiến nhóm có thêm việc phải làm
  • Việc loại trừ người dùng trình duyệt cũ, người dùng có kết nối mạng kém và người dùng công nghệ hỗ trợ là điều không thể chấp nhận trong một dịch vụ công độc quyền
  • Cần từ bỏ xu hướng tiếp tục thúc đẩy những cách làm thô ráp và non nớt xuất hiện trong giai đoạn mở rộng của ngành phần mềm
  • Nếu bạn xây dựng được một ứng dụng web hoạt động cả trên PlayStation Portable và kết nối 3G, nó sẽ hoạt động cho mọi người dùng và có thể vẫn hoạt động sau 30 năm

Bài viết liên quan

2 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Hacker News

  • Là một lập trình viên không làm web, tôi khá tò mò, vì sao cách này lại làm tăng khối lượng công việc
    Cách tiếp cận được mô tả trong bài có vẻ khá đơn giản: tạo các component chuẩn cho form và đặt nút gửi ở bên dưới là được. Từ lâu trước đây khi tự làm website cá nhân tôi cũng đã làm như vậy, và nó không hề khó lắm. Có thể là vì tôi không hiểu rõ lĩnh vực này, nhưng làm frontend hào nhoáng có vẻ còn khó hơn nhiều

    • Vài năm gần đây tôi nhận ra rằng một số kỹ sư junior và mid-level chưa từng nghiêm túc nghĩ đến khả năng có thể làm website mà không cần framework ứng dụng một trang nặng nề
      Không phải vì họ ngốc. Nếu hỏi trực tiếp “Có thể làm website mà không cần React không?” thì dĩ nhiên họ sẽ trả lời “có”. Nhưng khi được giao làm một website mới, vì quen tay và chỉ muốn xong việc, họ sẽ mở một project React mới gần như theo phản xạ
      Một số người thực sự không biết cách nào khác. Họ không biết cách dựng một HTTP server bình thường trả về HTML thuần, cũng không có kinh nghiệm làm form xác thực và gửi mà không cần JavaScript. Những người này không phải kiểu người lên HN viết bài, cũng không tham gia tranh luận online về công cụ hay kỹ thuật mới, hoặc cả công cụ kỹ thuật cũ. Họ chỉ học vừa đủ để đi làm qua một khóa bootcamp hoặc một môn webapp ở đại học, rồi sau đó mỗi lúc chỉ học đúng công cụ mà nhà tuyển dụng yêu cầu hoặc người nào đó trong team đã chọn
      Ở góc nhìn của người lớn tuổi hơn, tôi mất khá lâu mới nhận ra điều này, nhưng giờ thì hiểu rồi. Tùy theo lộ trình nghề nghiệp, có người lại tiếp xúc với những phần đơn giản nhất của HTML, CSS và JavaScript thuần còn muộn hơn cả những phần phức tạp, mang tính framework chuyên biệt của từng công nghệ. Vì thế với họ, những thứ đó không hề kém chuyên nghiệp hơn, mà ngược lại còn có cảm giác khó hiểu hơn, cao cấp hơn, hoặc là kiến thức phụ
      Câu “như vậy công việc của bọn tôi sẽ tăng lên rất nhiều” cũng chưa chắc là nhận định sai do cố tình. Khi phải làm việc bằng công cụ không quen thuộc, dù công cụ đó ít phức tạp hơn, cảm giác khối lượng việc tăng lên rất nhiều là điều hoàn toàn có thể xảy ra
    • Hai năm trước, khi bắt đầu công ty mới, ngay từ đầu chúng tôi đã quyết định không dùng framework SPA JavaScript nặng nề. Chúng tôi giữ mọi thứ ở dạng HTML render phía server đơn giản, và chỉ dùng JavaScript theo hướng tăng cường dần dần
      Ứng dụng nhanh và đơn giản, nhưng cũng phải trả giá. Khả năng lấy ngay các phần tử UI phong phú từ các gói npm bị hạn chế, và để đem lại trải nghiệm người dùng tốt thì cần nhiều công sức hơn rất nhiều. Mọi thứ đều mất nhiều thời gian hơn, và kết quả là trải nghiệm người dùng cũng tệ hơn. Chúng tôi có quan tâm, nhưng đôi khi đơn giản là không có thời gian để chăm chút đến cùng
      Công ty đã thất bại, và tôi không nghĩ React có thể cứu nó. Nhưng tôi có thể nói từ trải nghiệm trực tiếp rằng sự ám ảnh mang tính đạo đức với “sự đơn giản” cũng không giúp ích gì. Lúc nào cũng là đánh đổi
    • Từ góc độ của người đọc rất nhiều code do người khác viết, tôi tin chắc rằng với nhiều người, học một cách làm mới bị xem như điều khó nhất trên đời
    • Tôi nghĩ vấn đề là chúng ta mới chỉ nghe một phía
      Có người nói rằng mình đã đưa ra một giải pháp đơn giản và hợp lý hơn những gì đa số sẽ nghĩ tới, còn người tiếp nhận bàn giao thì lại không hài lòng
      Liệu chúng ta có biết chất lượng của đoạn code được bàn giao có thực sự cao không? Người đó phản ứng chỉ vì nó “không phải React” chăng? Có thể trong công ty có sẵn một template bắt buộc cho cách xây ứng dụng không?
      Không ai biết được
    • Khả năng lớn là liên quan đến công nghệ mà mọi người đã quen. Đã có vài thế hệ lập trình viên web chỉ biết hệ sinh thái JavaScript khi làm webapp, nên bất cứ giải pháp nào không phải kiểu JavaScript thuần đó đều có thể trông xa lạ

  • Dù dạo gần đây không còn nghe nhắc đến nhiều, HTML Triptych vẫn là một trong những đề xuất mà tôi hy vọng rồi sẽ vào trình duyệt. Cách HTML form giao tiếp với REST endpoint là một pattern tốt
    Xác thực hỗ trợ người dùng được xử lý bằng các thuộc tính của input, xác thực thực sự được xử lý ở phía bên kia của request, và luồng sẽ có dạng GET /form => POST /thing => GET /thing/1. Nếu tính năng triptych được triển khai, đây sẽ là một pattern rất tuyệt
    [0] https://triptychproject.org/

  • Tôi hoàn toàn không thích các site React, nhưng điều tôi không hiểu là chẳng lẽ các site kiểu này không hề lazy-load chút nào sao
    Ngay cả một SPA lớn cũng có thể rất nhanh nếu chỉ tải component khi cần
    Tôi đã đi từ Angular1 -> Vue2 -> Svelte2 rồi chốt lại ở web component thuần không dùng shadow DOM, và thấy vừa thích làm việc với nó vừa nhanh

  • Dạo này hầu hết các ứng dụng tôi đều chỉ làm bằng HTMX + Go + SQLite
    Tôi thấy vậy là đủ cho đa số dự án
    Một trong các site của tôi có rất nhiều ảnh và xử lý 10TB lưu lượng mỗi tháng. Với trường hợp đó, cấu hình như sau: 1. Dùng S3 vì cần một kho lưu trữ dữ liệu đáng tin cậy 2. Đặt Cloudflare ở phía trước và bật Tiered Cache. Như vậy các POP sẽ ưu tiên lấy từ Cloudflare thay vì từ origin. Tôi cache mọi thứ trong 1 năm ở cả trình duyệt lẫn Cloudflare, đồng thời thiết lập quy tắc bỏ qua chính sách cache của origin và chuỗi truy vấn, và chỉ dùng các đối tượng bất biến cần revision 3. Đặt BunnyCDN ở phía trước nó
    Chỉ riêng Cloudflare thì không cho phép vận hành site nhiều ảnh như vậy, nên tôi dùng cách này để cắt giảm chi phí rất nhiều. Theo chính sách thì chủ yếu không được dùng cho ảnh mà phải dùng cho HTML, CSS, JavaScript và các nội dung khác của site
    Nếu chỉ dùng S3 thì chi phí sẽ cực kỳ lớn
    Tuy vậy gần đây tôi đang làm ứng dụng di động. PWA có giới hạn. Hệ điều hành có thể thu hồi vùng lưu trữ IndexedDB, nên không thể cung cấp kho dữ liệu đáng tin cậy trong app mà không cần đăng ký tài khoản hay backend can thiệp
    Cuối cùng tôi buộc phải chuyển sang Flutter trên Android, nhưng lại gặp một nỗi khổ khác. Có lúc cập nhật app bị treo ở trạng thái “đang xét duyệt” rất lâu nên khá bực. Trong khi đó web app của cùng ứng dụng này thì cập nhật rất nhanh nếu so sánh
    Tôi tự hỏi vì sao không có hệ điều hành di động nào cho phép làm app bằng JavaScript, HTML, CSS và còn cung cấp luôn lưu trữ ổn định mà không cần quá nhiều công sức. Điểm hay của PWA là có thể cập nhật rất nhanh

    • Đã từng có một hệ điều hành di động như vậy. Chỉ cần du hành thời gian về lúc Palm ra mắt webOS vào năm 2009
      Du hành thời gian là phần dễ, sau đó còn phải tìm cách ngăn sự sụp đổ của Palm và việc webOS bị lãng quên như một hệ điều hành smartphone
      Nếu 2009 là quá xa thì cũng có thể thử đặt cược vào Firefox OS năm 2012
      Nói vui vậy thôi, thực ra đã có người và công ty từng thử rồi. Nhưng do thời điểm không thuận lợi và nhiều sự kiện chồng chéo nên trong dòng thời gian của chúng ta, thực tại đó đã không xảy ra
    • Go thực sự rất tốt cho ứng dụng server. Lẽ ra tôi nên biết điều đó sớm hơn nhiều
      Nó có cảm giác đúng ngay điểm tối ưu: không có gánh nặng vô nghĩa như C, nhưng cũng tránh sang một bên để bạn tập trung vào business logic như Java. Không giống Rust
      Nó không phù hợp cho mọi việc. Đặc biệt là khả năng tạo abstraction còn hạn chế thì hơi đáng tiếc. Nhưng với ứng dụng server nhiều business logic thì nó rất tuyệt. Cảm giác đây không phải ngôn ngữ cố làm tất cả, mà là ngôn ngữ chuyên cho mảng đó
    • 10TB lưu lượng mỗi tháng thì ngoài CDN, mạng quảng cáo, nội dung khiêu dâm, hoặc các site thương mại điện tử lớn, tôi khó mà hình dung được. Không biết bạn làm gì mà ra tới 10TB lưu lượng mỗi tháng
    • Cứ như gặp đúng người giống mình vậy. Dạo này tôi cũng đang mê làm đủ thứ với HTMX + Go + SQLite. Với tôi đây giống như bộ ba công nghệ nhàm chán nhưng hợp gu. Tôi triển khai lên máy chủ colocated bằng các script bash bình thường
      Tôi cũng tự làm vài thư viện để trừu tượng hóa phần SQL và HTMX/web/OAuth. Giờ các ứng dụng của tôi rất giống nhau nên việc chuyển tính năng qua lại khá dễ
      https://github.com/cattlecloud/webtools
      https://github.com/cattlecloud/litesql
    • Bây giờ 10TB chẳng đáng là bao. Các VPS ở châu Âu của Hetzner đều kèm 20TB lưu lượng mỗi tháng, và phần vượt mức cũng dưới 2 USD mỗi TB. Máy chủ dedicated thì fair use không giới hạn; nếu lấy trung bình qua nhiều tháng thì chắc khoảng 200TB mỗi tháng

  • Một phản biện là In Defence of the Single Page Application
    https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...

    • Buồn cười là tôi mở nó trên kết nối Internet di động thì nó kẹt luôn ở vòng quay tải. Không biết là do mạng của tôi, dù chắc không phải, hay do vấn đề hỗ trợ di động, nên tôi còn chẳng đọc được nội dung
    • Một trò nhại đủ phát triển thì không thể phân biệt với thực tế
    • Hồi đó chuyện này cũng đã được bàn rồi
      In Defence of the Single Page Application - https://news.ycombinator.com/item?id=31275178 - tháng 5/2022, 32 bình luận
    • Thứ tôi thấy chỉ là animation “loading”. Sau 10 giây thì tôi bỏ cuộc. Vậy nên đây không phải phản biện mà là ví dụ xác nhận luôn luận điểm của bài viết

  • Bài này hay, và là một ví dụ rất tốt về việc mang vấn đề ra rồi giải quyết bằng công nghệ phù hợp ở đúng mức độ cần thiết. Việc nắm trọn kiến thức miền của khách hàng thực sự rất có ích
    Tuy vậy tôi không thích cách đóng khung kiểu “HTML đơn giản tốt hơn React”. Vì với tư cách là một lập trình viên React, tôi cũng có thể kể chính xác cùng một câu chuyện như vậy
    Có thể nói mãi về rất nhiều thứ mà bài này lướt qua đại khái, như độ phức tạp và các sắc thái giữa lưu session phía server và lưu trữ phía trình duyệt, nhưng sẽ quá dài
    Những thứ đơn giản trong HTML thì trong React cũng đơn giản
    Nghĩa đen là cùng một đoạn mã. Không có gì trong React ngăn bạn dùng kiểm tra hợp lệ HTML gốc của trình duyệt. Những phần mã trở nên phức tạp trong React, ví dụ logic validation bị làm quá mức, thì trong Astro cũng sẽ phức tạp. Astro cũng có cách riêng cho schema validation v.v., và để tích hợp vào site Astro thì bạn cũng phải tích hợp client router các kiểu, nên ở đó cũng rất dễ thành quá phức tạp
    Đối tượng so sánh ở đây có lẽ cũng là một đội outsource nước ngoài với hiểu biết chưa đầy đủ, và cấu trúc dự án tạo động lực để họ làm ra giải pháp nhanh nhất có thể, trong ít thời gian nhất có thể, với độ phức tạp lớn nhất có thể
    Điểm cuối này khá tinh vi. Không phải là công ty outsource cố tình làm vậy, nhưng cấu trúc khuyến khích thực tế khiến sự phức tạp quá mức lại có lợi cho họ, nên họ không có động lực trực tiếp để chọn cách đơn giản
    Dù sao thì một giải pháp đơn giản xử lý trực tiếp vấn đề trước mắt vẫn luôn tốt hơn, và điều đó đúng với bất kỳ stack nào
    Không phải tôi ác cảm với form validation của Astro, tôi chỉ muốn nhấn mạnh rằng còn nhiều thứ hơn là “kiểm tra hợp lệ HTML gốc của trình duyệt”

    • Có vẻ như cả LLM cũng chấp nhận điểm cuối đó

  • Bài viết rất hay, nhưng mỗi lần đọc những bài truyền cảm hứng kiểu này tôi lại thấy giằng co. Ý tưởng về một trang web đơn giản — hoàn toàn đúng đắn, hoạt động tốt, tải nhanh và không phụ thuộc vào trình duyệt hiện đại — rất hợp ý tôi
    Rồi tôi lại tự hỏi liệu có phải vì mình không đủ thông minh để hiểu React hay những công nghệ hào nhoáng đang thịnh hành lúc đó hay không
    Cảm giác như có một giới hạn nhận thức không thể vượt qua. Nếu đưa cho tôi một trình soạn thảo đơn giản như Sublime và bảo làm một trang web, thì đó là không gian khiến tôi thấy vui vẻ, kể cả có JavaScript. Nhưng nếu đưa VSCode hay Zed, các plugin Claude/Copilot/ChatGPT gắn khắp nơi, rồi cả tutorial React, thì đầu óc tôi như nhũn ra

    • Nếu thấy được an ủi thì, ngay cả những người dùng mấy framework hào nhoáng đó phần lớn cũng không hẳn đủ thông minh để hiểu chúng đâu
    • Bạn cũng có thể thích bài này về sự phức tạp và vì sao nó là điều tệ: https://tengstrand.github.io/blog/2019-09-14-the-origin-of-c...
      Giữ mọi thứ đơn giản không phải là điều xấu; ngược lại, nhiều khi phải đủ thông minh để không làm nó phức tạp quá mức
    • Tôi thích web. Tôi ghét những gì các tín đồ cuồng React đã làm với web
      Embrace Extend Extinguish là có thật, và những kẻ hùa theo nó cũng xứng đáng bị thay thế bởi các LLM nói dối nhanh hơn và phun ra code rác nhiều hơn

  • Làm tôi nhớ lại gần 15 năm trước. Tôi dùng quản lý session phía backend của Grails, cùng form HTML được cải thiện bằng CSS responsive và “một ít” JS
    Khác với bây giờ là công nghệ trình duyệt khi đó chưa phát triển đến mức này. Phải để ý nhiều trình duyệt, lại còn phải xử lý cả IE7, thậm chí IE6, nên rất khó và cần QA diện rộng. BrowserStack mãi sau mới xuất hiện
    Có lý do để các thư viện JavaScript phát triển như vậy. Khi đó chưa có npm, thậm chí bower cũng chưa có. Rồi Backbone.js xuất hiện và tôi rất thích nó. AngularJS thì thật ấn tượng, rồi các phiên bản Angular sau đó có đợt phá vỡ tương thích lớn, sau nữa là React, Polymer, v.v.
    Trình duyệt native ngày nay làm được rất nhiều thứ và việc nâng cấp tính năng cũng dễ hơn nhiều. Nhưng không phải lúc nào cũng thế. Quyết định dùng React thời đó là hợp lý vì nhiều lý do, và ở đây cũng có thể vậy

  • Hơn 10 năm trước tôi từng xây các ứng dụng kiểu này ở GOV.UK cho Bộ Tư pháp. Chúng tôi tự làm một thư viện trình hướng dẫn biểu mẫu để có thể xác thực form dài theo từng bước và chia nó thành nhiều trang, vì Ruby on Rails không hỗ trợ sẵn việc đó
    Khi ấy, nguyên tắc mọi người đều phải có thể sử dụng dịch vụ số bất kể họ truy cập bằng môi trường nào là điều cực kỳ quan trọng

    • Tôi luôn thích các trang HTML cơ bản cho phép tải tài liệu lên mà không cần khởi động lại toàn bộ ứng dụng. Đây cũng là thực hành rất tốt với các form thông thường
      Với mỗi session ID, bạn có thể đối chiếu trang của ứng dụng nhiều trang với session ID đó, nên nếu cần thì người dùng thậm chí có thể tự nhập nó. Nhưng chỉ cần có đủ thông tin như địa chỉ IP, ngày tải lên, trình duyệt, hệ điều hành thì đáng ra cũng phải phân biệt được. Dù vậy, session chính xác nhất vẫn nên nằm trong trình duyệt, để cookie của một đơn đăng ký không bị trộn với người nộp khác, như ông chú bà con nào đó dùng PlayStation Portable chẳng hạn
    • Trang web gov.uk thực sự rất ấn tượng. Tối giản và đúng mục đích
      Tôi tò mò họ dùng công nghệ gì cho ứng dụng di động. Tôi đoán nó không phải app di động hoàn chỉnh mà có lẽ dùng webview

  • Đây không phải là kiểu “đổi ứng dụng React sang form HTML thì hiệu năng tốt hơn”. Mà là “đổi một trang web tệ thành một trang web tốt thì hiệu năng tốt hơn”
    Đổ điều này cho công nghệ vận hành trải nghiệm trình duyệt là ngớ ngẩn. Với React vẫn có thể làm ra trải nghiệm người dùng tuyệt vời, và với HTML thuần cũng có thể tạo ra website kinh khủng
    Cải thiện đến từ thay đổi thiết kế, không phải từ công nghệ

    • Có thể nói ràng buộc của cách làm HTML-first đã giúp tránh những pattern tệ từng dùng trước đó
      Nhưng đúng là vậy. Thay đổi phía người dùng đến từ việc sửa thiết kế chứ không phải từ công nghệ dùng bên dưới
      Nó rất giống những bullet point tệ trong CV. Kiểu ai đó viết “viết lại website theo hướng HTML-first, tăng 100% lượng khách truy cập” như thể kết quả kinh doanh đến từ thay đổi code. Nhưng hỏi kỹ mục đó thì rốt cuộc họ sẽ thừa nhận là đã thiết kế lại toàn bộ site để sửa vấn đề thiết kế hoặc thêm tính năng, và chính điều đó mới kéo lượng truy cập tăng lên
    • HTML bình thường đi kèm chút JavaScript thuần không hẳn là hố sâu của thành công, nhưng React thì gần với hố sâu tuyệt vọng hơn nhiều. Cái trước có xu hướng thô ráp nhưng hiệu quả; cái sau muốn khai thác được tiềm năng thì phải có bằng tiến sĩ né tránh độ phức tạp
      JavaScript: The Good Parts của Douglas Crockford mỏng đến mức buồn cười. React: The Good Parts chắc còn mỏng hơn nữa
    • Tất nhiên rồi. Chỉ là với React thì khó hơn gấp 100 lần, và nếu thất bại thì fan của nó sẽ đổ lỗi cho bạn chứ không đổ cho công nghệ
    • Câu trả lời chuẩn là có những công nghệ khiến một bên khó hơn bên kia. Về nguyên tắc điều đó phần nào đúng, nhưng chẳng hạn cần có lập luận rằng React thực sự khiến việc tạo ra kết quả tốt khó hơn so với một trang HTML bình thường
      Điều thú vị là bài gốc mô tả kiểu form wizard nhiều trang mà khoảng 10 năm nay tôi hầu như không còn thấy. Nhưng mỗi lần tôi gặp kiểu đó thì đa phần lại là những hệ thống enterprise khủng khiếp. Lần gần nhất tôi thấy là một sản phẩm Oracle gì đó để xử lý chi phí
      Vấn đề của những thứ đó luôn là thao tác giữa chừng rất chậm. Mỗi nút bấm phải chờ vài giây. Nếu phải quay lại một hai bước thì bực gấp đôi. Các ứng dụng một trang làm kém thì thường chậm lúc khởi động. Tải lên mất thời gian, nhưng một khi đã tải xong thì hiệu năng thường cũng ổn
 
GN⁺ 4 giờ trước
Ý kiến trên Lobste.rs

  • Việc làm ra thứ hoạt động đúng đắn cho con người dùng thì đương nhiên tốn công hơn. Nhưng rốt cuộc đó cũng chính là cốt lõi của toàn bộ công việc

    • Cảm giác hơi kỳ. Nếu tính cả công sức để tiếp tục vận hành, ví dụ chi phí phải chạy theo vòng xoay phiên bản của hệ sinh thái JavaScript, thì một ứng dụng React gần như chắc chắn nhiều việc hơn HTML đơn giản
      Có vẻ điều những người đi sau thật sự muốn nói gần hơn với việc họ không nắm vững các nền tảng cơ bản của web
    • Trong xã hội tư bản, mục đích của công việc thường là kiếm tiền. Kiếm tiền và làm ra phần mềm vẫn chạy được trong môi trường client cũ hoặc hiếm gặp thường đi theo hai hướng trái ngược nhau
      Không phải nói điều đó là đáng mong muốn, mà là thực tế hiện nay đang như vậy

  • Đoạn nói rằng đã mất thời gian để giải thích “gửi form và chuyển hướng” cho đồng nghiệp nghe thật chua chát. Đó là vì ai cũng đã quen với ứng dụng web lấy client làm trung tâm
    Tình trạng phát triển web hiện nay thật sự đáng buồn, và có quá nhiều thứ phải dạy lại

  • Tôi không nghĩ cần tới mức tương thích cao như vậy mới biện minh được cho cách tiếp cận này. Như bài viết cũng nói, suy cho cùng nó chỉ là một form
    Nên nếu là tôi thì trong trường hợp nào tôi cũng sẽ làm như vậy

  • Tôi muốn thử làm công việc xây dựng website kiểu như bài viết mô tả. Ràng buộc phải là bản tải xuống cực nhỏ, chạy được trên gần như mọi trình duyệt và vẫn đảm bảo accessibility nghe như một thử thách khá thú vị
    Không biết có công ty nào chuyên về hướng này không, và họ có tuyển người không. Có lẽ tôi chỉ là một người già nhớ thời mọi thứ còn đơn giản hơn trước

    • Không hẳn là nghề nghiệp, nhưng bạn đã ở trong đó rồi. Sáng nay tôi đã gửi một yêu cầu tính năng để làm tốt hơn phần này
      Chức năng này được tách biệt đủ tốt để rất dễ trích ra thành thư viện tái sử dụng, và vẫn còn nhiều việc để làm. Tôi muốn biến kiểu này thành mặc định của framework web. Bài viết thực sự rất hay

  • Hơi mỉa mai là trên Firefox, do một kiểu style nào đó mà phần nội dung chính thậm chí không hiện ra đầy đủ cũng không chọn được, nên tôi phải chuyển sang chế độ đọc. Tôi thấy tiêu đề, dấu trích dẫn màu hồng và các code block, còn lại thì không thấy gì cả
    Sửa: nhìn các bình luận bên dưới thì có lẽ là vấn đề môi trường của tôi. Để lại cho đủ ngữ cảnh
    Dù sao tôi vẫn đọc được bài. Dù là developer hay người dùng cuối, tất cả chúng ta đều đang trả giá cho “tính linh hoạt” của React. Tôi đã nhiều lần ước rằng ở công ty có thể dùng một stack khác
    Ngoài ra, khả năng đồng cảm của tác giả và cách họ thiết kế nó thành một cấu trúc “ai cũng thắng” thật sự gây ấn tượng. Sự quan tâm rồi sẽ được đền đáp

    • Tôi cũng vậy. Đang dùng Firefox 152.0b9 trên Debian Trixie
    • Kỳ lạ là trên Firefox của tôi thì trang vẫn hoạt động bình thường

  • Rất đồng cảm. Trước đây tôi từng làm một blog dùng JavaScript cực nhiều, và các tính năng dựa trên JS suýt nữa đã gây ra phản ứng dữ dội
    Tôi vẫn chưa có thời gian chuyển hẳn sang cách HTML-first, nhưng bề ngoài thì đã để nó trông gần như một trang web HTML-first
    Trong dữ liệu phân tích của tôi cũng thấy kết quả tương tự. Tỷ lệ thoát giảm từ 80% xuống khoảng 50%, và khách truy cập mới cho các bài viết sau đó gần như tăng gấp đôi
    Nghĩ đến việc có bao nhiêu người có lẽ đã tránh luôn domain của tôi mãi mãi vì cái triển khai tệ hại làm bằng JS lúc đầu thì thật rùng mình. Nếu là webpage hay blog thì đây là một trong những lời khuyên quan trọng nhất

  • Cách làm này cũng giúp cho tự động điền form. Trước đây từng có trường hợp cả form đều động và không có thuộc tính nào để nhận diện từng phần, nên không thể làm tự động nhập liệu được
    Thật tiếc vì nó được thiết kế quá tay để trông đẹp hơn là để có chức năng, nên tôi rất thích đọc bài này về thiết kế ưu tiên người dùng

  • Nếu thêm SSE streaming và thư viện morph vào đây thì cũng có thể làm các tính năng động, realtime và multiplayer khá đẹp