Phát triển quá mức lấy JavaScript làm trung tâm đang phá hỏng web
(jonoalderson.com)Tóm tắt tổng quan
Phát triển quá mức lấy JavaScript làm trung tâm đang phá hỏng web
- Việc lạm dụng các framework JS làm độ phức tạp của website ngày càng trầm trọng
- Trải nghiệm lập trình viên (DX) lấn át trải nghiệm người dùng (UX)
- Ngay cả tác vụ đơn giản cũng đòi hỏi cấu trúc quá mức
- Hiệu năng, khả năng truy cập và khả năng bảo trì đều suy giảm
- Khôi phục chức năng vốn có của web là lời giải
Mở đầu
Căn bệnh của web lấy phát triển làm trung tâm
- Phần lớn website quá phức tạp và chậm chạp
- Thiết kế lấy JS làm trung tâm đã chuyển cấu trúc sang ưu tiên lập trình viên hơn người dùng
- Việc ngay cả thay đổi nhỏ cũng đòi hỏi quy trình triển khai phức tạp đã trở thành chuyện phổ biến
Nội dung
Nguyên nhân là khát vọng muốn trông giống ứng dụng
- Từ sau thập niên 2010, cùng với làn sóng ứng dụng di động, nhu cầu về “web như ứng dụng” gia tăng
- Khi các framework JS như Angular được đưa vào, độ phức tạp tăng vọt
- Ngay cả nội dung đơn giản cũng được phát triển như một hệ thống
Văn hóa ưu tiên trải nghiệm lập trình viên (DX)
- Các framework mới nhất tập trung vào sự tiện lợi cho lập trình viên
- Trừu tượng hóa thành phần tạo ra khoảng cách với UX
- Thay vì hỏi “vì sao blog lại dùng React”, người ta lại ưu tiên bàn về tính tương thích SSR
Thực tế nơi độ phức tạp đã trở thành tiêu chuẩn
- Ngay cả tác vụ đơn giản cũng cần cấu trúc nhiều tầng như build, routing, API, cache
- Vì stack phức tạp, người không phải lập trình viên không thể chỉnh sửa nội dung
- Công nghệ thay đổi quá nhanh khiến việc bảo trì trở nên khó khăn
Tác hại của việc lạm dụng framework
- Đang tái hiện thực các chức năng web vốn có như SSR, cache, metadata
- Hiệu năng thấp hơn, còn phụ thuộc thì nhiều hơn
- Kết cục là nảy sinh nghịch lý tái tạo CMS bằng framework JS
Sự lặp lại vô nghĩa và chi phí
- Việc đưa vào rồi loại bỏ framework lặp đi lặp lại, không có cấu trúc ổn định
- Thay vì giải quyết vấn đề của người dùng thực tế, người ta tập trung vào xử lý độ phức tạp nội bộ
- Content marketing, SEO và thử nghiệm bị chậm lại, còn trải nghiệm người dùng thì tệ đi
Thiệt hại với người dùng và marketer do lạm dụng JS
- Việc chỉnh sửa nội dung cần có lập trình viên can thiệp
- SEO và chất lượng trang suy giảm
- Với người dùng, sự bất tiện như tải chậm và lỗi tương tác ngày càng tăng
JS chỉ là công cụ, không phải mục đích
- JS là công cụ mạnh mẽ, nhưng với đa số website thì đang bị dùng quá mức
- Với nội dung tĩnh, chỉ cần HTML, CSS và một ít JS là đủ
- Vanilla JS, server-side rendering và lượng script tối thiểu hiệu quả hơn
Sự tập trung quyền lực và vấn đề cấu trúc
- Vì stack phức tạp nên mọi công việc đều phụ thuộc vào lập trình viên
- Trong cấu trúc tổ chức, quyền lực tập trung theo hướng lấy lập trình viên làm trung tâm
- Các quyết định kỹ thuật được đưa ra dựa trên sự tiện lợi cho lập trình viên hơn là cho người dùng
Kết luận
Khôi phục bản chất của web là lời giải
- Cần những website tải nhanh, có thể tìm kiếm được và dễ bảo trì
- HTML render phía máy chủ, semantic markup và JS tối thiểu là câu trả lời để quay về nền tảng cơ bản
- Cần cách tiếp cận lấy kết quả làm trung tâm thay vì lấy công nghệ làm trung tâm
- Cần đặt câu hỏi: “Vì sao lại dùng công nghệ này?”
- Web đơn giản và lấy người dùng làm trung tâm sẽ mang lại hiệu năng, tiết kiệm chi phí và tính linh hoạt
23 bình luận
Chỉ cần nhìn vào WordPress thôi... có lẽ đã là câu trả lời cho vấn đề trên rồi. Thị phần của WordPress cũng lớn hơn rất nhiều, dù chậm thì vẫn vậy...
Tôi nghĩ nếu có kết quả benchmark làm căn cứ thì các lập trình viên sẽ dễ đồng cảm hơn. Nếu lạm dụng việc viết code dựa quá nhiều vào framework thì chắc chắn trang web sẽ chậm đi, nhưng cá nhân tôi lại thấy khá nhiều trang dùng mã thuần còn chậm hơn các trang dùng framework đã được tối ưu, đặc biệt ở khía cạnh chuyển trang bên trong site. Tất nhiên, nếu là một trang chỉ có dữ liệu tĩnh thì có thể chỉ với HTML + CSS sẽ nhanh hơn, nhưng tôi không chắc ngày nay những trang chỉ gồm dữ liệu tĩnh còn phổ biến đến mức nào.
Nếu không có những thứ như React hay Vue thì ngay cả khi triển khai cùng một chức năng, bạn cũng sẽ phải viết mã phức tạp hơn đúng không? Đặc biệt khi xử lý popup, ngay cả việc truyền một
propsthôi mà làm bằng JavaScript thuần cũng khiến mã phức tạp hơn nhiều. Ngay cả những việc đơn giản như thế này mà mã đã trở nên phức tạp thì thật sự các chức năng phức tạp sẽ càng khó triển khai hơn.Đó là sự phức tạp tất yếu. Không còn là HTML theo mẫu đơn giản như trước đây nữa.
Người ta dùng trình duyệt cũng chỉ có vài loại, vậy mà framework thì sao lại nhiều đến thế. Chẳng phải tốt nhất là các công ty quản lý trình duyệt tạo ra framework tối ưu rồi cùng nhau quản lý nó sao. Còn lặp lại vòng luẩn quẩn này đến bao giờ nữa.
Vì triết lý phát triển mà mỗi người theo đuổi khác nhau quá mà.........
Tôi đồng cảm với hiện tượng, nhưng không đồng ý với kết luận.
Nguyên nhân bề mặt của hiện tượng này, như bài viết cũng đã đề cập, là nhu cầu đối với "web kiểu ứng dụng" ngày càng tăng,
và cả bây giờ lẫn trước đây, web vốn không thật sự phù hợp để tạo ra "một thứ gì đó giống ứng dụng", nhưng nếu cố gắng hết sức thì vẫn có thể "làm ra thứ na ná như vậy".
Thực ra, ngay từ khi ra đời, web là một nền tảng được tạo ra để chia sẻ một dạng "tài liệu" như các bài luận văn.
Chỉ cần nhìn vào các thành phần cơ bản của HTML là có thể thấy điều đó.
Sau đó, các công nghệ có thể tạo nội dung động như CGI xuất hiện, rồi ở phía trình duyệt cũng được tích hợp ngôn ngữ script, nhờ vậy có thể thêm tính động cho kết quả hiển thị, và quá trình thoát khỏi "web như một tài liệu" bắt đầu từ đó.
Vấn đề là, từ khoảnh khắc bắt đầu thoát ly đó cho đến hiện tại, nền tảng cốt lõi của web vẫn là một hệ thống dựa trên "tài liệu".
Tất nhiên đã có rất nhiều công nghệ mới không còn thiên về "tài liệu" như WebSocket, WebRTC, WASM, nhưng cho đến nay phần lớn website vẫn được phát triển dựa trên nền tảng "tài liệu" truyền thống.
Chúng ta vẫn phải chồng các thẻ
divlên nhau để vẽ giao diện.Đó là phần phân tích hiện tượng, vậy câu trả lời là gì thì tôi nghĩ như sau:
nếu không hề xét đến tính khả thi mà chỉ tưởng tượng về chức năng của nền tảng kế tiếp trong trạng thái lý tưởng, thì nó sẽ như thế này.
(Không phải mọi website đều phải như vậy, mà chỉ giới hạn ở những website mang tính chất ứng dụng.)
Trước hết, trình duyệt sẽ trở thành một kiểu app launcher.
Một khi đã tải về thì nó phải có thể chạy cả khi ngoại tuyến.
Và ứng dụng sẽ được triển khai bằng các ngôn ngữ khác, thoát khỏi HTML/CSS/JS hiện tại.
Trong quá trình đó, trình duyệt có thể cung cấp một dạng framework giống như Android.
Cách giao tiếp với máy chủ cũng có thể tách khỏi kiểu yêu cầu web hiện tại để sử dụng một paradigma khác.
Với các giao tiếp cần tính thời gian thực, có thể dùng nguyên bản kết nối TCP hiện có,
hoặc cũng có thể tạo mới và sử dụng một cơ chế giao tiếp RPC đơn giản hơn, không dùng giao thức HTTP.
Tôi không hiểu rõ ý cuối cùng bạn nói về việc đó là một nền tảng lý tưởng là gì.
Xét cho cùng thì đó cũng là câu chuyện của thời phải tải chương trình native về rồi dùng ActiveX trên đó.
Về bản chất, đây là màn gồng mình để tạo ra một kiểu web giống ứng dụng bên trong giao thức HTTP vốn dựa trên nền tảng là các "tài liệu" web,
và có ý kiến rằng nếu cần các tính năng ở cấp độ ứng dụng để giải quyết việc này, thì tại sao không tạo một giao thức và framework mới dành cho ứng dụng.
Giống như trên smartphone không chạy chương trình thuần native trực tiếp mà chạy một dạng ứng dụng được sandbox, cấu trúc đó sẽ được thực thi ở cấp độ trình duyệt.
Tất nhiên, để không đi vào vết xe đổ kiểu ActiveX thì tính mở và tiêu chuẩn hóa phải được đặt lên trước.
Ngay cả khi là web kiểu ứng dụng, tôi nghĩ vẫn nên hướng tới điều gần với kết luận đã nêu. Nếu dùng JavaScript quá nhiều thì từ phía client sẽ trở nên nặng nề.
Thực tế cũng không phải là không có framework có thể triển khai theo cách đó. Ngay lúc này, với Next.js, nếu giảm thiểu việc dùng client component chỉ khi thật sự cần thì cũng có thể làm được tương đối, và như người khác đã nói, ở phía hệ sinh thái Rails có Hotwire(https://hotwired.dev/) — một bộ framework hỗ trợ web kiểu ứng dụng (Turbo, Stimulus, v.v.) để có thể tiến rất gần tới kết luận mà tác giả đề cập.
Tôi đồng cảm với nhận thức vấn đề cốt lõi của bài viết này, nhưng cũng có vài chỗ khiến tôi phải hơi nghiêng đầu khó hiểu.
Ví dụ, một website dùng để quảng bá cho một dịch vụ cụ thể do công ty chúng tôi vận hành vẫn đang duy trì chính kiểu đơn giản mà bài này ca ngợi. May là website này có phần lớn thành phần khá tĩnh. Mã HTML, CSS phía frontend đều do con người tự viết tay, không dùng bất kỳ framework nào, còn JS thì chỉ gắn cỡ jQuery và Google Analytics. Các mục như thông báo hay bảng tin được triển khai bằng AJAX dùng jQuery, nhưng tôi không nghĩ mức đó là phi lý hay quá phức tạp. Theo tôi, đó là mức mà hồi xưa khi mới nhập môn phát triển web cơ bản tôi cũng có thể làm được bằng jQuery. Theo tôi biết thì site này đã được vận hành từ thời Internet Explorer, nên không phải do tôi trực tiếp tạo ra, nhưng tôi thấy nó cũng không tệ.
Tuy nhiên, ở đây có gắn quản lý phiên bản Git và pipeline CI/CD, đồng thời tách riêng server staging với server production thực tế. Khi một Pull Request được merge vào nhánh Main, pipeline sẽ chạy bundler rồi tự động triển khai đầu ra lên server staging; sau khi người phụ trách kiểm tra server staging và phê duyệt triển khai cuối cùng thì nó mới được triển khai lại lên server production. Trước đây thì chỉ đơn giản là ghi đè trực tiếp file gốc lên server production qua FTP, nhưng sau khi công việc liên quan được chuyển sang cho đội của chúng tôi thì đã đổi sang cách này.
Đó có thực sự là sự phức tạp phi lý không? Trước kia, sửa thẻ tiêu đề của website đó chỉ là dùng AcroEdit có hỗ trợ kết nối FTP (đúng vậy, những người ban đầu trực tiếp viết HTML cho site đó vẫn còn dùng cái này) để vào thẳng file HTML trên server production, sửa đúng một dòng rồi lưu là xong hết mọi việc, nên có lẽ với họ cảm giác như vậy cũng đúng.
Nhưng theo tôi, mức độ phức tạp tăng thêm này hoàn toàn đáng để chấp nhận. Không phải mọi công việc đều chỉ tương đương với việc sửa đúng một thẻ tiêu đề. Và việc có thể mạnh dạn xóa hẳn đoạn mã cũ từng bị dán chằng chịt dưới dạng comment vì lúc nào cũng có thể khôi phục lại, hay việc theo dõi thay đổi và rollback minh bạch, hoặc việc bundler có thể bổ sung thêm một số tối ưu hóa cơ bản nếu cần, theo tôi đều là những ưu điểm đủ lớn. Việc thêm server staging để có thể xem trước trước khi triển khai lên môi trường thực tế cũng có thể bị coi là một dạng phức tạp, nhưng tôi nghĩ điều đó là cần thiết.
Tôi cũng rất bất mãn với chuyện cấu trúc mã nội bộ của đủ loại website ngày càng trở nên quá phức tạp và nặng nề. Ứng dụng Outlook trên Windows hiện nay được xây dựng dựa trên web app, và gần đây nó đặc biệt còn nặng hơn nữa. Chỉ riêng việc soạn nội dung email trên màn hình hoặc chọn toàn bộ nội dung thôi mà cũng bị giật, thậm chí đến mức hiện cả "trang không phản hồi". Tò mò không hiểu vì sao lại vậy, tôi mở công cụ dành cho nhà phát triển trong Outlook web ra xem và đã bị sốc. Chỉ cần xóa cache rồi tải lại, đến tận 1 phút sau vẫn còn đủ loại request tiếp tục hiện lên. Kiểm tra trong trình duyệt thì chỉ riêng dữ liệu liên quan đến các site MS Office thôi đã lưu đến vài GB.
Tuy nhiên, bài viết này đang trộn lẫn nhiều thứ với nhau; có chỗ tôi đồng cảm, nhưng cũng có chỗ tôi không thấy đồng cảm lắm. Về semantic HTML hay accessibility thì theo tôi biết quá khứ thậm chí còn kinh khủng hơn. Hơn nữa, luận điểm rằng cải thiện trải nghiệm cho lập trình viên lại làm xấu đi trải nghiệm người dùng là điều tôi hoàn toàn không đồng cảm, dù có thể vì tôi không phải là lập trình viên web frontend. Thậm chí, nói rằng mọi quyền lực và khả năng kiểm soát đều tập trung vào lập trình viên còn nghe có vẻ vô lý. Chẳng phải trong công ty, quyền lực nằm ở ban điều hành sao? Hay là ở phương Tây cấu trúc công ty khác Hàn Quốc đến mức đó?
Như mọi khi, tôi hoàn toàn đồng ý rằng sự cân bằng và trung dung, cũng như tính đơn giản và tính thực dụng, là những giá trị quan trọng và cần được ưu tiên trong quá trình ra quyết định. Nhưng bài viết này đang lập luận như thể "đối xử với mọi website như một sản phẩm phần mềm" hoàn toàn là trách nhiệm của lập trình viên, và tôi nghĩ chính điểm đó lại làm lu mờ nhận thức vấn đề cốt lõi. Ngoài ra, những đoạn có vẻ như đang lý tưởng hóa "thời xưa tốt đẹp" khi hệ thống còn chưa được thiết lập bài bản thì ngược lại mới là điều đáng bị phê phán hơn.
Chẳng phải đây là một câu chuyện hoàn toàn khác với điều bạn đang nói sao?
Bạn cho rằng ở điểm nào thì đây là một câu chuyện hoàn toàn khác?
Rốt cuộc, tôi nghĩ điều mà bài viết này phê phán là sự phức tạp quá mức và sự phình to do nó gây ra. Tôi không cho rằng chỉ vì tôi không nhắc đến JavaScript trong bình luận của mình thì đó lại là một bình luận hoàn toàn không liên quan. Xét cho cùng, đó cũng là lời phê phán về một khía cạnh mang tính cục bộ. Và như tôi đã nói ngay từ đầu trong bình luận của mình, bản thân tôi cũng đồng cảm với ý thức vấn đề cốt lõi của bài viết gốc.
Có vẻ bạn đã hiểu sai ý của bài viết gốc.
"...ở đây có gắn quản lý phiên bản Git và pipeline CI/CD, đồng thời đã tách riêng máy chủ staging và máy chủ production thực tế. Khi một Pull Request được merge vào nhánh Main, pipeline sẽ chạy bundler rồi tự động triển khai kết quả tạo ra lên máy chủ staging; sau khi người phụ trách kiểm tra máy chủ staging và phê duyệt triển khai cuối cùng thì nó mới tiếp tục được triển khai lên máy chủ production. Trước đây chỉ đơn giản là dùng FTP để ghi đè trực tiếp các tệp gốc lên máy chủ production, nhưng sau khi công việc liên quan được chuyển sang đội của chúng tôi thì đã được thay đổi như thế này.
Liệu đây có thật sự là sự phức tạp bất hợp lý không?"
Bạn đã nói như vậy, nhưng tôi nghĩ đây là một bài viết khá không liên quan. Mức độ công việc như triển khai và quản lý theo cách đó với điều mà bài viết này đang lập luận dường như là hai chuyện rất khác nhau.
Ý của bài viết gốc không chỉ đơn thuần là phê phán các framework JS đã trở nên phức tạp.
Để tiện, tôi sẽ trích dẫn từ liên kết bản dịch tiếng Hàn ở trên.
> Giờ đây, chỉ để thay đổi một tiêu đề thôi cũng cần 4 kỹ sư, 3 framework và một pipeline CI/CD. Việc xuất bản một trang web đã trở nên phức tạp đến mức kỳ lạ.
> Và rồi từng chút một, web đã trở thành thứ phải được biên dịch trước khi xuất bản. Không phải vì người dùng cần vậy. Mà vì các nhà phát triển muốn cảm thấy mình đang làm điều hiện đại.
> Mọi thứ đều được tối ưu cho nhà phát triển, và trở nên thù địch với tất cả những người còn lại.
> Chúng ta không còn chỉ đơn giản chịu đựng sự phức tạp nữa, mà xem nó là điều hiển nhiên. Chúng ta mặc định rằng mọi site đều cần một bước build, bundler, chiến lược hydration, lớp routing, lớp API, design system và logic vô hiệu hóa bộ nhớ đệm thật khéo léo. Chúng ta xây bằng microservice, host trên edge network, và triển khai cả pipeline chỉ để phân phối nội dung đơn giản.
> Chúng ta đang tái tạo các chức năng của những nền tảng như WordPress, nhưng tạo ra kết quả nặng hơn gấp 10 lần mà khả năng sử dụng lại kém hơn rất nhiều. Tệ hơn nữa là mỗi lớp mới đều mang vào lỗi mới, vấn đề tương thích mới và gánh nặng nhận thức mới. Giờ đây chúng ta phải bảo trì logic hydration, chiến lược cache và pipeline build chỉ để đưa một trang chủ đơn giản lên mạng.
> Chiến dịch marketing bị trì hoãn vì thư viện component không đủ linh hoạt. Các bài test A/B bị hủy vì lớp phân tích không tương thích với chiến lược hydration. Cập nhật nội dung phải chờ build nhiều ngày liền. Những điều chỉnh SEO cơ bản thì bị chôn vùi trong backlog.
> Các marketer không thể cập nhật nội dung chữ hay chạy thử nghiệm nếu không tạo ticket. Họ không thể xem trước nội dung, kiểm tra layout hay xuất bản trang. Mọi thay đổi đều phải đi qua nhà phát triển, pipeline, phê duyệt và build lại.
> Marketer, biên tập viên nội dung, người phụ trách SEO, nhà thiết kế — tất cả đều bị loại khỏi quy trình. Bởi giờ đây ngay cả những việc đơn giản cũng đòi hỏi sự thành thạo kỹ thuật. Nếu bạn muốn đổi thẻ tiêu đề, họ sẽ bảo hãy trao đổi với kỹ sư; nếu bạn muốn xuất bản một chiến dịch, hãy tạo ticket và chờ hai sprint.
> Mọi thứ đều chảy qua đội phát triển. Điều đó có nghĩa là đội phát triển sẽ quyết định điều gì quan trọng, điều gì được triển khai và điều gì bị đẩy khỏi ưu tiên vô thời hạn. Và họ càng thêm nhiều phức tạp, họ càng trở nên không thể thay thế.
Khác với văn hóa phát triển ở Hàn Quốc, nơi quy trình đi từ ban lãnh đạo -> người lập kế hoạch -> lập trình viên, thì ở phương Tây không có khái niệm "người lập kế hoạch" như ở Hàn Quốc, và lập trình viên có phần tham gia tích cực hơn vào việc hoạch định sản phẩm. PM ở phương Tây cũng không hoàn toàn trùng khớp với "người lập kế hoạch" của Hàn Quốc, giống như cover letter và bài tự giới thiệu không phải là hai khái niệm hoàn toàn giống nhau. Tất nhiên, với game — nơi tính chất dự án sáng tạo rất mạnh và yếu tố thú vị cùng gameplay là quan trọng — thì phương Tây cũng ngang hàng hơn so với châu Á, nhưng vẫn có cấu trúc đi từ director xuống lập trình viên.
À, ra là có sự khác biệt như vậy.
Tuy nhiên, có vẻ như điều đó không liên quan nhiều đến nội dung ở trên.
Dùng Rails, sống vui
Tôi đồng ý với ý chính của bài viết này. Dạo này JavaScript bị lạm dụng quá mức nên có nhiều trường hợp trang web bị giật lag dù đang dùng i9-9900k. Dù đây là một cấu hình hơi lửng lơ nếu xét cho chơi game hay làm việc, nhưng thực tế là vẫn có vô số máy tính văn phòng với cấu hình còn thấp hơn thế rất nhiều.
Vì vậy tôi thích Astro và hotwired, những framework theo triết lý chỉ dùng JS khi thật sự cần, chẳng hạn cho các phần tương tác hoặc điều hướng trang có tính tương tác. Tôi cũng thích server-side rendering, tức là hãy render ở phía máy chủ. Ngược lại, tôi cực kỳ không thích CSR (bao gồm cả kiểu chỉ render meta tag ở phía server rồi xử lý phần còn lại bằng CSR). Bởi tôi xem đó là việc đẩy những gì máy chủ phải làm sang cho phía client. Cá nhân tôi cho rằng kiểu SPA truyền thống dùng CSR nên được dùng khi chạy frontend cục bộ trong các ứng dụng như Electron. Tất nhiên, nếu frontend được tải từ server thì vẫn nên dùng SSR.
Dưới đây là bản tóm tắt phản ứng bình luận về bài viết, được phân loại thành 5 kiểu:
1. Hoàn toàn đồng ý và ủng hộ
Đặc điểm chính: Hoàn toàn đồng ý với lập luận của bài viết và thừa nhận vấn đề của stack JS phức tạp.
Ví dụ ý kiến:
2. Lo ngại về việc lạm dụng framework
Đặc điểm chính: Chỉ trích việc dùng quá mức các framework như React, Angular, và cho rằng công nghệ đơn giản là đủ.
Ví dụ ý kiến:
3. Đồng ý một phần + cân nhắc thực tế
Đặc điểm chính: Đồng cảm với lập luận, nhưng cũng có quan điểm thực tế cho rằng sự phức tạp là không thể tránh khỏi hoặc là cần thiết.
Ví dụ ý kiến:
4. Phê phán văn hóa phát triển và cấu trúc ngành
Đặc điểm chính: Chỉ ra rằng tình trạng thừa framework không chỉ là vấn đề kỹ thuật đơn thuần, mà là sản phẩm của cấu trúc tuyển dụng, văn hóa và marketing.
Ví dụ ý kiến:
5. Phê phán hoặc phản đối
Đặc điểm chính: Không đồng ý với tiền đề của bài viết, hoặc cho rằng đó là lập luận một chiều.
Ví dụ ý kiến:
Ồ, chia theo từng loại như vậy nên dễ xem và rất hay.
Tôi đồng cảm với vấn đề “mức độ phức tạp quá mức của web” mà bài gốc chỉ ra. Tuy nhiên, tôi khó đồng ý với chẩn đoán cho rằng nguyên nhân chỉ nằm ở văn hóa lập trình viên hay việc lạm dụng framework. Phần lớn sự phức tạp của web ngày nay thực ra là cái bóng của các tính năng và yêu cầu bảo mật mang tính tất yếu do “mô hình kinh doanh” đòi hỏi. Nếu bỏ qua điểm này, chẩn đoán đó khó tránh khỏi việc chỉ đúng một nửa.
Web không còn là một “phòng trưng bày miễn phí” nữa. Ngày nay, ngoài các trang công cộng, phần lớn dịch vụ web tồn tại với mục tiêu tạo doanh thu. Vì vậy, câu hỏi cốt lõi khi lựa chọn công nghệ không nên là “đoạn code này có thuần khiết không?” mà phải là “công nghệ này có giúp doanh nghiệp của chúng ta thành công hay không?”.
Từ góc nhìn này, “web nội dung nhẹ” mà bài gốc lý tưởng hóa sẽ sớm va vào bức tường của các yêu cầu kinh doanh trong thực tế. Ví dụ, một doanh nghiệp bán nội dung không thể vận hành chỉ bằng các trang tĩnh đơn giản. Để xử lý đăng ký trả phí và thanh toán, cần có logic dựa trên trạng thái như xác thực người dùng, kiểm tra trạng thái thuê bao và quản lý quyền truy cập; để bảo vệ nội dung, cũng cần lớp bảo mật như xác minh token theo thời gian thực nhằm ngăn sao chép trái phép hoặc truy cập không được phép. Hơn nữa, để nâng cao trải nghiệm người dùng và tỷ lệ chuyển đổi thông qua cá nhân hóa và A/B testing, việc xử lý dữ liệu động cũng là điều bắt buộc.
Tất cả những điều này thuộc phạm vi của một “ứng dụng tinh vi”, và framework là công cụ thực tế để hiện thực hóa chúng.
Tất nhiên, không phải mọi sự phức tạp đều có thể được biện minh. Chúng ta cần phân biệt hai loại phức tạp.
Phức tạp tất yếu: là sự phức tạp có ROI rõ ràng, phát sinh để triển khai các chức năng kinh doanh như xác thực, thanh toán, cá nhân hóa, v.v. Đây là chi phí buộc phải chấp nhận.
Phức tạp ngẫu sinh: là sự phức tạp không cần thiết phát sinh do sự tiện tay của lập trình hoặc do trừu tượng hóa kỹ thuật quá mức. Đây là nợ kỹ thuật và sự lãng phí cần được đo lường và loại bỏ liên tục.
Các dịch vụ thành công phân biệt rõ hai loại này để xây dựng kiến trúc thực tế. Nói cách khác, họ áp dụng chiến lược hybrid: giữ cho lớp tiền tuyến nơi marketing và SEO đóng vai trò quan trọng nhẹ nhất có thể, đồng thời dùng nền tảng framework cho các khu vực bên trong cần giao dịch cốt lõi hoặc chức năng cá nhân hóa để đảm bảo độ ổn định — qua đó vừa đạt được tốc độ vừa đảm bảo tính năng.
Bài gốc tập trung nguyên nhân của sự xuống cấp trải nghiệm người dùng chỉ vào văn hóa framework, trong khi lại loại trừ “những yêu cầu tất yếu do mô hình doanh thu tạo ra”. Nếu bỏ qua điểm này mà bàn về phát triển web, thì chẳng khác nào chỉ nói về việc mang “món ăn ngon và nhanh” ra bàn cho khách, nhưng lại xem như không tồn tại căn bếp phức tạp để nấu món đó và quầy thu ngân để thu tiền.
Web có nặng nề đến đâu cũng không thể vì thế mà vứt bỏ framework một cách vô điều kiện. Theo tôi, trọng tâm phải là làm sao hiện thực hóa các chức năng mà doanh nghiệp cần một cách hiệu quả nhất, với chi phí thấp nhất, để mang lại giá trị cho người dùng.
Bản dịch tiếng Hàn ở bên dưới. https://junghan92.medium.com/%EB%B2%88%EC%97%AD-%EC%9E%90%EB%B0%94%EC%…