Nolan Lawson: Khi AI làm thay đổi cuộc chơi phát triển Frontend

Rất nhiều nhà giáo dục mà tôi ngưỡng mộ trong lĩnh vực frontend web dường như đang rút lui hoặc giảm bớt công việc của họ: có thể kể đến Axel Rauschmayer, Salma Alam-Naylor, Josh W. Comeau. Những tên tuổi nổi tiếng khác như Kent C. Dodds, Addy Osmani, Rachel Nabors và Lydia Hallie cũng đã chuyển hướng từ việc nói về phát triển frontend sang nói về… chà, bạn cứ thử đoán xem.

Tôi chưa bao giờ kiếm sống bằng việc nói về web dev, nhưng tôi có blog này và tôi đã từng tham gia các buổi diễn thuyết tại hội thảo cũng như các podcast về những chủ đề mà tôi tâm đắc. Ví dụ gần đây, niềm đam mê của tôi là giải thích cặn kẽ về hiệu năng CSS: cách shadow DOM hoạt động, cách công cụ xử lý style của trình duyệt vận hành, những cái bẫy của CSS-in-JS, v.v.

Chỉ để cho vui, tôi quyết định hỏi Claude Sonnet xem nó sẽ xử lý một Chrome trace có chi phí “Style Calculation” cao như thế nào. Đây là một trong những câu đố trí tuệ yêu thích của tôi, vì đó là kiểu vấn đề mà tôi thấy các web dev – ngay cả những người dày dạn kinh nghiệm! – vẫn vấp phải hết lần này đến lần khác. Claude đã đưa ra một câu trả lời hoàn toàn đáng nể:

Prompt: Trả lời mà không cần tìm kiếm trên internet: bạn đang xem một Chrome trace và thấy các khoảng thời gian lặp đi lặp lại với chi phí Style cao nhưng chi phí Layout tương đối thấp. Bạn sẽ tìm kiếm những gì trong webapp để tối ưu hóa? Bạn sẽ đo lường điều gì tiếp theo?

Chi phí “Style” thực sự đại diện cho điều gì

Giai đoạn Style (Recalculate Style) là nơi trình duyệt đối chiếu các bộ chọn CSS với DOM và tính toán style cuối cùng cho từng phần tử bị ảnh hưởng. Nó rất tốn kém bất kể có thứ gì thực sự di chuyển hay thay đổi kích thước hay không (đó là công việc của Layout). Vì vậy, nếu Style cao nhưng Layout thấp, có khả năng bạn đang phải trả giá cho việc đối chiếu/vô hiệu hóa bộ chọn trên nhiều phần tử, chứ không phải do hình học phức tạp.

Những điều cần tìm kiếm trong webapp

1. Độ phức tạp và số lượng bộ chọn

2. Phạm vi vô hiệu hóa (Invalidation scope) — đây thường là vấn đề lớn nhất

3. Tần suất/sự khuếch đại

4. Sự lan truyền thuộc tính kế thừa/tính toán

5. Shadow DOM / ranh giới thành phần

Những điều cần đo lường tiếp theo

Các bản sửa lỗi điển hình sau khi tìm ra nguyên nhân

Ngày nay, khi gặp một trang web tải chậm, ngay cả với tư cách là người đã viết về hiệu năng trình duyệt trong nhiều năm và từng làm việc trong một nhóm hiệu năng trình duyệt, tôi có lẽ sẽ chỉ ném một Chrome trace vào Claude Code và nhờ nó gợi ý cải tiến. Thực tế, tôi đã làm chính xác điều này trong công việc hàng ngày và thu được kết quả tốt.

Tương lai của frontend

Vậy điều này để lại gì cho giáo dục frontend? Rõ ràng là không mấy khả quan; tôi ước mình có những câu trả lời truyền cảm hứng hơn cho những người (giống như tôi) từng tìm thấy nhiều sự thỏa mãn khi cố gắng nâng cao tiêu chuẩn cho các lập trình viên frontend ở khắp mọi nơi. Tuy nhiên, tôi có một vài dự đoán và tôi nghĩ vấn đề này vẫn đáng để suy ngẫm.

Câu hỏi cốt lõi là sự phát triển frontend sẽ đi về đâu trong kỷ nguyên mới này. Đáng buồn thay, tôi cảm thấy có nhiều xu hướng đang chống lại việc tăng cường đầu tư vào kiến thức frontend:

Frontend ít rủi ro hơn khi giao cho một agent. Nếu bạn sử dụng agent để viết một bản di chuyển cơ sở dữ liệu (database migration), bạn có thể muốn trải qua vài vòng đánh giá mã nguồn AI, tự mình kiểm tra kỹ lưỡng, chạy trên môi trường staging trước, v.v. Tuy nhiên, nếu bạn viết một React component bằng agent, thì rủi ro khi "yolo" nó vào production (thường là) thấp hơn nhiều.

Lưu ý rằng tôi không nói là không có rủi ro: agent có thể làm hỏng khả năng truy cập (accessibility), gây ra vòng lặp vô hạn chặn người dùng, v.v. Nhưng nhìn chung, mã frontend phù hợp để thay thế và ít tồn tại lâu dài hơn các loại mã khác. Vì vậy, tôi kỳ vọng nhiều lập trình viên AI sẽ cảm thấy thoải mái khi để agent tự xử lý mà không cần giám sát (dù tốt hay xấu).

DevExp (trải nghiệm lập trình viên) đang trở nên ít quan trọng hơn về tổng thể. Rất nhiều cuộc thảo luận trước thời LLM trong không gian frontend là về công thái học so với kết quả: bài viết “The ‘developer experience’ bait-and-switch” của Alex Russell là một ví dụ tuyệt vời. Một ví dụ khác, Svelte và Solid từ lâu đã lập luận rằng công thái học của họ dẫn đến kết quả tốt hơn React: ít mã hơn, hiệu năng tốt hơn, v.v.

Trong khi đó, Cursor và Viget đã viết blog về việc chuyển đổi codebase của họ từ Solid và Lit sang React. Vì việc viết lại mã ít tốn kém hơn với các agent, điều này có thể hơi đáng ngạc nhiên: tại sao không chuyển sang framework có hiệu năng cao hơn/ít dài dòng hơn? Câu trả lời (rõ ràng trong trường hợp của Cursor, và tôi nghi ngờ cả Viget) tất nhiên là: “các agent biết React”. Dù tốt hay xấu, React đang chiếm ưu thế quá mức trong các trọng số huấn luyện, và “trải nghiệm agent” đang bắt đầu quan trọng hơn trải nghiệm lập trình viên.

Các tiêu chuẩn sẽ bắt kịp. Tôi đã rời xa không gian tiêu chuẩn web được vài năm nay, nên đây hoàn toàn là suy đoán của cá nhân tôi. Nhưng tôi tưởng tượng rằng rất nhiều nỗ lực nhằm cải thiện công thái học khi xây dựng trang web – các viết tắt CSS tốt hơn, cú pháp JavaScript ngắn gọn hơn, v.v. – sẽ bị coi là ít quan trọng hơn so với những thứ thực sự tạo ra sự khác biệt về hiệu năng, khả năng, v.v. Suy cho cùng, đối với một agent, việc viết 3 dòng CSS thay vì 1 dòng cũng không khác biệt là mấy, và dù sao thì việc sử dụng cú pháp mới hơn có khi còn khó hơn vì bạn phải hướng dẫn agent về những thứ không có trong trọng số huấn luyện của nó.

Theo một cách nào đó, sự thay đổi này có thể đã diễn ra từ trước. Tôi nhớ vài năm trước tại TPAC, rất lâu trước khi cơn sốt lập trình AI bùng nổ, tôi đã nói với một người trong nhóm Chrome rằng tôi đang làm việc về các tiêu chuẩn web component. Họ trả lời rằng họ không quan tâm đến điều đó, vì các API đó chỉ ảnh hưởng đến trải nghiệm lập trình viên chứ không thực sự làm cho trình duyệt có khả năng mạnh mẽ hơn (ví dụ như Project Fugu). Điều đó đã in sâu vào tâm trí tôi vì đó là một quan điểm hay: các API như shadow DOM và custom elements không mang lại cho các web developer bất kỳ siêu năng lực mới nào; chúng chỉ thay đổi nơi và cách mã nguồn được tạo ra. Tôi kỳ vọng những thứ như vậy sẽ rời khỏi tâm điểm khi lập trình AI chiếm ưu thế.

Điều này không có nghĩa là các tiêu chuẩn sẽ biến mất khỏi các chủ đề mà một frontend dev cần theo kịp, nhưng tôi tưởng tượng nó sẽ ít tập trung vào “sử dụng cú pháp mới hơn này” (một nguồn tài liệu bất tận cho các bài thuyết trình hội thảo và bài báo) mà nhiều hơn vào “đây là những khả năng mới nổi”. Và tôi dự đoán nhóm thứ hai sẽ nhỏ hơn nhiều so với nhóm thứ nhất, vì chúng có xu hướng gây tranh cãi hơn đối với các cơ quan tiêu chuẩn và số lượng tính năng để khai thác cũng ít hơn.

Giáo dục frontend sẽ đi về đâu?

Vậy lĩnh vực giáo dục frontend có thể thích nghi với tương lai khắc nghiệt này như thế nào? Để tránh cảm giác hoàn toàn ảm đạm, đây là một vài hướng đi tích cực mà tôi nghĩ nó có thể hướng tới.

Trước hết, các agent vẫn cần được giáo dục về bức tranh toàn cảnh. Các agent và công cụ hỗ trợ dường như rất thích viết React và đặc biệt là SPA, nhưng SPA không phải là câu trả lời cho mọi thứ. Bạn có thể đốt rất nhiều token để bắt một agent viết một SPA lớn phức tạp cho trang web marketing của mình, rồi sau đó phải sửa tất cả các lỗi về nút quay lại, trạng thái focus, hiệu năng, v.v., hoặc bạn chỉ cần chọn một framework MPA như Astro hoặc Eleventy là xong. Có lẽ các framework này sẽ khó hơn một chút để các agent làm việc cùng (đặc biệt là Astro vì nó trông giống React nhưng không phải là React), nhưng tôi đoán rằng vì bạn viết ít hơn khoảng 50% mã nguồn tổng thể nên điều đó cũng không quan trọng.

Thứ hai, việc tạo ra các trang web hoạt động tốt cho các agent có lẽ sẽ là một nỗ lực hiệu quả trong tương lai gần. is-agentic của Vercel là một ví dụ điển hình. Trớ trêu thay, điều này quay trở lại với những nguyên tắc cơ bản tốt mà các trang web hướng tới công chúng đáng lẽ phải thực hiện ngay từ đầu: nội dung được server-rendered, khả năng truy cập phù hợp, tốc độ trang, v.v. Nhưng nếu việc gắn nhãn “AI” vào đó là thứ khiến mọi người quan tâm, thì này, tôi hoàn toàn ủng hộ.

Lưu ý rằng tôi hơi ít lạc quan hơn về điểm thứ hai này, vì tôi không chắc liệu web có còn tồn tại ở dạng hiện tại khi các agent trở nên phổ biến hơn hay không. Nếu tôi muốn tìm hiểu chi phí bay từ Seattle đến Paris, tôi thà hỏi một agent còn hơn là nhấp qua một loạt các nút gây khó chịu trên một trang web tải chậm. Lý do duy nhất tôi không thể làm vậy là vì các trang web này chặn bot một cách rõ ràng, hoặc họ không cung cấp MCP, nhưng tôi chắc chắn có nhiều startup đang rất nóng lòng giải quyết vấn đề đó. Vì vậy, tôi không chắc tình hình hiện tại bền vững đến mức nào.

Thứ ba, chúng ta có thể cung cấp dịch vụ tư vấn cho những "quái vật" được tạo ra bằng vibe-coding. Một lượng lớn mã frontend do AI tạo ra đang được tung ra ngay lúc này, và một số trong đó (để dùng một thuật ngữ của Claude) chắc chắn sẽ trở thành “trụ cột chịu lực”. Nếu các trang web đó chậm, không tuân thủ tiêu chuẩn và đầy lỗ hổng bảo mật, thì việc chỉ hỏi agent “làm ơn sửa trang web của tôi” có thể là không đủ. Có thể có một cơ hội ở đây cho chuyên môn thực sự, đặc biệt là nếu có tiền bạc liên quan và kiến thức của người vibe-coder về phát triển web không vượt quá mức “trang web là các ứng dụng được lưu trữ trên internet”.

(Tôi thừa nhận đây là điểm yếu nhất trong ba điểm của tôi, vì tôi hoàn toàn có thể tưởng tượng thế hệ tiếp theo của các ứng dụng web “tự chữa lành” sẽ vượt qua chuyên gia trung bình vào năm 2027 hoặc 2028. Nhưng hiện tại: vâng, chuyên môn vẫn quan trọng.)

Kết luận

Mục đích của bài viết này không phải để làm cho bản thân tôi cảm thấy tốt hơn, hay để nhảy múa trên nấm mồ của tất cả những sự nghiệp đã bị đảo lộn bởi sự bùng nổ AI gần đây. Tôi là một người có bản tính u sầu, và bài viết này là cách tôi cho phép mình đắm chìm trong sự u sầu đó. Tôi không lấy làm vui vẻ gì khi nhận thấy khối lượng kiến thức khổng lồ mà tôi đã tích lũy qua nhiều năm đã trở nên gần như lỗi thời, tôi cũng không vui khi thấy điều tương tự xảy ra với những đồng nghiệp có trình độ cao hơn tôi nhiều. Nhưng giả vờ như điều đó không xảy ra cũng không phải là một chiến lược hợp lý.

Có một tâm trạng trong một số blog tôi đọc những ngày này theo kiểu “Tôi quá mệt mỏi khi nói về AI” hoặc “Làm ơn đừng bao giờ nhắc đến AI với tôi nữa”. Tôi chắc rằng một phần trong đó là kiểu thái độ chán chường, tỏ ra thượng đẳng mà người ta cảm thấy dễ chịu khi đeo như một huy hiệu danh dự. Nhưng tôi nghĩ phần lớn nó cũng đến từ nỗi sợ hãi thực sự. Thật đáng sợ khi thừa nhận rằng bạn không biết điều gì sẽ xảy ra trong một năm tới. Thật bất ổn khi tưởng tượng sự nghiệp của mình đang đi theo một quỹ đạo nhất định, bình yên cập bến nghỉ hưu, rồi lại thấy mọi thứ bị đảo lộn chỉ vài năm trước khi đạt được mục tiêu.

Phép ẩn dụ mà tôi đã sử dụng là một tiểu hành tinh vừa va vào trái đất, và chúng ta vẫn đang khảo sát đống đổ nát. Thật khó để dự đoán điều gì sẽ xảy ra sau khi bụi lắng xuống (chưa nói đến việc loài gặm nhấm nhỏ bé nào sẽ mở ra Kỷ nguyên Động vật có vú!), nhưng việc hoàn toàn phớt lờ miệng hố va chạm dường như là kiểu phủ nhận tồi tệ nhất. Một phép ẩn dụ khác là covid: khi covid ập đến, tôi không nhớ mình đã nghĩ “Ôi, tôi quá mệt mỏi khi nói về covid” – thay vào đó, tôi muốn tìm hiểu mọi thứ có thể về virus, dịch tễ học, đeo khẩu trang, v.v. Hóa ra đó là một ý tưởng hay, vì covid sẽ thống trị cuộc sống của tôi trong vài năm tới (đến lúc đó thì vâng, cuối cùng tôi cũng đã mệt mỏi khi nói về nó!).

Tôi khó mà có quả cầu pha lê để tiên đoán, nhưng bài viết này là nỗ lực của tôi để suy ngẫm về nơi mà lĩnh vực tôi yêu quý nhất có thể sẽ đi về đâu trong tương lai. Tôi thừa nhận rằng mình ít còn gắn bó với nó hơn những ngày này: tôi đã rời xa các tiêu chuẩn web, tôi thậm chí không làm việc về frontend ở công việc hiện tại, và blog của tôi chủ yếu là những lời than vãn về AI thay vì thực đơn quen thuộc của tôi về trình duyệt, hiệu năng, khả năng truy cập, v.v. Dù vậy, tôi vẫn dành nhiều tình yêu và sự tôn trọng cho lĩnh vực frontend, và tôi quan tâm đến những gì sẽ xảy ra với nó trong tương lai. Nó có thể trở nên không thể nhận ra chỉ trong vài năm nữa, nhưng ít nhất, tôi hy vọng các đồng nghiệp của mình tìm ra cách để điều hướng tất cả những thay đổi này và phát triển mạnh mẽ trong thế giới mới kỳ lạ này.