Chỉ cần một cỗ máy cực khủng với mức giá cực chát là có vẻ đủ? Hãng luật cực khủng thì chắc sẽ mua được thôi. Nhưng mà đúng kiểu chạy máy xưởng 24/7 ấy ha ha ha
Ý 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ế.
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.
Với các dịch vụ như chatbot cần hỗ trợ tính năng streaming, khi xử lý đồng thời thì công đoạn prefill cũng bị ảnh hưởng bởi cả decode, nên dù VRAM có dư dả thì từ góc nhìn người dùng vẫn trông như hiệu năng bị giảm đi rất nhiều.
Tôi cũng đã thử áp dụng các tùy chọn liên quan đến chunk prefill và cả tính năng Disaggregated Prefilling mà vLLM cung cấp ở mức thử nghiệm, nhưng mỗi khi có yêu cầu mới đi vào thì vẫn xảy ra hiện tượng câu trả lời đang được sinh ra trước đó bị khựng và đứt quãng, nên ở góc nhìn của một lập trình viên mới vào nghề, tôi muốn hỏi liệu ngoài cách tăng thêm GPU hoặc node thì còn phương án nào hiệu quả nhất không.
Trên Android, nếu dùng vanced thì bạn có thể ẩn giao diện bình luận, mình khuyên dùng.
Trên trình duyệt web, mình cũng khuyên dùng các tiện ích như Improve Youtube hoặc Adguard để ẩn nó.
Có lẽ sau bản cập nhật đó, các công ty adblock đã tăng doanh thu nhiều hơn.
Những ứng dụng độc lập chặn hẳn ở tầng mạng thì chỉ dùng được bản trả phí, nên chắc cũng bán được khá nhiều.
"...ở đâ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.
Tôi cũng liên tục nhận được thông báo đẩy trên Android nói rằng không thể truy cập máy chủ DNS.
Tạm thời tôi chuyển sang dùng Google DNS.
https://developers.google.com/speed/public-dns/…
wow...
Đúng vậy, có vẻ như càng đào sâu vào mục tiêu là gì và tại sao phải làm thì càng tìm ra được giải pháp rõ ràng hơn.
Cảm ơn bạn đã đón nhận bài viết!
Cảm ơn những lời chia sẻ rất hay!
Chỉ cần một cỗ máy cực khủng với mức giá cực chát là có vẻ đủ? Hãng luật cực khủng thì chắc sẽ mua được thôi. Nhưng mà đúng kiểu chạy máy xưởng 24/7 ấy ha ha ha
Một người chỉ nghĩ đến giá mua Porsche mà hoàn toàn không tính đến chi phí bảo dưỡng, tiền xăng, bảo hiểm, v.v.
Ý 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ế.
Có lẽ không áp dụng được với các công ty Hàn Quốc
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.
Với các dịch vụ như chatbot cần hỗ trợ tính năng streaming, khi xử lý đồng thời thì công đoạn prefill cũng bị ảnh hưởng bởi cả decode, nên dù VRAM có dư dả thì từ góc nhìn người dùng vẫn trông như hiệu năng bị giảm đi rất nhiều.
Tôi cũng đã thử áp dụng các tùy chọn liên quan đến chunk prefill và cả tính năng Disaggregated Prefilling mà vLLM cung cấp ở mức thử nghiệm, nhưng mỗi khi có yêu cầu mới đi vào thì vẫn xảy ra hiện tượng câu trả lời đang được sinh ra trước đó bị khựng và đứt quãng, nên ở góc nhìn của một lập trình viên mới vào nghề, tôi muốn hỏi liệu ngoài cách tăng thêm GPU hoặc node thì còn phương án nào hiệu quả nhất không.
Đây chẳng phải là một thái độ chịu trách nhiệm hơn sao; cá nhân tôi dường như đồng cảm với chính định hướng của Google.
Tôi cũng đồng ý. Không biết có phải là quá hai mặt không nữa. Nhưng mấy thứ được làm tốt thì họ vẫn để yên đấy.
Tôi không hiểu vì sao lại gọi đó là thái độ hai mặt...
Trên Android, nếu dùng vanced thì bạn có thể ẩn giao diện bình luận, mình khuyên dùng.
Trên trình duyệt web, mình cũng khuyên dùng các tiện ích như Improve Youtube hoặc Adguard để ẩn nó.
Tùy trường hợp thôi!
Có lẽ sau bản cập nhật đó, các công ty adblock đã tăng doanh thu nhiều hơn.
Những ứng dụng độc lập chặn hẳn ở tầng mạng thì chỉ dùng được bản trả phí, nên chắc cũng bán được khá nhiều.
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.
Tò mò Faceted Search là gì nên tôi lần theo thì thấy còn có vài thứ đáng đọc thêm.
https://www.cybertec-postgresql.com/en/faceting-large-result-sets/
https://roaringbitmap.org/about/
https://github.com/cybertec-postgresql/pgfaceting
Nội dung này thật sự rất đồng cảm. Tôi cũng đã bỏ SNS, và giờ gần như không còn đọc bình luận trên YouTube nữa.