AI có đang khiến frontend lặp lại 10 năm đã mất?
(mastrojs.github.io)- Phi kỹ năng hóa thay thế lao động có tay nghề bằng việc vận hành công nghệ ở mức kỹ năng thấp hơn để giảm chi phí và hạ rào cản gia nhập, nhưng cũng làm suy yếu năng lực thương lượng của người lao động
- Trong 10 năm qua, frontend đã trải qua giai đoạn mà framework và công cụ che khuất kiến thức về trình duyệt, khả năng truy cập và hiệu năng, đẩy chuyên môn front of the frontend ra ngoài lề
- AI tác tử đưa việc viết mã lên mức trừu tượng cao hơn, nhưng là một kiểu trừu tượng rò rỉ (Leaky) do tính không quyết định và việc những thay đổi nhỏ ở đầu vào hay mô hình cũng có thể tạo ra kết quả rất khác
- LLM là phần tiếp nối của kiểu copy-paste từ Stack Overflow: người có kỹ năng sẽ nhanh hơn, còn người mới cũng có thể tạo ra thứ chạy được, nhưng vẫn cần ai đó hiểu và sửa đầu ra
- AI có thể tạo ra nhiều AI slop hơn và giúp cắt giảm chi phí, nhưng điều đó không có nghĩa là không còn cần những người hiểu về chất lượng, người dùng và các đánh đổi
Frontend và AI coding nhìn từ góc độ phi kỹ năng hóa
- Phi kỹ năng hóa (deskilling) là quá trình thay thế lao động có tay nghề bằng công nghệ mà lao động bán kỹ năng hoặc không có kỹ năng cũng có thể sử dụng; nó giúp giảm chi phí và hạ rào cản gia nhập nhưng đồng thời làm suy yếu năng lực thương lượng của người lao động
- Trong 10 năm qua, phát triển frontend đã trải qua quá trình phi kỹ năng hóa thông qua các framework và công cụ JavaScript, và trên toàn bộ lĩnh vực lập trình, AI tác tử cũng đang tạo ra thay đổi tương tự
- Như cách gọi Frontend’s Lost Decade, chuyên môn frontend từng gắn với hiểu biết sâu về trình duyệt và môi trường người dùng đã bị đẩy lùi bởi lối phát triển lấy framework làm trung tâm
Chuyên môn đã biến mất khỏi frontend
- Trước đây, phát triển frontend đòi hỏi kiến thức chuyên sâu về HTML ngữ nghĩa, CSS, khác biệt giữa các trình duyệt, khả năng truy cập, cải tiến tăng dần, hiệu năng mạng, thiết kế giao diện và kiểm thử người dùng
- Một số người làm nghề gọi những lĩnh vực này là front of the frontend để phân biệt với “frontend” hiện nay
- Quá trình phi kỹ năng hóa frontend diễn ra thông qua việc áp dụng framework và công cụ coi trình duyệt như một mục tiêu biên dịch đơn giản, tương tự JVM hay iOS như một runtime ứng dụng
- Khi lấy các thành phần như Shadcn radio button, bạn có thể tạo tính năng mà không cần hiểu sâu về HTML nền tảng, những khác biệt tinh vi giữa các trình duyệt, hiệu năng tải trang hay khả năng truy cập
- Doanh nghiệp có thể dễ dàng đưa các lập trình viên phổ thông vào làm việc frontend để giảm chi phí
- “Lập trình viên full-stack” ngày nay thường không còn chỉ người hiểu sâu cả frontend lẫn backend, mà là nhà phát triển đa năng có thể xử lý cả hai phía bằng framework JavaScript
- Có thể dễ dàng điều chuyển cùng một lập trình viên giữa nhiều dự án, và thậm chí giao cả ứng dụng native với React Native và Electron
- Cùng với lợi thế hạ rào cản gia nhập, năng lực thương lượng của người lao động cũng suy yếu
AI coding là mức trừu tượng cao hơn, đồng thời cũng là trừu tượng rò rỉ
- Những thay đổi đang diễn ra trong toàn bộ ngành lập trình hiện nay rất giống với điều các nhà phát triển web đã trải qua trước đó
- Nó đang dịch chuyển theo hướng thay thế công việc đòi hỏi kỹ năng viết mã thủ công bằng công nghệ mà lao động bán kỹ năng hoặc không có kỹ năng cũng có thể sử dụng
- Hiện vẫn chưa rõ rốt cuộc người lao động sử dụng AI tác tử sẽ cần những năng lực nào, và giá lao động cũng như chi phí LLM cục bộ hay từ xa sẽ đi đến đâu
- Nhưng có vẻ rất rõ rằng doanh nghiệp sẽ dùng công nghệ này để cắt giảm chi phí và làm suy yếu năng lực thương lượng của người lao động
- Việc giá trị thị trường của kỹ năng được mài giũa lâu năm suy giảm gợi nhớ đến giai đoạn thợ thủ công và nghệ nhân bị thay thế bởi lao động dây chuyền lắp ráp
- Có thể xem phi kỹ năng hóa như một sự gia tăng hiệu quả nhờ tự động hóa, tức là chuyển sang làm việc ở mức độ trừu tượng cao hơn
- Công nghệ mới che giấu chi tiết và cho phép người vận hành tập trung vào bức tranh lớn hơn, nhưng việc coi chi tiết nào là “không quan trọng” lại là một phán đoán rất hệ trọng
- Các chi tiết của trừu tượng rốt cuộc rồi cũng rò rỉ ra ngoài
-
Trừu tượng rò rỉ của frontend “hiện đại”
- Trừu tượng thường đi kèm chi phí hiệu năng; việc chấp nhận hy sinh một phần hiệu năng runtime để đổi lấy năng suất lập trình viên có thể là lựa chọn hợp lý khi có máy chủ mạnh và tải ở mức vừa phải
- Nhưng trên điện thoại di động với mạng chậm, cùng một đánh đổi đó trở thành một vấn đề hoàn toàn khác
- Khi dùng nhiều framework JavaScript phía client nặng như React và các package trong hệ sinh thái, bạn đã trừu tượng hóa mất các vấn đề về khả năng truy cập và hiệu năng trên điện thoại cấu hình thấp hoặc mạng chậm
- Kết quả là những lựa chọn được đưa ra mà không nghĩ đến, cũng không quan tâm đến các vấn đề đó
-
Tính không quyết định của coding theo kiểu tác tử
- Khi tạo tính năng hoặc sửa lỗi bằng AI tác tử, thay vì tự tay viết toàn bộ mã, bạn mô tả thay đổi ở mức cao hơn bằng ít từ hơn
- AI nhìn vào dữ liệu huấn luyện và ngữ cảnh xung quanh để điền vào các chi tiết bị lược bỏ; đôi khi nó đoán đúng, đôi khi lại thất bại
- Mức độ hữu ích của cách này phụ thuộc rất lớn vào việc bạn cho rằng điều gì là quan trọng trong lập trình
- Coding theo kiểu tác tử không có tính quyết định như compiler; chỉ một thay đổi nhỏ ở đầu vào hoặc mô hình cũng có thể dẫn đến kết quả rất khác nhau, nên nó rò rỉ còn nhiều hơn các lớp trừu tượng lập trình trước đây
- Việc so sánh AI với “junior engineer” cũng bắt nguồn từ tính không quyết định này, nhưng con người khác ở chỗ họ có thể học mà không cần bạn chỉnh AGENTS.md hay SKILL.md mãi mãi
LLM là phần tiếp nối của kiểu copy-paste từ Stack Overflow
- Phép so sánh gần nhất với việc dùng LLM là cách người ta từng dùng Google Search
- Khả năng chọn đúng từ khóa để đưa bài viết diễn đàn hoặc câu trả lời trên Stack Overflow phù hợp lên trang kết quả đầu tiên cũng từng là một kỹ năng mà lập trình viên phải học
- Prompt cho LLM cũng là quá trình buộc hệ thống trả về tổ hợp phù hợp từ dữ liệu huấn luyện, gần giống một truy vấn trong không gian rất cao chiều như tìm kiếm web mơ hồ
- Kết quả tìm kiếm vốn nhạy cảm với thay đổi nhỏ trong cách diễn đạt và thay đổi trong chỉ mục tìm kiếm của Google; LLM cũng nhạy cảm với cách biểu đạt đầu vào và thay đổi mô hình
- Gần đây Google đã thay đổi tìm kiếm để chuẩn hóa mạnh hơn các từ ngữ đầu vào; điều này giúp việc tìm kiếm dễ hơn với người không quen “Google-fu”, nhưng lại làm nó kém mạnh mẽ hơn với người thành thạo
- Google và Stack Overflow đã thay đổi lập trình theo cách không thể đảo ngược, khiến việc copy-paste câu trả lời thay cho đọc tài liệu hướng dẫn có thể tạo ra kết quả hoạt động được ở mức nào đó với tần suất đáng ngạc nhiên
- LLM là phần tiếp nối của cùng một xu hướng đó
- Nó giúp những người biết mình đang làm gì trở nên nhanh hơn một chút
- Nó cũng cho phép những người không thật sự biết mình đang làm gì tạo ra thứ gì đó chạy được ở mức nào đó
- Trừu tượng rồi sẽ rò rỉ, và khi điều đó xảy ra, sẽ cần ai đó thực sự hiểu sâu chuyện gì đang diễn ra để sửa lại
- Cũng như từng dạy lập trình viên junior phải đọc và hiểu câu trả lời trên Stack Overflow trước khi dùng, giờ đây cũng cần dạy họ đọc, hiểu đầu ra của LLM và nắm được nó khớp với codebase hiện có như thế nào
Khoảng cách giữa chất lượng và kinh doanh
- Một số lập trình viên chưa bao giờ tiến đến mức thực sự hiểu câu trả lời trên Stack Overflow; họ cho rằng chỉ cần kết quả chạy được là đủ
- Nhiều công ty, dù không công khai thừa nhận, thực ra cũng hài lòng với cách tiếp cận như vậy
- Giờ đây, các công ty còn công khai khoe mình dùng AI nhiều đến mức nào mà thậm chí không còn giả vờ là họ đang xem xét kỹ đầu ra
- Rõ ràng LLM có những use case hợp lệ, nhưng đồng thời cũng có thêm nhiều cách mới để phá hỏng code, giao tiếp trong tổ chức và quy trình làm việc
- Cũng như code review, tồn tại bất đồng lớn về cách dùng và tích hợp LLM vào workflow; nếu không khớp với điều mà cả nhóm coi trọng thì luồng làm việc rất dễ phát sinh vấn đề lớn
- Nhiều công ty vẫn vận hành ổn dù liên tục tạo ra phần mềm tệ
- Trái với điều các lập trình viên muốn tin, thành công kinh doanh và chất lượng phần mềm chỉ hiếm khi có tương quan
- Thông thường, những yếu tố khác như thương hiệu hay giá cả tác động mạnh hơn, và các dự án phần mềm thường bị đối xử như một hộp đen nơi thành công hay thất bại xuất hiện với xác suất gần tương đương
- Trong frontend cũng vậy: website chậm và quá nhiều cookie banner có thể làm giảm tỷ lệ chuyển đổi, nhưng tác động đó thường nhỏ hơn những yếu tố như lòng trung thành với thương hiệu hay giá cả, và website của đối thủ cạnh tranh cũng thường chậm
- Trong bầu không khí kiểu “không ai bị sa thải vì chọn React”, lựa chọn an toàn được ưu tiên hơn chất lượng
- Điều này không có nghĩa là bạn nên ngừng quan tâm tới người dùng và tinh thần nghề nghiệp, nhưng việc tìm được nơi làm việc cho phép bạn làm như vậy đã khó hơn
- Khi cơn sốt qua đi và người ta hiểu rõ hơn công việc nào thực sự phù hợp với LLM và công việc nào không, có thể một phần cân bằng sẽ quay trở lại, nhưng bản thân nghề này sẽ không còn như trước
Những kỹ năng vẫn còn sau công nghiệp hóa
- Khi các sản phẩm và công trình thường nhật bắt đầu có thể được sản xuất hàng loạt bằng quy trình công nghiệp, một phản ứng là đưa ra những sản phẩm và công trình do nhà máy tạo ra nhưng trông như đồ thủ công, bằng cách mô phỏng phong cách quá khứ
- Đối lại với chủ nghĩa lịch sử, đầu thế kỷ 20, Bauhaus đã phát triển một cách tiếp cận không đặt công nhân nhà máy và nghệ nhân vào thế đối lập, mà để họ cùng làm việc và tái phát triển nghệ thuật cùng thủ công trên tiền đề của quy trình sản xuất công nghiệp
- Bauhaus yêu cầu nhà thiết kế quay lại xưởng, trực tiếp xử lý vật liệu, nhưng mục tiêu cuối cùng phải là các thiết kế có thể sản xuất hàng loạt
- Phần mềm gần với nghề thủ công ở chỗ chương trình được viết ra được chuyển tới người dùng “nguyên trạng” mà không qua một công đoạn sản xuất riêng, nhưng lại gần với thiết kế công nghiệp ở chỗ cùng một thứ được phân phối cho hàng nghìn người dùng
- Khả năng tự tay viết mã vẫn cần thiết; cũng như nhà thiết kế công nghiệp phải hiểu vật liệu của sản phẩm, nhà thiết kế web phải rất thành thạo HTML và CSS
- Google, Stack Overflow, các thư viện dùng ngay, và LLM giúp người mới bắt đầu dễ tiếp cận hơn, nhưng cũng liên tục hạ thấp rào cản tự nhiên để khiến một thứ gì đó chạy được
- Công nghiệp hóa đã tạo ra rất nhiều sản phẩm nhựa rẻ tiền mà không suy nghĩ đủ về cách dùng và người dùng, nhưng thiết kế công nghiệp tốt vẫn tồn tại
- Trình xử lý văn bản đã tạo ra rất nhiều tài liệu định dạng tệ, nhưng typography và thiết kế đồ họa vẫn tồn tại
- Wix và Next.js đã cho phép tạo ra nhiều website chậm và kém khả năng truy cập, nhưng những người làm front of the frontend vẫn còn đó
- AI cho phép tạo ra rất nhiều AI slop, nhưng điều đó không có nghĩa là không còn cần những người biết mình đang làm gì và quan tâm đến công việc của mình
Thay đổi và đánh đổi trong thời gian tới
- Cũng như các ngành khác, tỷ trọng của phần công việc được làm đúng cách có thể sẽ trở nên nhỏ hơn trong tổng thể
- Đồng thời, vì việc tạo ra sản phẩm sẽ dễ hơn và rẻ hơn, chiếc bánh tổng thể vẫn sẽ tiếp tục lớn lên
- Hiện rất khó nói số lượng tuyệt đối những người được trả công để làm tốt công việc sẽ tăng hay giảm
- Có những lúc việc nhanh chóng tung ra prototype hay MVP là lựa chọn đúng
- Nếu bạn vẫn chưa tìm được product-market fit, thì lặp lại nhanh và học nhanh thường quan trọng hơn việc xây dựng mọi thứ để sẵn sàng cho tương lai
- Tuy vậy, bạn phải biết mình đang muốn học điều gì và sẽ xác thực việc học đó như thế nào
- Khi đến đúng thời điểm, thường tốt hơn là lùi lại một bước và làm lại cho đúng ngay từ đầu
- Ví dụ, về sau sẽ rất khó đạt hiệu năng tốt trên một frontend có kiến trúc tệ
- Bắt đầu với stack đơn giản rồi bổ sung tính năng về sau thường dễ hơn làm ngược lại
- Mastro khuyến khích một cách rõ ràng việc bắt đầu với hiệu năng tốt và stack đơn giản
- Dù bạn chọn mua dịch vụ, dùng thư viện mã nguồn mở, sinh bằng LLM hay tự viết, bạn vẫn phải biết mình đang chấp nhận những đánh đổi nào ở từng phần của hệ thống
- Khi cơn sốt lắng xuống, ngành này sẽ nhận ra rằng AI chỉ là một công cụ nữa trong hộp đồ nghề
- Từ nay đến lúc đó, những đoạn code xấu xí, giao tiếp đổ vỡ và các đợt sa thải tồi tệ dưới danh nghĩa AI có thể vẫn sẽ tiếp tục xuất hiện
Muốn tiếp tục nhận các chủ đề công nghệ được tuyển chọn?
Theo dõi kênh Telegram. @GeekNewsVN
1 bình luận
Ý kiến trên Hacker News
Theo tôi, điều OP tiếc nuối là chuyên môn sâu, nhưng thực ra với nhiều người đó lại là thứ khá bất tiện
Tôi hiểu chuyện phải sống bằng kỹ năng như xử lý dị biệt giữa các trình duyệt, tự triển khai component có thể truy cập được, hay độ thành thạo về CSS, nhưng phần lớn trong số đó gần với độ phức tạp ngẫu nhiên hơn. Việc nhiều người hơn có thể tạo ra thứ gì đó rõ ràng là điều tốt, và nếu một phần kết quả chậm hơn hoặc kém khả năng truy cập hơn thì đó là sự đánh đổi có thể lựa chọn
Có thể nói rằng lớp trừu tượng đang áp đặt những kết quả mà người dùng không chọn, nhưng tôi cũng nghĩ LLM có thể hiểu các quy ước về accessibility tốt hơn tôi
Thế nhưng các framework siêu cấp cao và giờ là cả LLM lại làm hỏng những phần này trong khi vẫn giúp tung ra MVP nửa sống nửa chín thật nhanh, nên khoảng cách giữa “chấp nhận được” và “ổn” ngày càng rộng ra. Với những người hướng tới mức “ổn”, việc cạnh tranh với phía chỉ cố đẩy “chấp nhận được” ngày càng khó hơn
Kết quả là nhiều làm đêm hơn và chất lượng phần mềm đi xuống, thậm chí có thể kéo theo mức độ hài lòng với công việc nhìn chung giảm sút. Dạo này đã bắt đầu có chuyện phải dùng devtools và uBlock để sửa website bị hỏng hoặc xóa các yếu tố gây phiền nhằm khôi phục chức năng cơ bản, và tôi cũng thấy người khác nói họ làm y như vậy ở đây (https://news.ycombinator.com/item?id=47042747). Ngay cả thời Flash hay thời đầu của trình duyệt trước đây cũng không cần phải tự tay can thiệp kiểu này
Cũng có ví dụ bớt mang tính giai thoại hơn: https://news.ycombinator.com/item?id=47390945
Tệ hơn nữa là phần lớn số tiền tiết kiệm được từ những cắt giảm này chỉ chảy về tầng lớp cao nhất trong tổ chức
AI mode của Google cũng có thứ như vậy, và các website khác dường như cũng đã đưa vào những thứ tương tự bằng vibe coding một cách quá rõ ràng
Ban đầu tôi không hiểu vì sao mức dùng GPU tăng vọt và quạt quay ầm ầm, nhưng giờ thì thấy đây là lỗi AI hay mắc mà chẳng ai test cho tử tế. Con người cũng có thể mắc lỗi kiểu này, nhưng cho tới tận gần đây thì cả đời tôi hầu như chưa từng gặp
Tôi dùng màn hình 240Hz nên trình duyệt định redraw 240 lần mỗi giây, và chỉ còn cách chặn bằng uBlock Origin. Thật vô lý
Điều dở hơn là đến khoảng giữa bài thì chúng lại tự phản bác chính luận điểm của mình
Ví dụ, bài viết nói rằng “việc xem chi tiết nào là không quan trọng là một quyết định cực kỳ hệ trọng, đôi khi mang tính chủ quan, và rốt cuộc thì chi tiết luôn rò rỉ ra ngoài”, mà nếu vậy thì công nghệ mới này cuối cùng vẫn sẽ thưởng cho hiểu biết kỹ thuật sâu. Vì điều đó là không thể tránh khỏi. Tôi đồng ý ở điểm đó. Nhưng vậy tại sao toàn bộ giọng điệu lại là “AI đang biến kỹ năng của tôi thành hàng hóa rẻ tiền”?
Về mặt kỹ thuật, website nói chung hiện tốt hơn 10 năm trước. Chúng có nhiều chức năng hơn, nhanh hơn, và SSL/accessibility/responsive đã trở thành các mặc định mạnh hơn. Các vấn đề của content farm, SEO và website tin tức là một kiểu thất bại khủng khiếp riêng do quảng cáo và incentive doanh nghiệp tạo ra, chứ không phải lỗi của React
LLM đôi khi có thể tận dụng điều đó. Nhưng nếu con người không còn viết nữa thì sau đó sẽ ra sao?
Tôi đồng ý rằng việc nhiều người hơn tạo ra thứ gì đó là điều tốt. Nếu các yếu tố khác giữ nguyên thì càng nhiều càng tốt. Nếu “AI” thấm vào mọi nơi vì những cải thiện không thể phủ nhận, thì bối cảnh và tâm trạng hẳn đã rất khác
Dù vậy, con người không đương nhiên có quyền đối với tri thức được “tạo ra” thông qua lao động của người khác. Nếu vấn đề ghi nhận công lao và bồi thường được xử lý nghiêm túc, và chỉ được học từ dữ liệu mà người tạo ra dữ liệu đã được trả tiền, thì có lẽ học CSS luôn sẽ nhanh hơn và rẻ hơn nhiều
Tất nhiên chẳng ai quan tâm đến máy tính của người dùng/mức sử dụng bộ nhớ, trải nghiệm xuống cấp, băng thông bị lãng phí, hay chi phí năng lượng và tác động môi trường cộng thêm lên 8 tỷ người
Việc nhiều người hơn cùng xây dựng hạ tầng công cộng cũng là điều “rõ ràng tốt” sao? Nếu kết quả là đường sá tệ hơn, cầu cống tệ hơn, hệ thống thất bại thì sao? Phần mềm cũng vậy, và thực ra đa số mọi thứ đều thế
Phần lớn những “công nghệ frontend” mà bài viết này nói là đang mất đi tính liên quan thực chất là công việc phải lần mò qua một bãi mìn đầy những ngoại lệ phi trực quan, trình duyệt không tương thích, gánh nặng lịch sử, và ngoại lệ của ngoại lệ của ngoại lệ
Frontend hiện đại, tức “tòa tháp của những tầng trừu tượng rò rỉ”, cuối cùng cũng đã tiến gần hơn đến một mô hình tư duy hợp lý cho phát triển web. Nó là thứ bị ép chồng lên trên mớ chất nổ kỳ quặc mang tên tiêu chuẩn và tập quán web, nhưng việc nó vẫn hoạt động và chỉ rò rỉ một chút tự nó đã là một thành tựu
Chúng ta vẫn đang ở trong bãi mìn ngoại lệ ấy, và khó có thể nói các công nghệ dùng để xây dựng frontend đã trở nên sạch sẽ, dễ dự đoán, và thoát khỏi gánh nặng lịch sử
Những gì chúng ta làm chỉ là trát vữa lên trên các sai lầm nền tảng và sự không tương thích, chứ chưa giải quyết được chúng. React không giải quyết được thực tế rằng HTML không được thiết kế như một hộp công cụ UI. Next.js không giải quyết được thực tế rằng JavaScript đầy rẫy những sai lầm thiết kế khiến nó không thể trở thành một ngôn ngữ an toàn, hợp lý và tử tế. Tailwind không giải quyết được việc CSS được chắp vá đưa vào để trang trí cho thứ markup vốn không được thiết kế cho việc styling
Điều mà LLM đang làm lúc này chỉ là “biết” nỗi kinh hoàng nằm dưới lớp vữa ấy bên trong một mô hình thống kê. Mô hình đó được huấn luyện bằng các ví dụ của một thời đại mà 99% trường hợp chỉ là vá lại các vết nứt của những lớp vữa trước đó
Nếu không đi ra ngoài một tập hợp nhỏ những thực hành tốt tương đối ổn, thì chỉ với vài thư viện nhàm chán nhưng đã được kiểm chứng, bạn vẫn có thể mang lại một trải nghiệm khá tốt
Nhưng một khi bạn bị cuốn vào framework frontend đang thịnh hành hôm nay, hoặc tệ hơn là framework từng thịnh hành hôm qua, hay phải chiều theo những sở thích kỳ quặc của một dev khác chỉ khăng khăng một cách làm nhất định, hoặc bắt đầu xử lý những màn hack “thiên tài” được dán bằng hy vọng và băng keo, thì độ phức tạp và cách các thành phần tương tác sẽ tăng theo cấp số nhân
Tôi đã sống qua thời đó. JavaScript thuần chỉ dành cho IE6 bị thay bằng jQuery đầy lỗi, rồi sau đó là các ứng dụng một trang Angular không thể bảo trì, rồi tiếp theo nữa là những codebase React quái vật
Thực tế còn nhiều hơn thế rất nhiều
Tôi đã gặp quá nhiều người đến phỏng vấn tự nhận là chuyên gia Next.js nhưng ngoài đó ra thì không làm được gì. Đó không phải kỹ năng, mà chỉ là kiến thức, và giờ thì nó có đầy miễn phí khắp nơi
Chỉ vì một thứ không được một ủy ban thiết kế hoàn hảo ngay từ đầu không có nghĩa là bạn có thể quên sạch mọi thứ, gập sách lại rồi để máy tính toán hộ
Tôi cũng đang làm theo cách sau nên biết nó sai ở đâu, nhưng không đến mức bị lừa để tạo ra một đống hỗn độn không thể bảo trì. Mỗi khi các agent đi chệch hướng, kỹ năng frontend của tôi lại thực sự phát huy tác dụng
Câu kiểu như “frontend từng là một kỹ năng chuyên môn hóa cao đòi hỏi phải hiểu HTML có ngữ nghĩa, CSS, khác biệt giữa các trình duyệt, khả năng truy cập, nâng cấp dần, hiệu năng mạng, thiết kế giao diện, thử nghiệm người dùng, v.v.” hẳn sẽ nghe khá buồn cười với thế hệ frontend developer trước đó, tức các lập trình viên C/C++
Web từng được xem là thứ hạ thấp đáng kể rào cản gia nhập và làm mất tính tay nghề của kỹ thuật. Có lẽ các lập trình viên assembly cũng từng nghĩ tương tự về các lập trình viên C/C++
Nhưng tất cả các tầng đều sai. Mỗi tầng đều được xây trên lớp trừu tượng của tầng bên dưới. Nếu đi xuống tận vật lý và toán học, bạn sẽ thấy ngay cả những người theo thuyết tập hợp cũng phải giả định một số tiên đề nào đó. Còn các nhà logic học làm gì thì chẳng ai biết
Lập luận kiểu “thật buồn khi quy trình mới tạo ra kết quả chất lượng thấp hơn, mà có vẻ nhiều người chẳng quan tâm” dường như dựa trên giả định rằng trước AI, phần lớn công việc này được thực hiện bởi những người thợ lành nghề tận tâm với chất lượng
Bất kỳ ai từng thực sự làm việc trong ngành và đủ thành thật đều biết thực tế không phải vậy. Có rất nhiều thứ dưới mức tầm thường
Ngoài ra, tùy bạn định nghĩa “chất lượng” thế nào, cũng khó chắc rằng kết quả do AI tạo ra thực sự kém hơn. AI có thể tạo ra sự đồng dạng khó chịu, nhưng đồng thời cũng tạo ra khá nhiều kết quả dùng được vì các tập quán mà mô hình học được, thích hay không, vẫn “hoạt động” đối với đa số người dùng cuối
Từ trước đã có rất nhiều áp lực phải chỉ làm mức tối thiểu đáp ứng yêu cầu rồi tuyên bố là thành công. Giờ thì có cảm giác áp lực đó đã trở nên không thể chịu nổi
Tuy vậy, tôi đồng ý rằng điều đó đã biến mất từ trước cả khi AI xuất hiện
Nếu nói về chất lượng thấp thì thời đó mới là thứ phổ biến hơn
Gần đây tôi cũng đã có suy nghĩ tương tự
Tôi đã gần như không làm frontend trong ít nhất 10 năm, nhưng cũng đủ lớn tuổi để nhớ thời cuối những năm 2000 khi đột nhiên ai cũng bắt đầu dùng framework thay vì tự tay làm web GUI, và những người vẫn còn tự viết HTML/CSS/JS cùng truy vấn cơ sở dữ liệu thì bị chế giễu. Tin tuyển dụng cũng bất ngờ chuyển từ yêu cầu PHP/HTML/CSS/SQL/JS sang Ruby on Rails, Django, Spring, GWT, rồi sau đó là Angular
Cảm giác này kỳ lạ là lại rất quen thuộc với hiện tại. Khi đó, ngay cả khi không có kiến thức sâu, bạn vẫn có thể tạo ra một ứng dụng web chạy được chỉ trong vài phút, và nó trông như phép màu. Sau đó thì chỉ lướt tài liệu qua loa, tìm kiếm rồi tùy biến trong framework, cho đến một lúc nào đó không thể làm tiếp nữa. Vì hoàn toàn không hiểu bên trong nó vận hành thế nào. Giống như webapp kiểu vibe coding, những webapp framework tiêu chuẩn được chắp vá trong một buổi chiều có thể nhận ra từ rất xa, nhưng lại gây ấn tượng mạnh với các quản lý
Điều thú vị là các lập trình viên nói về mô hình tuyến đầu mà họ chủ yếu dùng theo cách khá giống với cách các lập trình viên GUI 15~20 năm trước nói về framework web mà họ yêu thích. Họ nhân cách hóa công cụ, thậm chí đồng nhất mình với nó, rồi thất vọng vì ở phiên bản X thì làm được mà lên X.1 lại tệ đi, và cứ lặp lại những câu như “giờ tôi phát triển nhanh gấp 10 lần”, “tôi sẽ lại tự viết XYZ bằng tay”
Một GUI tự chế mà không ai ngoài bạn biết xử lý thì cũng chẳng phải lợi thế
Cá nhân tôi không thích những thứ tạo cảm giác quá “to lớn” như Nuxt/Next, nhưng lại thích Vue. Tuy vậy giờ tôi muốn loại bỏ phần lớn JavaScript, nên định đi theo các giải pháp kiểu HTMX hay Alpine cùng với template phía server
Cá nhân tôi thấy càng ít công nghệ phải dùng càng tốt. Trước đây cũng từng có thời webapp đã nhét đủ thứ vô ích vào bên trong trước cả khi thêm một dòng mã tùy chỉnh
Năm 2004 tôi cũng từng làm một site theo cách cơ bản là bỏ file txt vào cây thư mục rồi để PHP chèn chúng vào HTML, chỉ là thêm thẻ thay vì xuống dòng. Khi đó phương án thay thế là các hệ quản trị nội dung nặng nề
Tôi đến với Django sau khi trải qua hai framework PHP kinh khủng do các lead developer ở chỗ làm tạo ra, nên những framework như Django là một bước chuyển dần dần hơn và dễ chịu hơn nhiều
Dĩ nhiên nếu tiếp tục đẩy xa hơn, kiểu thêm quản lý phiên bản vào object, thì mọi thứ trở nên cực kỳ rắc rối, không còn đảm bảo hoạt động và cũng không biết sửa thế nào nữa
Dù vậy, bản thân thái độ thì có vẻ vẫn giống bây giờ
Chúng ta đang ở trong ngành phần mềm. Cốt lõi của ngành này là tự động hóa những công việc có tính lặp lại rất cao
Các dự án frontend có tính lặp lại rất cao, và giờ AI làm thay việc đó. Đó là điều tuyệt vời, và nó giải phóng rất nhiều thời gian để làm những thứ thú vị hơn
Việc một kỹ năng không còn quá liên quan bị mất tính chuyên môn hóa đã là chuyện diễn ra liên tục trong ngành kể từ khi máy tính được phát minh. Vì vấn đề đó đã được giải quyết, bằng AI hay bằng cách nào khác
Cứ bước tiếp và học kỹ năng mới thôi. Thực tế thì dùng AI hiệu quả cũng là một kỹ năng mà một số người thấy khó. Mọi thứ vẫn không tự nhiên mà được tạo ra. Nếu đưa prompt đúng thì có thể làm được, nhưng bạn có thực sự đang prompt đúng không? Công cụ có làm đúng điều bạn yêu cầu không? Làm sao bạn biết được? Bạn đã kiểm tra chưa? Tôi cũng đang dành một lượng thời gian khổng lồ để prompt cho AI, và rõ ràng là đang tiến bộ lên, nhưng nó vẫn gần như là một công việc toàn thời gian
Khoảng 10 năm nữa, chúng ta sẽ nhìn lại và thấy cách này là một cách làm phần mềm cực kỳ kém hiệu quả. Công cụ sẽ tốt hơn và AI sẽ tự chủ hơn. Nếu bạn đang dành cả ngày để lặp đi lặp lại cùng một prompt, thì ai đó hoặc thứ gì đó cũng sẽ phải tự động hóa luôn việc đó
Sự bất mãn ở đây là việc tự động hóa đó có nguy cơ mã hóa những thứ không mong muốn
Thế giới cần nhiều phần mềm hơn rất nhiều so với những gì chúng ta có thể làm ra lúc này
Đây là một quan điểm tệ đến mức tôi còn không biết phải bắt đầu phản bác từ đâu. Chẳng lẽ ý là mọi UI đều có nút bấm nên đó là thứ lặp lại sao?
Nếu mọi người thật sự tin như vậy, thì cũng dễ hiểu vì sao UX đã tệ đi từ thập niên 90 và còn tệ hơn nữa về sau
AI coding rất hữu ích để tạo prototype cho sản phẩm, nhưng đồng thời cũng sinh ra những sản phẩm mà nhìn từ xa cũng thấy rõ là do AI làm
Vừa rồi cũng có một startup demo ứng dụng, và app đó có đúng kiểu cảm giác UI vibe coding
Phản hồi họ nhận được thì lạnh lùng nhưng chính xác. Đại ý là: “Khá ổn đấy, nhưng trông quá rõ là làm bằng AI, mà nếu vậy thì những người khác cũng có thể dùng AI làm ra thứ họ muốn rất nhanh, nên thứ bạn định bán không còn nhiều giá trị”
Nhưng phần lớn mọi người thậm chí còn không bỏ ra mức quan tâm cơ bản đó
Các góc bo tròn vẫn là một xu hướng bất tận, và dường như mọi thứ chưa được định nghĩa rõ ràng đều bị lây nhiễm theo hình dạng đó
Một nhà đầu tư mạo hiểm giỏi sẽ không đưa ra kiểu phản hồi vô nghĩa như vậy. Tốt thì là tốt thôi, nó có được làm bằng AI hay không thì có gì quan trọng? Nếu là cùng chất lượng sản phẩm mà không lộ ra kiểu vibe coding thì lại chấp nhận được sao? Chỉ những người phản đối AI vì ý thức hệ mới bận tâm chuyện đó thôi
Thỉnh thoảng tôi có cảm giác những kỹ thuật dùng HTML để tạo giao diện người dùng phức tạp mà không cần AJAX hay thao tác DOM vào đầu những năm 2000 đã gần như biến mất, giống như kỹ thuật xây kim tự tháp vậy
Các lập trình viên full-stack trẻ có phần bị “phi kỹ năng hóa”, đến mức chẳng hạn có nhiều người nghĩ rằng muốn kiểm tra hợp lệ form thì cần JavaScript
Một khi đã dùng AJAX và bắt đầu thao tác DOM, độ phức tạp của giao tiếp bất đồng bộ gần như tất yếu sẽ dẫn tới một thứ có quy mô tương tự React. Dù có thể viết kiểu
document.title="A new title"và không cần kéo thêm gì vào, nếu chỉ xem frontend là “cập nhật UI khi dữ liệu từ server tới” thì với ứng dụng phức tạp vẫn phải cập nhật nhiều phần của UI, và đến một lúc nào đó bạn sẽ tự tạo ra thứ như lớp giao tiếp hay bus quản lý trạng thái. Có thể làm theo cách khác không? Tất nhiên là cóNếu hệ sinh thái React có vấn đề thì không phải vì nó tạo ra các lớp trừu tượng chồng lên lớp trừu tượng khác, mà vì các lớp trừu tượng đó bị rò rỉ. Nếu chỉ làm thứ rất đơn giản và không quá quan tâm đến hình thức, bạn có thể dùng Bootstrap hay MUI mà không cần hiểu CSS. Nhưng để làm ra sản phẩm ở mức chuyên nghiệp đem tới cho khách hàng, bạn phải hiểu HTML, CSS, JS và mọi framework dùng trong dự án
Phần lớn những người chỉ trích React thực ra không hiểu React giải quyết vấn đề gì. Nếu bạn cho họ xem mã nguồn của một webapp đủ phức tạp nhưng không phụ thuộc React, bạn vẫn có thể chỉ ra trong đó một thứ na ná React do họ tự làm
Tôi không đồng ý rằng việc vận hành một ứng dụng frontend dùng server-side rendering, lazy loading, v.v. của NextJS lại “dễ” hơn thời chỉ dùng HTML, JS và CSS
Mức độ phức tạp và kỳ vọng của người dùng giờ đã ở một nơi hoàn toàn khác
Hơn nữa, số kỹ sư lành nghề đã nhiều hơn cỡ 1000 lần, và bạn phải cạnh tranh với thị trường toàn cầu. Đầu những năm 2000 gần như không có cạnh tranh. Kỹ năng của người lao động nhìn chung chỉ có tương quan khá lỏng với mức mà thị trường đòi hỏi, còn bây giờ thì mức cạnh tranh là cực kỳ khốc liệt