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.
Vì thương vụ OpenAI mua lại mà Claude đã ngừng cung cấp giấy phép cho phiên bản mới nhất, nên nếu muốn dùng các model Claude 4.x trên Windsurf thì phải tự mua API với giá đắt; liệu Claude có quay lại không?
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.
Thật quá đáng sợ.
Việc những hồ sơ bị ghi lại một cách ác ý
lấn át ký ức và trải nghiệm, trở thành bằng chứng
và có thể dẫn đến chuyện đe dọa chúng ta, quả thực có thể xảy ra.
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.
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ẻ div lê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.
Một tháng trước, tôi bắt tay phát triển một framework để vừa học xem AI coding là gì bằng cách tận dụng CURSOR.
Trong khoảng 3 tuần, tôi liên tục lặp lại cảnh thành công rồi lại để mã nguồn từng được AI Agent kiểm chứng bị phá hỏng, và đã cố gắng bằng mọi cách để kiểm soát AI Agent nhưng vẫn thất bại.
Rồi tôi nhận ra rằng trước khi phát triển framework, ưu tiên trước hết phải là phát triển mã nguồn để kiểm soát AI Agent.
Cuối cùng, đúng tròn 1 tháng kể từ khi bắt đầu để tìm hiểu AI thực sự là gì, tôi đã đạt được thành quả hoàn tất phát triển phần mềm có thể được AI triển khai 100% và vận hành 100% một cách hoàn toàn kiểm soát được AI Agent (chính xác hơn là không cần LLM bên ngoài hay AI Agent).
Hiện tại đã là ngày thứ 14, tôi đang tiếp tục huấn luyện bổ sung META AI đó để nâng cấp thêm, đồng thời xây dựng và buộc nó tuân thủ các quy định vận hành; song song đó, tôi cũng đang tiến hành migration, cải tiến và chuẩn hóa cùng lúc 3 hệ thống MES vốn trước đây do con người làm ra một cách chưa hoàn chỉnh, và hiện đã bước vào giai đoạn hoàn tất.
Và lúc này, tôi đang chuẩn bị cho một sự tiến hóa khác nữa.
Tôi cho rằng tầm nhìn cốt lõi của công nghệ MCP-B là như sau.
"Thông qua một trung gian đáng tin cậy là tiện ích mở rộng Chrome (Extension), tận dụng thông tin người dùng mà trình duyệt đã quản lý an toàn sẵn có (cookie, phiên, xác thực, v.v.),
gọi và điều khiển các 'công cụ (Tools)' mà nhà phát triển đã định nghĩa trước trên trang web bằng lệnh ngôn ngữ tự nhiên từ cửa sổ chat AI."
Tuy nhiên, tôi cảm thấy rằng "có vẻ không có nhiều khả năng để mở rộng", và tôi nghĩ lý do là như sau.
Sự kháng cự từ người dùng: Đây là rào cản lớn nhất. Người dùng vốn có sự e ngại bản năng và lo ngại về bảo mật đối với việc cài đặt tiện ích mở rộng có thể truy cập thông tin trình duyệt của mình. Nếu sự tiện lợi mà công nghệ này mang lại không đủ áp đảo để vượt qua những lo ngại đó, người dùng sẽ ngần ngại cài đặt.
Gánh nặng cho nhà phát triển web: Ngoài việc xây dựng API hiện có, các nhà phát triển website còn phải gánh thêm việc định nghĩa và quản lý riêng các 'công cụ (Tools)' cho MCP-B. Nếu lợi ích thu được từ việc công nghệ này được chấp nhận rộng rãi không đủ lớn, các nhà phát triển sẽ không muốn bỏ công sức gấp đôi như vậy.
Trách nhiệm đối với vấn đề bảo mật: Nếu xảy ra sự cố bảo mật thông qua công nghệ này, có thể sẽ không rõ trách nhiệm thuộc về nhà phát triển website, nhà phát triển tiện ích mở rộng hay nhà cung cấp mô hình AI. Sự phức tạp này khiến doanh nghiệp ngần ngại áp dụng công nghệ.
Thiếu nền tảng tập trung: Hiện tại chưa có thư mục hay nền tảng được chuẩn hóa nào cho biết "website nào cung cấp những công cụ nào". Người dùng khó biết mình có thể sử dụng tính năng AI nào cho đến khi truy cập vào website đó.
Kết luận là,
ý tưởng của MCP-B tự thân rất thú vị và đổi mới về mặt kỹ thuật, nhưng có vẻ chưa thể đưa ra câu trả lời rõ ràng cho câu hỏi cốt lõi của cả người dùng lẫn nhà phát triển rằng "tại sao nhất định phải dùng cách này?". So với phương thức API hiện có, lợi ích đạt được còn không rõ ràng, trong khi các nhược điểm như lo ngại bảo mật và độ phức tạp trong phát triển lại rất rõ ràng.
Vì vậy, ở thời điểm hiện tại, công nghệ này có thể được sử dụng thử nghiệm trong phạm vi một số người đam mê hoặc các nhà phát triển có mục đích cụ thể, nhưng có vẻ sẽ gặp nhiều khó khăn để mở rộng ra toàn bộ hệ sinh thái web.
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.
Lại bị lừa nữa à~
Không dễ để dùng kiểu bấm cái là xong cho thật tiện.
Grok 4 giờ đã là mô hình AI hàng đầu
Đánh giá Grok 4 của Simon Willison
Grok tìm kiếm Elon Musk nói gì trên X về vấn đề Israel-Palestine
Mọi thứ đều ổn, nhưng nếu dùng cái này thì không thể điều khiển WireGuard trên hệ thống. Nếu muốn dùng riêng với tunnel thì phải tách ra bằng VM.
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.
Vì thương vụ OpenAI mua lại mà Claude đã ngừng cung cấp giấy phép cho phiên bản mới nhất, nên nếu muốn dùng các model Claude 4.x trên Windsurf thì phải tự mua API với giá đắt; liệu Claude có quay lại không?
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.
Vì triết lý phát triển mà mỗi người theo đuổi khác nhau quá mà.........
Đúng là ngay cả AI cũng không công bằng.
Thật quá đáng sợ.
Việc những hồ sơ bị ghi lại một cách ác ý
lấn át ký ức và trải nghiệm, trở thành bằng chứng
và có thể dẫn đến chuyện đe dọa chúng ta, quả thực có thể xảy ra.
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.
Tôi tò mò vì sao thương vụ này lại đổ bể.
Hóa ra hình thái tối thượng của AI nịnh người dùng lại là AI nịnh sếp...
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.
Ôi, có vẻ tương lai của Windsurf cũng không hẳn là tươi sáng.
Một tháng trước, tôi bắt tay phát triển một framework để vừa học xem AI coding là gì bằng cách tận dụng CURSOR.
Trong khoảng 3 tuần, tôi liên tục lặp lại cảnh thành công rồi lại để mã nguồn từng được AI Agent kiểm chứng bị phá hỏng, và đã cố gắng bằng mọi cách để kiểm soát AI Agent nhưng vẫn thất bại.
Rồi tôi nhận ra rằng trước khi phát triển framework, ưu tiên trước hết phải là phát triển mã nguồn để kiểm soát AI Agent.
Cuối cùng, đúng tròn 1 tháng kể từ khi bắt đầu để tìm hiểu AI thực sự là gì, tôi đã đạt được thành quả hoàn tất phát triển phần mềm có thể được AI triển khai 100% và vận hành 100% một cách hoàn toàn kiểm soát được AI Agent (chính xác hơn là không cần LLM bên ngoài hay AI Agent).
Hiện tại đã là ngày thứ 14, tôi đang tiếp tục huấn luyện bổ sung META AI đó để nâng cấp thêm, đồng thời xây dựng và buộc nó tuân thủ các quy định vận hành; song song đó, tôi cũng đang tiến hành migration, cải tiến và chuẩn hóa cùng lúc 3 hệ thống MES vốn trước đây do con người làm ra một cách chưa hoàn chỉnh, và hiện đã bước vào giai đoạn hoàn tất.
Và lúc này, tôi đang chuẩn bị cho một sự tiến hóa khác nữa.
Tôi cho rằng tầm nhìn cốt lõi của công nghệ MCP-B là như sau.
"Thông qua một trung gian đáng tin cậy là tiện ích mở rộng Chrome (Extension), tận dụng thông tin người dùng mà trình duyệt đã quản lý an toàn sẵn có (cookie, phiên, xác thực, v.v.),
gọi và điều khiển các 'công cụ (Tools)' mà nhà phát triển đã định nghĩa trước trên trang web bằng lệnh ngôn ngữ tự nhiên từ cửa sổ chat AI."
Tuy nhiên, tôi cảm thấy rằng "có vẻ không có nhiều khả năng để mở rộng", và tôi nghĩ lý do là như sau.
Kết luận là,
ý tưởng của MCP-B tự thân rất thú vị và đổi mới về mặt kỹ thuật, nhưng có vẻ chưa thể đưa ra câu trả lời rõ ràng cho câu hỏi cốt lõi của cả người dùng lẫn nhà phát triển rằng "tại sao nhất định phải dùng cách này?". So với phương thức API hiện có, lợi ích đạt được còn không rõ ràng, trong khi các nhược điểm như lo ngại bảo mật và độ phức tạp trong phát triển lại rất rõ ràng.
Vì vậy, ở thời điểm hiện tại, công nghệ này có thể được sử dụng thử nghiệm trong phạm vi một số người đam mê hoặc các nhà phát triển có mục đích cụ thể, nhưng có vẻ sẽ gặp nhiều khó khăn để mở rộng ra toàn bộ hệ sinh thái web.
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.
Giả vờ thật~ chán…
Hàn Quốc đúng là từ đầu đến cuối đều là xứ sở Java nên thấy lạ cũng phải thôi kk