Guồng chạy của frontend
(polotek.net)- Với các sản phẩm càng tồn tại lâu, thời gian và năng lượng dành cho tranh luận viết lại sẽ trở thành chi phí lớn hơn so với việc chọn framework frontend
- Nếu sản phẩm vẫn sống sau 5 năm thì đó là thành công, nhưng trong thời gian đó framework đã chọn rất có thể sẽ trở nên lỗi thời hoặc thay đổi lớn thành một phiên bản mới cùng tên
- Các đội sản phẩm giỏi hơn không chuyển sang công cụ mới, mà hiểu sâu framework hiện tại, nâng cao độ thành thạo đủ để công cụ không cản trở tiến độ công việc
- Để giảm chi phí dài hạn, lựa chọn bám sát nền tảng web và các công nghệ web cốt lõi hơn, thay vì các lớp trừu tượng phức tạp, có thể là một thỏa hiệp kinh doanh thực tế
- Sự phức tạp của hệ sinh thái frontend gây khó khăn cho cả lập trình viên mới vào nghề lẫn đội tuyển dụng, và những lập trình viên yếu về nền tảng web cơ bản sẽ dễ bị tổn thương hơn trước lần thay đổi stack tiếp theo
Khó thoát khỏi guồng chạy bằng cách viết lại
- Nhiều đội frontend tin rằng viết lại sẽ đưa họ đến trạng thái tốt hơn, nhưng với sản phẩm tồn tại lâu dài, bản thân việc chọn framework không phải là quyết định kỹ thuật quan trọng nhất
- Nếu sản phẩm tồn tại hơn 5 năm, có thể xem đó là thành công, nhưng trong khoảng thời gian đó framework được chọn có thể trở nên lỗi thời
- Cộng đồng frontend luôn vận hành xoay quanh sự thay đổi, và khả năng điều này thay đổi trong tương lai gần là thấp
- Ngay cả các framework phổ biến còn sống sót cũng có thể thay đổi hoàn toàn bên trong, và về thực chất có thể được viết lại dưới một số phiên bản mới
- Việc đội ngũ cần tập trung không phải là chạy theo những công cụ mới và hào nhoáng, mà là nắm vững đủ framework đang dùng hiện tại
- Cần có mức độ hiểu biết và thành thạo đủ để công cụ không trở thành rào cản cho tiến độ công việc
- Kỳ vọng rằng chuyển sang công cụ thay thế sẽ giải quyết vấn đề gần như là một cái bẫy
Càng gần nền tảng web, chi phí dài hạn càng giảm
- Nếu một công ty muốn giảm chi phí do công nghệ frontend thường xuyên lỗi thời, họ có thể cân nhắc hướng đi gần hơn với nền tảng web
- Cần giảm bớt các lớp trừu tượng phức tạp và học lại xem web thực sự có thể làm gì
- Điều này không có nghĩa đây là đáp án cho mọi vấn đề, hay mặc nhiên là tốt hơn
- Nó có thể là một thỏa hiệp kinh doanh giúp mang lại nhiều giá trị hơn và giảm chi phí về dài hạn
- Ở gần các công nghệ web cốt lõi sẽ giúp bạn ít bị chi phối hơn bởi lập luận rằng phải viết lại hàng triệu dòng code thì các kỹ sư giỏi trong tương lai mới có thể làm việc được
- Với từng kỹ sư, việc hiểu sâu các công nghệ web cốt lõi cũng có lợi hơn cho giá trị thị trường dài hạn so với việc liên tục chạy theo một framework cụ thể
- Có thể phải từ bỏ một phần khả năng được tuyển dụng trong ngắn hạn
- Nhưng có lợi hơn cho sự bền vững của sự nghiệp so với cách cố học mọi công nghệ phổ biến
- Biết một công nghệ cụ thể không có nghĩa là sẽ được bảo vệ trước các thực tế như thị trường xấu đi
Sở thích framework và chi phí đội ngũ
- Những kỹ sư có sở thích mạnh về framework nên phản ánh tiêu chí đó vào điều kiện tìm việc
- Nếu vào một đội đã dùng một framework cụ thể rồi cố chuyển họ sang framework mình ưa thích, điều đó sẽ làm xáo trộn đội ngũ và tăng chi phí đáng kể
- Sự phức tạp của hệ sinh thái frontend hiện nay là gánh nặng cho cả lập trình viên mới vào nghề lẫn doanh nghiệp
- Lập trình viên mới vào nghề gặp khó khi học đủ kỹ năng để tìm việc, và bị choáng ngợp bởi các công cụ phức tạp
- Doanh nghiệp cảm thấy ngay cả việc tuyển lập trình viên phổ thông cũng khó hơn, và tiêu chuẩn đầu vào cho các vị trí lập trình viên chính thức cũng tăng lên
- Nếu người học hệ sinh thái công nghệ hiện nay không học được nền tảng web cơ bản, họ có thể gặp bất lợi nghiêm trọng khi stack lại thay đổi
- Web là một nền tảng có năng lực và độc đáo để phân phối phần mềm; theo thời gian nó đã tốt hơn và duy trì mức tương thích ngược cao
- Các công cụ nền tảng hiện nay đã đủ tốt, nhưng tầng framework đang vận hành theo cách đi ngược lại thay vì tiếp nhận nền tảng
1 bình luận
Ý kiến Hacker News
Gần đây tôi đã làm việc chuyển hệ thống build của mã frontend từ yarn sang pnpm; bình thường tôi là kỹ sư backend nhưng cũng đã va chạm với phía JS khá nhiều
Điều khó chịu nhất mỗi khi bước vào frontend là cảm giác thật sự mọi thứ đều như đã deprecated. Nếu bạn dùng apollo CLI vào năm 2022 thì nó sẽ nhanh chóng bị deprecated, và bạn phải học một công cụ hoàn toàn khác như graphql-client với cấu hình và tùy chọn khác hẳn. Cuối cùng tôi giữ nguyên cái cũ và chỉ tắt kiểm tra Node engine của pnpm để nó khỏi than phiền. Hễ định nâng cấp bản vá cho một dependency thì chữ ký kiểu có thể vỡ, nên cái đó cũng bị khóa lại, rồi để một TODO trong codebase hy vọng một ngày nào đó ai đó sẽ sửa
Vừa làm cho nó chạy được thì hàng trăm cảnh báo deprecated đã trôi qua trong lúc cài đặt, và ngay khi build xong chỉ muốn bỏ chạy
Việc cả ngành frontend lại chấp nhận thay đổi phá vỡ tương thích và deprecated ở mức này thật sự rất kỳ lạ. Tôi đã làm một dự án Rust lớn gần 4 năm; trong thời gian đó có vài thay đổi nhỏ phá vỡ ở thư viện bên thứ ba, nhưng chỉ đúng một lần có thay đổi lớn buộc phải sửa ứng dụng đáng kể. Trong khi đó JS trông như cứ chưa tới 6 tháng là phải viết lại thứ gì đó
Thế giới frontend tiếp nhận mạng xã hội, YouTube, thậm chí cả Twitch, tích cực hơn nhiều lĩnh vực khác. Những influencer này cần liên tục có chất liệu mới để giữ độ liên quan, nên họ không ngừng đẩy ra những thứ mới có thể biến thành nội dung
Thêm vào đó là văn hóa hội nghị rất sôi động. Các hội nghị frontend và JS giống như một cuộc cạnh tranh lớn để trình bày chủ đề mới đang nổi
Thị trường bán các khóa học frontend cũng rất lớn. Những người làm khóa học cần khiến sếp phê duyệt khóa video giới hạn giá $700 để học xu hướng mới, mà muốn vậy thì họ phải kéo ngành đi xa khỏi những thứ cũ mà ai cũng đã biết. Vì thế họ đẩy mạnh cái mới và biến cái cũ thành deprecated
Một web app nhỏ thuần JS cỡ 5KLOC tôi viết 15 năm trước vẫn đang được khoảng 10 người dùng mỗi ngày mà không cần sửa một dòng nào. Nó thậm chí còn bền hơn cả ứng dụng Win32
Tôi cho rằng phần lớn churn của frontend đơn giản là một dạng thất bại về chính trị và tổ chức
Khi tôi bắt đầu từ thời pure JS/jQuery, quản lý dependency thực chất là chép các file
.jsvào thư mụcvendor/. Sau đó nodejs/npm xuất hiện, rồi ở frontend còn từng dùng bower trước cả npm, và bỗng nhiên lời khuyên tiêu chuẩn là đừng tự làm mà hãy tải module vềNhưng ngay từ hồi đó cũng đã có nhiều người nghi ngờ liệu có đúng khi không tự sở hữu hàng nghìn dòng mã ẩn bên dưới, mà lại giao cho những tình nguyện viên làm mã nguồn mở vì vui
Ngay cả bây giờ, nếu muốn duy trì dự án lâu dài, bạn vẫn có thể tránh để phần vô hình phình quá to. Với những vấn đề nhỏ, có thể xử lý theo kiểu “thư viện này tôi chỉ cần đúng một hàm, vậy đừng phụ thuộc cả thư viện, hãy chép riêng hàm đó vào codebase và thêm test”
Vì vậy tôi nghĩ đây không phải vấn đề của riêng JavaScript mà là vấn đề con người và quy trình. Có rất nhiều lập trình viên JS không gặp chuyện này, nhưng một phần lớn của hệ sinh thái thì có
Mỗi ngày có hàng nghìn giờ công bị đốt chỉ để sửa hậu quả của những thay đổi phá vỡ ‘cực kỳ quan trọng’™ kiểu như “Hay đổi
MultiselectDropdownthànhMultiSelectButtonDropdownnhé? Tiện thể thay luôn API bằng cái hoàn toàn mới!”Gần như không có văn hóa hiểu được cái giá khổng lồ của API không tương thích. Điều này đặc biệt gây bực bội vì tôi đã làm Go 10 năm. Go có lời hứa về tương thích ngược, và dường như điều đó cũng ảnh hưởng tới thái độ của những người phát triển thư viện Go đối với tương thích và thay đổi phá vỡ. Việc mã viết từ 10 năm trước vẫn compile và chạy nguyên vẹn trên Go mới nhất là một trải nghiệm thực sự tuyệt vời
Tôi từng chuyển sang Flutter để thoát khỏi địa ngục JS/web này, và nó khá hợp; tôi có thể quên đi phần lớn sự phức tạp ngẫu nhiên của web stack. Nhưng văn hóa “phá package cũng không sao” cũng đang ngấm vào hệ sinh thái Dart, và điều đó cực kỳ khó chịu
Thành thật mà nói tôi thấy nó còn tệ hơn frontend rất nhiều. Frontend ít ra còn có TypeScript và đặc tính ngôn ngữ giúp giới hạn mức độ thiệt hại ở mức tương đối sane. Trong Python thì thật sự theo nghĩa đen là làm gì cũng được, nên tác giả thư viện cũng đúng nghĩa đen là làm gì cũng làm. Muốn đổi cách import module thì cứ đổi, muốn dùng metaclass để phá tan mọi giả định về cách class hoạt động thì cũng làm được. Ngay cả khi nghĩ static type sẽ giúp, những thứ nhỏ như
Partialcũng không có, và cũng không thể khẳng định tĩnh rằng hai object có cùng kiểu hay khôngThấy người ta than phiền vì thư viện thay đổi mà buồn cười. Quá trình chuyển từ Python 2 sang 3 kinh khủng đến mức ở công ty cũ của tôi có một monolith Python 100 triệu dòng hoàn toàn không có kế hoạch nâng cấp lên Python 3. Đi từ SqlAlchemy 1 lên 2 là một cuộc di trú 8 bước và thực chất là viết lại toàn bộ; chỉ cần vỡ một chỗ là cả site sập. Vậy mà người ta lại than vì React thêm hooks theo kiểu tùy chọn
Điều kỳ lạ là trên internet đầy rẫy các bài viết về “máy chạy bộ frontend”, nhưng lại hiếm thấy những bài than phiền về phía ngược lại
Về ý kiến “nếu là kỹ sư, càng hiểu sâu các công nghệ web cốt lõi thì theo thời gian càng giữ được giá trị thị trường cao hơn nhiều”, tôi nghĩ mình đủ tư cách để nêu quan điểm vì đã làm frontend gần 20 năm và trải qua nhiều lần thay đổi lớn về mô hình
Việc hiểu hết các công nghệ web cốt lõi chắc chắn giúp trở thành một kỹ sư cân bằng hơn. Nhưng việc đó có khiến bạn trông hấp dẫn hơn trên thị trường tuyển dụng hay không thì tôi khá hoài nghi. Không phải vì kiến thức này không quan trọng, mà vì những người có quyền quyết định tuyển dụng phần lớn chỉ làm pattern matching
Nếu muốn tối đa hóa “giá trị thị trường”, thì vẫn cần rất giỏi React. Nó gần như là tấm vé vào cửa cơ bản; những thứ khác đều tuyệt vời, nhưng nếu thiếu nền tảng đó thì lựa chọn sẽ ít đi. Có thể tác giả bài viết cũng muốn nói theo nghĩa đó, chỉ là tôi đã hiểu sai
Tuy vậy, với các vai trò như tư vấn hoặc hợp đồng thì tôi đồng ý với bình luận gốc. Nếu từng làm việc với những người tuyển dụng hoặc quyết định có mời phỏng vấn ở các công ty tư vấn lớn, bạn sẽ thấy họ gần như tự động loại những ai chưa biết sẵn stack mà họ thích hoặc stack khách hàng hiện tại đang dùng. Các kiến trúc sư kỹ thuật cũng làm vậy, nên đây không chỉ là vấn đề của HR không có nền tảng kỹ thuật. Họ không muốn mất thời gian để ai đó thích nghi với công nghệ, bất kể người đó giỏi đến đâu
Trong những vai trò như vậy, việc luôn bắt kịp cái mới là cực kỳ quan trọng. Nếu không, CV có thể bị loại chỉ vì thiếu buzzword, trước cả khi một kỹ sư kịp đánh giá năng lực của ứng viên
Có thể đây là trường hợp đặc biệt, nhưng việc không biết React chưa bao giờ là vấn đề với tôi. Cách nói “tấm vé vào cửa cơ bản” là hơi quá mạnh
Frontend có một mức trần lương thưởng khá cứng. Khi lên đến một ngưỡng nào đó, bạn sẽ không còn phải xây UI nữa
Phần lớn công ty, kể cả công ty lớn, không quá quan tâm, không kiểm tra, và cũng không tuyển theo các nền tảng cốt lõi. Họ tuyển theo kiểu “giỏi React” hoặc “có nhiều kinh nghiệm với Next.js”
Kiến thức nền tảng rất tuyệt khi bạn xây thứ gì đó từ con số 0, nhưng công ty thực tế hiếm khi làm vậy. Họ thường lấy những giải pháp có sẵn với hệ sinh thái lớn và tài liệu tốt để dùng. Nếu giỏi các thứ đó thì bạn dễ được tuyển hơn nhiều, còn kiến thức nền tảng có thể học trong quá trình làm
Câu “dù chọn framework nào thì 5 năm sau nó cũng obsolete” nghe như một lập luận hơi cũ
Tôi không chủ yếu làm frontend, nhưng cũng không né tránh frontend khi cần, và khoảng 10 năm qua tôi đã dùng React. Dù có một phần xu hướng chuyển sang Svelte, thì đến lúc Svelte vượt React có lẽ nó cũng đã được dùng production đủ lâu rồi. Angular có thể suy yếu vào một lúc nào đó, nhưng nếu tính cả thời Angular1 lẫn Angular2+ thì nó còn lâu đời hơn React
Frontend đúng là thay đổi nhanh, nhưng không đến mức tệ như vậy. Nếu chọn phương án nhàm chán, bạn sẽ có kết quả nhàm chán
Angular1 và 2 khác nhau đến mức gần như không thể so sánh nếu bỏ qua cái tên, và nhiều lập trình viên đã bị cú này làm khổ. Bản thân Angular cũng đang thay đổi khá mạnh. Không nghiêm trọng như lúc chuyển từ v1 sang Angular2, nhưng vẫn đủ lớn để cần tái thích nghi đáng kể. Mọi thứ đang chuyển sang standalone component, cú pháp template mới, signals, v.v.
React cũng tương tự. Sự xuất hiện của functional component và hooks là một chuyển đổi mô hình lớn. Vẫn tương thích, nhưng hai cách làm rất khác nhau
Ở cấp độ mô hình tổng quát hơn cũng thế. Ban đầu tất cả đều là server-side rendering, rồi lao hết tốc lực sang single-page app, rồi lại quay về server-side rendering, nhưng lần này là server-side rendering từng phần có hydration
Khác đến mức có thể xem như framework khác, nên dù lập luận đó cần xét nuance, nó cũng chưa hẳn sai hoàn toàn
Làm việc với nó thật sự rất đơn giản. Tôi tạo một ứng dụng phân bổ cổ phiếu đơn giản, và điều khiến tôi ngạc nhiên nhất là kích thước bundle. Chỉ 9KB sau gzip, nhỏ hơn mọi framework mà tôi biết. Thậm chí còn nhỏ hơn cả htmx, vốn ở mức nào đó gần như “phản-JS”
Framework cũ vẫn có thể chạy trong thời gian rất dài. Chỉ cần vẫn còn người hiểu stack đó và có thể được thuê khi cần để làm việc với nó, thì stack đó chưa obsolete. Có thể gọi là “cũ” hoặc “legacy” thì đúng hơn. Nhưng cho đến ngày không còn ai xử lý được nó nữa, thì nó chưa obsolete
Thật thú vị khi gọi đây là vấn đề của frontend. Đây không phải là vấn đề của frontend mà là vấn đề khi những người mới liên tục tham gia vào một hệ sinh thái khổng lồ
15 năm trước, khi Java ở tuyến đầu của đổi mới, tôi cũng thấy y như vậy. Chỉ trong vài năm đã xuất hiện hàng chục framework và nhiều hệ thống build khác nhau. Sự thay đổi từ React 17 lên 18 nhỏ hơn rất nhiều so với từ Perl 5 sang 6 hay từ Python 2 sang 3
Ở backend, thay vì “hãy dùng framework mới”, người ta nói “hãy dùng ngôn ngữ mới”. Mốt gần đây là viết lại thứ gì đó bằng Rust, còn trước đó đã có Go, Haskell, Scala và F#
Nếu bạn thấy việc chuyển mã frontend từ React sang thứ như Svelte là phiền phức, hãy thử viết lại một ứng dụng VB 6. Chưa kể những thứ như RPC mà dữ liệu nằm ngay trong code
Không phải là tôi nói sự bất ổn trong thực hành kỹ thuật không phải vấn đề. Đó là vấn đề lớn. Chỉ là nó không phải vấn đề riêng của frontend
webpack cũng đã 13 năm tuổi, nhưng ngay trong vài năm gần đây cách cấu hình của nó vẫn thay đổi mạnh mẽ
Nếu cấu hình Apache thay đổi thường xuyên như các hệ thống này, chẳng ai dùng Apache cả
Ở công ty trước, trong 2 năm đã có 2 lần di chuyển cơ sở dữ liệu, tiêu tốn tổng cộng 1 năm thời gian kỹ thuật. Không phải chỉ vài bảng không cốt lõi mà là toàn bộ bảng đều bị ảnh hưởng. Khi có gì đó hỏng hoặc cấp trên hỏi sao chậm thế, họ lại đổ lỗi cho các kỹ sư đang học frontend vì còn thiếu kinh nghiệm
Tôi đã làm Java developer hơn 25 năm, và hơn 10 năm đầu có làm full-stack, đó cũng là mô hình phổ biến của các công ty thời đó. Giờ thì việc có một team frontend riêng là bình thường, thậm chí nhiều nơi còn có ba team riêng cho web, iOS và Android. Với tôi, sự thay đổi đó diễn ra vào khoảng thời kỳ chuyển từ AngularJS sang Angular
Java cũng thay đổi rất nhanh trong khoảng 10 năm đầu, đặc biệt là 3 năm đầu tiên thì cực nhanh. Nhưng giai đoạn đó đã kết thúc. Java 5 là thay đổi lớn, Java 8 cũng có những tính năng quan trọng, nhưng Java 8 là từ năm 2014. Team của chúng tôi gần đây mới chuyển sang Java 11, trong khi giờ đã có Java 24. Tôi chưa từng dùng tính năng nào của Java 11 và cũng không biết chúng là gì. Suốt 10 năm tôi không phải học thêm lấy một tính năng ngôn ngữ mới nào
Công cụ build vẫn y như 15 năm qua, IDE vẫn y như 20 năm qua. Framework dùng chủ yếu cũng vẫn như 10 năm qua. Khi tôi chuyển sang công việc gần đây nhất, cấu trúc codebase y hệt team trước đó
Xây dựng dịch vụ web bằng Java là một bài toán đã được giải xong. Theo nghĩa tốt, nó hoàn toàn nhàm chán, giống COBOL
Frontend thay đổi nhanh vào cuối thập niên 90 và đầu những năm 2000, nhưng sau đó nó vẫn tiếp tục thay đổi nhanh. Dự án UI cá nhân tôi làm vài năm trước giờ đã hoàn toàn lỗi thời
Với bất kỳ dự án Java nào tôi từng làm sau thời kỳ EJB, nếu bây giờ tìm một Java developer đưa vào thì họ có thể làm việc hiệu quả ngay. Ngay cả khi người đó sinh ra sau khi dự án được tạo cũng vẫn được. Cùng lắm chỉ cần học vài thư viện cũ
Cách bước xuống khỏi cái máy chạy bộ là đừng dùng frontend framework nữa. Không phải chọn một framework ngẫu nhiên khác rồi sau này lại viết lại
Cần server-side rendering, JavaScript chỉ khi cần thiết, và không chia nhân sự trong công ty thành backend với frontend riêng biệt
Nếu một kỹ sư có thể viết SQL để chỉ lấy đúng các cột cần cho một SSR web view, đồng thời cũng chịu trách nhiệm cho chính web view đó, thì không cần tốn dù chỉ 1 giây nghĩ về API hay ORM. Chỉ cần biết SQL và HTML/CSS/JS thuần hiện đại. Khi phần lớn công việc trở thành chuyển đổi view của nghiệp vụ (SQL) sang DOM (HTML), hệ sinh thái lập trình phía server sẽ lùi về phía sau
Tôi nghĩ hình thái cuối cùng là SSR nội dung web ngay bên trong RDBMS. Kiểu như Oracle APEX. Nhưng phần lớn kỹ sư vẫn chưa sẵn sàng cho cuộc thảo luận đó. Ngay cả tôi lúc đầu nhìn thấy ngoài thực tế cũng vậy. Chúng ta quá gắn bó với cách làm khiến mình đau khổ
Nó làm trầm trọng thêm vấn đề frontend trở nên quá phức tạp. Vì đã có người trong team frontend, họ sẽ tiếp tục tự tạo việc và tăng thêm độ phức tạp. Việc có quá nhiều người chỉ biết phát triển web mà không biết gì khác cũng là vấn đề
Trong side project của tôi, một trong các ràng buộc ban đầu là toàn bộ website phải xuống cấp một cách mượt mà ngay cả khi tắt JavaScript. Vì vậy mỗi khi định thêm thứ gì thường sẽ làm bằng JavaScript, tôi lại tự hỏi “có thể làm việc này mà không cần JavaScript không?”, và cho đến giờ thật ngạc nhiên là câu trả lời luôn là có
Chỉ riêng CSS selector cho các control HTML cơ bản thôi mà giờ đã làm được rất nhiều thứ. Codebase đó đến giờ vẫn chưa có nổi một dòng JS nào
Team sản phẩm/thiết kế có thể ép đưa vào càng nhiều đồ trang trí bằng JavaScript càng tốt, mà hoàn toàn không cân nhắc đến tính khả dụng, hiệu năng, khả năng truy cập hay kỹ thuật tốt
Tôi không giỏi frontend, và cũng không có designer. Tôi giỏi backend hơn nhiều, nhưng những người khác trong team có năng khiếu về thiết kế frontend hơn tôi
Khi tạo website đầu tiên, tôi đã đọc những bài kiểu như “Svelte tốt hơn React”, “solid-js sẽ là xu hướng lớn tiếp theo” và nghĩ đó là phần quan trọng của phát triển web
Người mới nên đọc MDN và bỏ qua phần còn lại
Mọi người cần tutorial và walkthrough, và cần xây dựng hiểu biết nền tảng về cách tất cả những thứ này hoạt động
Framework giúp trừu tượng hóa những phần đó
Nhưng sự ám ảnh gần đây với Next.js và SSR thì có thể không như vậy. Cá nhân tôi thấy đây có thể là yếu tố khiến phe React đi xuống
Nếu nghĩ đến việc JS thuần và CSS đã tiến bộ thế nào trong vài năm gần đây, cùng với những tính năng thú vị như animation cho
display: nonegần như đã đến giai đoạn được áp dụng, thì cách tạo HTML template từ phía server và chỉ dùng JS ở nơi cần thiết trông hợp lý hơn bao giờ hếtĐây là lời của một người chủ yếu kiếm sống bằng React
Giống tác giả, tôi cũng đã làm frontend theo đủ kiểu suốt 20 năm. Hệ sinh thái, mức độ churn, và màn nhào lộn để đồng bộ trạng thái giữa frontend và backend thật sự điên rồ
Gần đây tôi bắt đầu một dự án proof-of-concept với Go templates và HTMX, và đang cố tái hiện cảm giác xây UI bằng “component” như React. Vẫn còn nhiều phần thô ráp, nhưng có tiềm năng. Thành thật mà nói tôi vẫn chưa chắc có cần HTMX hay không. Tôi đã bắt đầu tự quản lý event listener, và có vẻ tôi thích cách đó hơn
Điều thú vị là việc quản lý trạng thái UI phức tạp dựa trên vai trò và quyền của người dùng lại dễ hơn nhiều ở phía server. Chỉ cần gửi HTML mà người dùng được phép thấy là xong
Tuy vậy, React, Vue và những thứ tương tự có động lực cực lớn. Tôi không biết một sự chuyển đổi tư duy tập thể sẽ có thể bắt đầu như thế nào. Nhất là khi xét đến việc có nhiều lập trình viên chỉ biết framework frontend như cách duy nhất để làm UI
Tôi không chắc về câu “dù chọn framework nào thì 5 năm sau nó cũng sẽ obsolete”
Tôi đã dùng React chuyên nghiệp hơn 10 năm
package.jsonbạn khai báo bao nhiêu dependency? Team dùng phiên bản node/npm nào?Nếu đang dùng bản đủ mới và các thư viện phổ biến, hẳn bạn đã thấy đống cảnh báo deprecated của dependency con trong lúc
npm installNói công bằng thì bản thân mã React đã giữ tương thích ngược khá tốt. Không phải lỗi của React. Nhưng các build system dùng 5 năm trước thì đều đã thay đổi và phá vỡ tương thích ngược. Tôi còn quên cả các component lifecycle method
Ngay cả một dự án được quản lý tốt như React cũng không thể thoát khỏi sự bừa bộn của hệ sinh thái quanh nó
Không phải lúc nào cũng có thể chọn như vậy, nhưng dạo này tôi thường chọn import JS thuần mà không cần build system, xử lý càng nhiều càng tốt ở backend Python/Django, và rời hẳn khỏi hệ sinh thái JavaScript. Tôi chưa từng hối hận
Bạn vẫn còn để app ở React 15 à?
Mọi trình soạn thảo WYSIWYG chạy trên React 16 đều không còn được hỗ trợ nữa. Nếu phát hiện ra vấn đề bảo mật thì đúng kiểu “cầu may”. Hoặc là đừng dùng nó
React 16 vẫn còn được hỗ trợ, nhưng rõ ràng là đã obsolete
Phản biện là nếu không áp dụng framework thì cuối cùng bạn sẽ tự tạo ra một framework nội bộ mà người ngoài team không hiểu, tài liệu thường sơ sài, và bạn cứ phải tiếp tục làm việc để thêm những tính năng mà framework sẵn có đã có rồi
Frontend có những chức năng chung cần thiết và những vấn đề chung cần giải quyết. Chẳng phải ít nhất bắt đầu với một thứ gì đó vẫn tốt hơn là khởi đầu từ con số 0 sao?
Vì chẳng ai từng thấy framework nội bộ đó nên không thể tìm được người có thể vào làm và tạo ra năng suất ngay lập tức. Dù tài liệu có tốt đến đâu thì vẫn cần thời gian để học và thấm nó. Nếu là tuyển dụng dài hạn thì chưa hẳn là tệ nhất, nhưng nếu tạm thời cần thêm lập trình viên thì bó tay
Tôi cũng đã viết ở nơi khác rồi, nhưng gần như ai cũng muốn webapp hoặc nghĩ rằng họ có webapp, trong khi thực tế phần lớn chỉ là website động. Để làm website động thì không cần chất chồng framework lên nhau
Đây không phải vấn đề của frontend mà là vấn đề của hệ sinh thái JS. Ở backend cũng xảy ra
Môi trường JS là một mớ hỗn loạn hoàn chỉnh, nơi dependency có hàng chục, hàng trăm dependency khác. Ví dụ, đồ thị dependency của Platformatic, một framework Node dựa trên Fastify, là như sau
https://npmgraph.js.org/?q=platformatic#zoom=h
Những dependency này có thể bị bỏ rơi vào bất kỳ lúc nào. Ngay cả những dependency khổng lồ như Axios hay Express cũng từng có lúc trông như bị bỏ mặc
Và mỗi dependency đều bị chi phối bởi cách mà maintainer của nó cho là đúng. Vài ngày trước, một dependency mà tôi dùng trong production — có khoảng 25 triệu lượt tải mỗi tuần, trong khi React khoảng 26 triệu, và được dùng trong 10 triệu repository trên GitHub — đã quyết định rằng không cần hỗ trợ một phiên bản Safari từ khoảng 3 năm trước nữa. Xét việc Safari chiếm hơn 50% thị phần di động ở Mỹ thì đúng là điên rồ