Cuộc chiến framework JavaScript đã kết thúc
(medium.com)Và chỉ có một người chiến thắng.
Những người tham gia: Cuộc chiến giữa các framework là một chủ đề nóng trong cộng đồng JS. Backbone, Sencha và các dự án khác đã biến mất. jQuery đáng ngạc nhiên là vẫn còn một cộng đồng lớn. Cũng có những cái không diễn ra như kỳ vọng, như Angular.
jQuery: Người tham gia lâu đời nhất. Nó nổi tiếng vì xử lý các vấn đề tương thích trình duyệt. Nhưng rất khó để mở rộng thành ứng dụng. Ngày nay nó không còn là xu hướng chủ đạo và cũng không phải lựa chọn tốt nhất.
AngularJS: Đã ở chế độ LTS và đã nghỉ hưu. Đây từng là một bước nhảy lớn trong hệ sinh thái framework và có nhiều người nhớ nó. Vì không còn được duy trì nữa nên nó không còn là một người tham gia.
Angular:
- Xuất hiện để cạnh tranh với React. Do các vấn đề về hiệu năng và độ vững chắc của AngularJS, nhiều lập trình viên đã ghen tị với React. Angular cố gắng hiện đại hóa AngularJS và tận dụng các cải tiến của ES6 để cạnh tranh với React.
- Đường cong học tập nặng nề là khó khăn lớn nhất. Nó đòi hỏi nhiều khái niệm. Nó kế thừa đường cong học tập của AngularJS, đồng thời có thêm những khó khăn mới như RxJS hay dependency injection (DI) phân cấp.
- Một mối lo khác là đã thất hứa quá nhiều. Ví dụ, V2 từng có thể tạo các trang server-side rendering (SSR) một cách đơn giản, nhưng tính đến 2022/2/24 thì không thể hoạt động nếu không có JS.
- Vấn đề lớn nhất là sự phân mảnh và nâng cấp phiên bản. Việc nâng cấp phiên bản quá khó nên người dùng không muốn chấp nhận rủi ro. Điều này thể hiện rõ trong thống kê của trang npm.
VueJS:
- Đây là câu trả lời cho các nhà phát triển muốn thứ gì đó có hiệu năng tốt hơn AngularJS, ổn định hơn Angular và dễ viết hơn. Trong hệ thống template, Vue rất gần với AngularJS, nên vừa giữ được sự đơn giản của AngularJS vừa nhận sức mạnh từ React.
- Nhưng VueJS có những vấn đề nghiêm trọng ở phiên bản 1 và 2. Nó không xử lý tốt array, và các tác giả đã đổ lỗi cho JavaScript vì đã chọn sai thuật toán cập nhật. Nó cũng phụ thuộc vào các thư viện như Vuex hoặc Redux.
- Vấn đề này đã được giải quyết trong phiên bản 3. Tuy nhiên, việc đổ lỗi cho người khác về sai lầm của chính mình không phù hợp với cộng đồng.
SvelteJS:
- Một đối thủ đang phát triển. Nó đưa ra nhiều lời hứa lớn. Họ cho rằng việc biên dịch component sang ngôn ngữ mệnh lệnh là ưu điểm chính. Theo họ, điều này tốt hơn cách khai báo của React.
- Cách dùng thì đơn giản. Tuy nhiên, các thành phần được tạo ra từ việc biên dịch lệnh không dễ dự đoán như vẻ ngoài của nó. Trong một số trường hợp, nó không thể phát hiện thay đổi một cách chính xác. Khi đó state có thể bị hỏng và view có thể không được cập nhật đúng. Vấn đề này gây ra nhiều lo ngại, khiến khó biện minh cho bất kỳ dự án SvelteJS nào, giống như VueJS trong quá khứ.
StencilJS:
- Nói строго thì đây không phải framework. Nó cho phép viết component và chuyển đổi sang framework khác. Hiện tại có thể chuyển đổi sang Angular, React, Vue và Web Components.
- Nó đặt ra câu hỏi: liệu đây có phải là mã giống mã của các framework khác không? (xem nguyên văn)
Mitosis:
- Có lẽ bạn chưa từng nghe đến, nhưng đây là lý do khiến bài viết này được viết ra. Đây là framework mới nhất do Misko Hevery, người tạo ra Angular, xây dựng.
- Nó có cùng mục tiêu với StencilJS. Nó biên dịch component sang rất nhiều framework.
- Tương tự, nó đặt ra câu hỏi: liệu đây có phải là mã giống mã của các framework khác không? (xem nguyên văn)
React:
- Một trong những framework lâu đời nhất đã có mặt trên kho npm hơn 10 năm. Nó đã thay đổi rất nhiều nhưng phần lớn vẫn tương thích với các phiên bản cũ. Mọi thay đổi đều theo hướng tốt hơn. Một số người cho rằng làm React với hook đã tạo ra một framework tốt hơn rất nhiều.
- Phẩm chất tốt nhất của nó không nằm ở hook hay các tính năng nhìn thấy được, mà ở điều ngược lại. Nó áp dụng các chuẩn JS mới nhất và JSX. Nó không còn là framework nữa. Có lẽ chưa bao giờ là như vậy. React đã nỗ lực quá nhiều vì tiêu chuẩn đến mức tự loại bỏ chính mình khỏi mã của người dùng.
Vì vậy, người chiến thắng là...
- JSX. Cũng là React, nhưng là triết lý đứng sau React. Bản thân React là một thư viện. Tuy nhiên có thể thay thế nó bằng nhiều thư viện khác như Preact hay React Native. Nhìn kỹ hơn thì StencilJS hoặc Mitosis rất giống React, và điều này không phải ngẫu nhiên.
- "Framework tốt nhất là framework tự loại bỏ chính mình khỏi mã của người dùng"
- React tận dụng rất nhiều JS và JSX. Mã của người dùng không phụ thuộc vào React. Cùng một đoạn mã có thể chạy trên framework khác mà không cần sửa đổi lớn.
- Vì vậy không còn nghi ngờ gì nữa, React là người chiến thắng trong cuộc chiến framework.
- Bởi vì nó không phải là framework trong mã của người dùng.
15 bình luận
Điều quan trọng là nếu viết mã sao cho thực hành tối đa lời khuyên của Bob rằng “đừng kết hôn với framework”, thì dù là React, Vue hay Angular, chẳng phải chúng ta đều có thể phát triển một cách thú vị sao?
Triển vọng của marko js như thế nào? Vì được eBay hỗ trợ nên gần đây tôi bắt đầu quan tâm, nhưng trong bài gốc thậm chí còn không hề nhắc tới...
React "đã thay đổi rất nhiều nhưng phần lớn vẫn tương thích với các phiên bản trước" - tôi đã không có nhiều trải nghiệm như vậy với tính tương thích này.
Angular "phân mảnh và nâng cấp phiên bản" - nhưng ở điểm này thì tôi lại có khá nhiều trải nghiệm mượt mà.
Tôi nghĩ JSX nên được phân loại là một specification chứ không phải framework. Tôi hiểu ý tác giả muốn nói gì, nhưng phần dẫn nhập dài lê thê một cách không cần thiết, và trên hết tiêu đề rất câu clickbait. Cách hành văn như vậy đang tự làm giảm chất lượng của chính bài viết.
Cảm ơn phần tóm tắt và những bình luận hay~! Mình nghĩ những câu chuyện như thế này sẽ giúp ích rất nhiều cho những người khác ;)
Nhìn chung tôi thấy đây là một bài viết khá kỳ lạ.
Trước hết là phần về Svelte.
Tôi xem bản gốc thì thấy họ viết rằng khi cập nhật mảng, nếu dùng kiểu như
array[0] += 1thì sẽ không được cập nhật nên đó là vấn đề, nhưng ngay trong tài liệu chính thức của Svelte cũng có nói rằng mảng phải được gán lại thì mới cập nhật, hơn nữa ngay từ đầu trong React cũng đâu thể cập nhật mảng theo kiểu này đúng không?Cả phần VueJS nữa.
Họ đang nói về nhược điểm của Vue khi so sánh với Angular, nhưng mang một đoạn mã Angular chạy được và một đoạn mã Vue không chạy được ra rồi bảo Vue không ổn thì tôi không hiểu điều đó có ý nghĩa gì.
Tôi nghĩ đây là một lời phê bình hợp lý. Sự khác biệt giữa gán lại và mutation là điểm dễ gây nhầm lẫn với người mới bắt đầu, và vì cả Svelte lẫn Vue đều dùng một cú pháp riêng tách biệt nhưng tương tự JavaScript, nên những chỗ không hoạt động như dự đoán hoàn toàn đáng bị phê bình.
Đặc biệt, Vue cập nhật trạng thái khi
setxảy ra thông qua proxy; thoạt nhìn thì có vẻ dễ, nhưng lại có nhiều chỗ dễ sập bẫy, nên tôi cũng rất đồng cảm với việc người ta phê bình điểm đó.React thì tự do hơn nhiều trong vấn đề này: trạng thái không được cập nhật chỉ bằng gán lại, mà phải gọi tường minh hàm
setUpdate, nhờ đó cung cấp cơ chế cập nhật một chiều trong phạm vi chuẩn JavaScript, nên ngay từ đầu đã không phát sinh những chuyện như nhầm lẫn giữa việc chỉ thay đổi một phần của mảng và việc gán lại.Đây hơi là câu chuyện chen ngang một chút, nhưng trong Vue 3 thì kiểu cập nhật mảng như vậy được hỗ trợ theo hướng reactive, nên tôi thấy bài viết này chỉ chăm chăm chỉ trích các phiên bản Vue cũ rồi lướt qua khá qua loa...^^;; Trong khi ở React, việc kiểu cập nhật này không hoạt động lại tuyệt đối không phải là một nhược điểm nhỏ, nhưng có cảm giác những đặc điểm như vậy lại không được phân tích, làm rõ cho đàng hoàng. haha
Bản gốc cũng có rất nhiều bình luận, và dường như cũng có nhiều bình luận chỉ ra nhiều vấn đề khác nhau.
Phần "Có phải là đoạn mã trông giống mã của framework khác không?" có kèm giải thích về StencilJS và Mitosis khá khó hiểu nên tôi đã xem bản gốc, và có vẻ như họ đang hỏi rằng chẳng phải đoạn mã dùng trong hai framework đó trông giống như đã thấy ở framework khác hay sao?
Có lẽ họ viết vậy với ý là cách viết mã khá giống React.
Đánh giá về VueJS có phần quá khắt khe..
Sự phụ thuộc vào redux thì react cũng chắc chắn không hoàn toàn tự do khỏi nó..
Nếu xét về quy mô người dùng thì đúng là React áp đảo ở vị trí số 1,
nhưng về mặt kỹ thuật thì không thể gọi đó là một dự án kém hơn React được.
Có phải điểm chính khi bàn về VueJs ở đây chủ yếu không phải là sự phụ thuộc vào thư viện bên ngoài, mà là "thái độ đổ trách nhiệm cho JS đối với những vấn đề do chính họ gây ra"?
Dù sao thì đúng là dư luận về vueJS không mấy tích cực.
Nếu vào đọc bài gốc, đoạn nhắc đến sự phụ thuộc vào Vuex và Redux cũng nói rằng để giải quyết các vấn đề phát sinh trong VueJS 2 thì những thư viện như Vuex, Redux gần như là 'bắt buộc'.
Đây cũng là nội dung mà ở bài gốc đã có khá nhiều bình luận rồi.
Khi độ phức tạp tăng lên, dù là Vue hay React thì các thư viện lưu trữ/cache trạng thái như Redux đều trở thành thứ "bắt buộc".
Đúng là như vậy, ở bài gốc thì với VueJS đây là nhược điểm, còn với React thì họ đã "cố ý" không nhắc đến.
Còn cách hành xử của cộng đồng thì từ góc nhìn của tôi không mấy quan trọng..
Trong React, Redux không phải là thứ bắt buộc. Vì có thể dùng Context API hoặc
useReducerđể quản lý state. Tuy vậy, tôi cũng không nghĩ đây là cơ sở để nói rằng React tốt hơn Vue.Vâng haha, nhìn chung có vẻ đây không phải là một bài viết hay.
Tác giả dường như đã định sẵn kết luận rồi, và để đi đến kết luận đó thì lại chê bai các framework khác.