React có mặt ở khắp mọi nơi, cung cấp sức mạnh cho hơn 1.3 triệu trang web và được sử dụng bởi nhiều (có lẽ là hầu hết) các công ty lớn.
Nó đã tồn tại hơn 12 năm, được Meta hậu thuẫn, với bộ công cụ rất trưởng thành và một hệ sinh thái rộng lớn.
Vì vậy, không có gì ngạc nhiên khi nó trở thành lựa chọn mặc định cho nhiều nhóm.
Nó rất ổn định với khả năng tương thích ngược tuyệt vời (thực ra đây cũng là một trong những điểm yếu của nó, vì có nhiều cách để làm mọi thứ).
Nhưng nó không hoàn hảo.
Nó thêm rất nhiều mã mẫu khiến việc viết code dài dòng hơn nhiều so với các framework như Svelte hay Vue.
DOM ảo cũng thêm một chi phí hiệu suất khá đáng kể (thực ra, chỉ là quá trình hòa giải, nhưng rất dễ sử dụng sai), ghi nhớ thường là thủ công, các tính năng đồng thời vẫn chưa thực sự trưởng thành, và các gói thường lớn, ngay cả khi đã loại bỏ rất nhiều code không dùng đến.
Nội dung chính
Ưu điểm
- Nhiều việc làm
- Phổ biến rộng rãi, hệ sinh thái khổng lồ, hỗ trợ cộng đồng tốt, được các tập đoàn lớn hậu thuẫn
- Linh hoạt, có thể xây dựng mọi thứ từ SPA, email đến ứng dụng di động (đại loại vậy)
Nhược điểm
- Mặc dù bắt đầu nhanh, nhưng React có thể mất nhiều thời gian để thành thạo đúng cách, và có nhiều điều khiến người mới bắt đầu vấp ngã
- Kém hiệu suất hơn ngay từ đầu, và DOM ảo thêm một chi phí phụ trội
- Khá nặng về mã mẫu, đặc biệt khi so sánh với Svelte hoặc Solid
Suy nghĩ của tôi
Nếu bạn đang lập trình theo cảm hứng, React có một lợi thế rất lớn, vì có quá nhiều code ngoài kia để các AI tiêu thụ.
Tương tự, nếu bạn đang tìm kiếm một công việc, bạn không thể sai lầm khi học React vì nó đã là framework thống trị của hầu hết các công ty trong một thời gian khá dài.
Tuy nhiên, cá nhân tôi không thích React:
nó chậm, nặng, nhàm chán và đôi khi phức tạp hơn một chút so với các framework khác.
Tôi thấy thật khó chịu khi cần làm quá nhiều công việc thủ công để cải thiện hiệu suất của một ứng dụng.
Điều này làm cho mã trở nên dài dòng và dễ mắc lỗi.
Mặc dù công cụ dành cho nhà phát triển rất tốt, việc kiểm tra đầu ra đã biên dịch vẫn có thể khá đau đầu.
Tôi dành nhiều thời gian hơn với tài liệu mở, vì đặc tả React khá lớn và rộng.
Những gì tôi đã xây dựng
Vue
Vue là một framework tiến bộ, nghĩa là nó có thể được sử dụng cho mọi loại ứng dụng, từ chỉ một tập lệnh nhúng để nâng cao HTML cho đến một SPA đầy đủ với SSR.
Giống như Svelte, nó sử dụng SFC (single file components
– thành phần tệp đơn) nơi mỗi tệp.vueđóng gói mẫu, logic và CSS phạm vi cùng nhau.
Đối với tính phản ứng, Vue sử dụng ES2015 Proxies để theo dõi các phụ thuộc và chỉ cập nhật những gì cần thiết, mà không cần ghi nhớ thủ công.
Ưu điểm
- Thực sự dễ dàng, trực quan và nhanh chóng để học và sử dụng
- Các thành phần tệp đơn đẹp với kiểu dáng phạm vi
- Tính phản ứng dễ dàng, chi tiết và theo dõi phụ thuộc hiệu quả
- Công cụ chính thức cho định tuyến, trạng thái và SSR (được đóng gói riêng)
Nhược điểm
- Mặc dù Vue có thể mở rộng rất tốt, nhưng cần nhiều suy nghĩ khi sử dụng nó cho một dự án rất lớn
- Có một số điểm không nhất quán (chẳng hạn như hai API Options và Composition cạnh tranh nhau)
- Một số lưu ý về tính phản ứng (ví dụ:
.value trên refs, việc giải cấu trúc làm mất tính phản ứng)
Suy nghĩ của tôi
Vue có thể được coi là framework “vừa phải”, nằm thoải mái giữa sự linh hoạt của React và cấu trúc của Angular.
Vue đủ nhanh, đủ thú vị và đã được kiểm chứng đủ, nhưng không thực sự xuất sắc một cách đáng kinh ngạc trong bất kỳ lĩnh vực nào trong số này.
Hệ thống phản ứng sử dụng Proxy thực sự ấn tượng.
Thay đổi một thuộc tính dữ liệu và mọi thứ phụ thuộc vào nó sẽ tự động cập nhật.
Và, hệ sinh thái mạnh mẽ hơn nhiều so với mọi người nhận ra.
Tôi đã chọn Vue cho Dashy, vì nó vừa có mọi thứ tôi cần, đồng thời cũng vô cùng dễ dàng, để những người đóng góp có thể thêm các widget và tính năng của riêng họ mà không cần đường cong học tập dốc.
Những gì tôi đã xây dựng
Svelte
Svelte luôn được xếp hạng là một trong những framework được yêu thích nhất, và có lý do chính đáng.
Nó đơn giản, nhanh, nhẹ và thực sự thú vị.
Tính phản ứng được tích hợp trực tiếp vào ngôn ngữ, không có hooks, proxy hay sự kỳ lạ củauseEffect;
chỉ cần gán cho một biến và nó phản ứng.
Không giống như nhiều framework khác, nó không cung cấp runtime hoặc sử dụng DOM ảo.
Thay vào đó, các thành phần được biên dịch thành JS thuần tối ưu hóa cao tại thời điểm xây dựng.
Vì vậy, không có chi phí runtime, không có mã framework trong gói của bạn và bạn có được hiệu suất gần như gốc trong trình duyệt.
Ồ, và đầu ra được biên dịch dễ đọc một cách đáng ngạc nhiên đối với con người.
Ưu điểm
- Các gói nhỏ hơn, nhanh hơn so với React hoặc Vue
- Mô hình phản ứng thực sự đơn giản
- Ít mã mẫu hơn bất kỳ framework nào khác
- Hoạt ảnh được tích hợp sẵn
Nhược điểm
- Hệ sinh thái vẫn nhỏ hơn React/Vue
- SvelteKit vẫn đang trưởng thành và có thể kém ổn định hơn một chút so với Next/Nuxt
- Đối với các nhóm lớn hoặc dự án khổng lồ, công cụ không mạnh mẽ bằng
Suy nghĩ của tôi
Xây dựng với Svelte khiến tôi hạnh phúc.
Tôi thích việc nó vừa hiện đại, trực quan và nhanh, nhưng cũng vì các SFC của nó rất phù hợp với các công nghệ web cốt lõi:
chỉ là HTML, CSS và JS.
Svelte đã là lựa chọn hàng đầu của tôi để xây dựng mọi thứ nhanh chóng và đẹp mắt, trong khi vẫn tạo ra một kết quả hiệu suất cao.
Nhưng tôi nhận thấy rằng nếu tôi không chú ý đến cấu trúc, một dự án lớn có thể nhanh chóng trở nên lộn xộn.
Tôi không nhất thiết sẽ sử dụng nó cho một bảng điều khiển doanh nghiệp khổng lồ nơi bạn có 15 đội cùng làm việc trên một codebase chung, React hoặc Angular vẫn mang lại nhiều khả năng dự đoán, ổn định và công cụ hơn trong những tình huống đó.
Những gì tôi đã xây dựng
Angular
Bạn có lẽ đang nghĩ Angular là một framework cũ kỹ, chỉ được dùng trong các ứng dụng kế thừa và môi trường doanh nghiệp.
Và vâng, điều sau là đúng, nhưng các bản phát hành gần đây (vâng, nó vẫn rất năng động) có một số tính năng tuyệt vời, khiến nó trở thành một lựa chọn rất khả thi vào năm 2025.
Không giống các framework khác, Angular đi kèm mọi thứ đầy đủ:
định tuyến, biểu mẫu, HTTP, kiểm thử, quốc tế hóa, hoạt ảnh, SSR và hơn thế nữa
– tất cả đều được duy trì chính thức và tích hợp sâu.
Không cần phải ghép nối một chồng công nghệ.
Nhưng viết code với nó có thể dài dòng.
Ưu điểm
- TypeScript ngay từ đầu
- Rất ổn định hiện nay
- Mọi thứ cần thiết cho ứng dụng lớn đều được bao gồm
- Biên dịch AOT cho các template, khiến nó nhanh hơn một số framework
- Nhiều việc làm trong thế giới doanh nghiệp
Nhược điểm
- Đường cong học tập dốc hơn (RxJS, DI, modules, zones)
- Dài dòng so với các framework như Svelte hoặc Vue
- Cộng đồng nhỏ hơn React/Vue trong mã nguồn mở hoặc hướng dẫn
- Ít linh hoạt hơn — bạn xây dựng theo cách của Angular
Suy nghĩ của tôi
Angular không phải là “ngầu”, nhưng nó nhất quán, mạnh mẽ và có thể mở rộng.
Thực sự không thiếu thứ gì, vì vậy bạn không cần phải cài đặt hàng tấn phụ thuộc bên thứ ba chỉ để thực hiện các tác vụ phổ biến.
Tôi không thấy nó phức tạp để bắt kịp, nhưng có rất nhiều thứ tôi cần học từ tài liệu, đặc biệt là với cú pháp template, định nghĩa component, directives, injections, v.v.
Điều duy nhất tôi gặp khó khăn, là ban đầu để làm cho hydration hoạt động cho các route SSR của mình.
Mọi thứ khác đều suôn sẻ.
Tôi sẽ cân nhắc sử dụng Angular lại cho các ứng dụng lớn, nơi sự ổn định, cấu trúc và hỗ trợ lâu dài quan trọng, nhưng không nhiều cho các ứng dụng nhỏ hơn.
Những gì tôi đã xây dựng
Lit
Lit là một framework siêu nhẹ để xây dựng các Web Component dựa trên tiêu chuẩn, được xây dựng xung quanh các API trình duyệt hiện đại (như Custom Elements và Shadow DOM) và rất tuyệt khi bạn muốn các thành phần UI có thể tái sử dụng, độc lập với framework.
Ưu điểm
- Sử dụng Web Component gốc và các tiêu chuẩn phổ biến
- Hiệu suất cao, vì không có DOM ảo, và các cập nhật là tối thiểu và trực tiếp
- Hoạt động với bất kỳ framework nào (hoặc không dùng framework)
Nhược điểm
- Cú pháp dài dòng:
@click , ?disabled, .value, v.v. - Component dựa trên lớp cảm giác lỗi thời
- SSR vẫn đang thử nghiệm và khó thiết lập
- Hệ sinh thái và tài nguyên học tập còn hạn chế
Suy nghĩ của tôi
Cá nhân tôi thấy việc viết các component Lit hơi giống như bước trở lại thời kỳ cũ của React.
Các component dựa trên lớp, và ngay cả những component đơn giản nhất cũng khá dài dòng, với một lượng lớn code mẫu.
., boolean bằng một?, trình nghe sự kiện bằng một@và tất cả giá trị bằng một$Kết xuất phía máy chủ vẫn đang thử nghiệm, và thật là một cực hình để làm cho nó hoạt động trong một dự án Vite + Lit độc lập.
Vì nó là web-component, và sử dụng shadow DOM, mỗi component hoàn toàn bị cô lập.
Điều này có cả ưu và nhược điểm, nhưng nếu bạn không quen với điều này, bạn có thể nhận thấy những thứ như CSS reset toàn cục hoặc kiểu dáng của bạn không hoạt động như bạn mong đợi.
Những gì tôi đã xây dựng
Marko
Marko là một ngôn ngữ khai báo và framework web hiệu suất cao, được xây dựng và duy trì bởi eBay.
Ưu điểm
- Cú pháp ngắn gọn, với các tùy chọn viết tắt cho markup, không cần import component/thẻ tùy chỉnh
- SSR và component UI đẳng cấu khá dễ dàng
- Định tuyến dễ dàng với Marko run
Nhược điểm
- Rất hạn chế và hỗ trợ ít — bạn chắc chắn không thể viết code ngẫu hứng với Marko!
- Tuyệt vời khi nó hoạt động, nhưng nếu bạn gặp sự cố, bạn sẽ phải lần mò vào mã nguồn của Marko và tự giải quyết
- Thiếu tài liệu (ví dụ:API cấp thấpchỉ là trang trống)
Suy nghĩ của tôi
Tôi thực sự rất thích những gì Marko hướng tới, việc tạo template rất hợp lý.
Nhưng nó hơi có cảm giác như sử dụng một framework từ tương lai, nhưng lại trong quá khứ, nó vừa mang tính tương lai vừa lỗi thời cùng một lúc.
Nhược điểm chính, và nó là một nhược điểm lớn
– đó là có rất ít thông tin trực tuyến.
Tài liệu ít ỏi, bạn không thể chỉ tìm kiếm trên github để tìm ví dụ, các công cụ AI không biết gì về kiến thức cơ bản của Marko, hỗ trợ cộng đồng rất hạn chế và ngay cả intelisense cũng rất hạn chế.
Vì vậy, nếu bạn gặp sự cố, bạn sẽ phải tự mình lần mò vào mã nguồn của Marko.
Và nó có một vài điểm đặc thù, thường không được ghi chép (ví dụ:
nếu bạn sử dụngclass {}trong một view hoặc layout cấp cao nhất, tất cả tính tương tác sẽ bị hỏng, mà không có thông báo lỗi).
Vì vậy, dù tôi rất thích làm việc với Marko, tôi không cảm thấy mình có thể giới thiệu nó cho bất kỳ dự án nghiêm túc nào, chỉ vì cộng đồng quá nhỏ.
Tôi cũng không nghĩ nó sẽ được duy trì tích cực lâu hơn nữa, vì hoạt động trên repo đã chậm lại trong vài năm qua, và ebay dường như là những người duy trì cốt lõi duy nhất.
Những gì tôi đã xây dựng
jQuery
Bạn có nghĩ tôi sẽ quên người bạn cũ jQuery sao?!
Gần 20 năm kể từ lần phát hành đầu tiên, jQuery vẫn hiện diện trên hơn 70% trong số 100k trang web hàng đầu (con số này phần lớn tương quan với việc sử dụng WordPress).
Con số đó giờ đang bắt đầu giảm, và với lý do chính đáng
– đối với các ứng dụng đơn giản, nhiều tính năng của jQuery giờ có thể được thực hiện một cách tự nhiên bằng JavaScript hiện đại, và đối với các ứng dụng phức tạp hơn, các framework hiện đại làm công việc tốt hơn nhiều.
…nhưng đầu năm nay, và lần đầu tiên kể từ năm 2016, một phiên bản chính mới,jQuery 4đã được xuất bản.
Ưu điểm
- Không cần công cụ build, trình quản lý phụ thuộc, trình chuyển mã (transpiler), v.v.
- Đã được kiểm chứng qua thực tế rất nhiều
- Hữu ích để hỗ trợ các trình duyệt (rất) cũ không có các tính năng JavaScript mới hơn
Nhược điểm
- Không có nhiều thứ jQuery có thể làm mà JavaScript thuần (vanilla JS) không thể làm được
Dù vậy, tôi không thể hoàn toàn thuyết phục bản thân xây dựng một ứng dụng hiện đại bằng jQuery.
Mặc dù tôi đã từng sử dụng nó (nhiều năm trước) chorevision-quizzes,intern-magnetvàuser-monkey.
Alpine
Cho phép bạn dễ dàng thêm tính phản ứng (reactivity) vào HTML được render từ server (không cần SPA, không hydration, không SSR).
Nó lý tưởng cho các cải tiến giao diện đơn giản mà không cần thiết lập build đầy đủ.
Điều thông minh là cách Alpine không làm phiền bạn.
HTML vẫn dễ đọc, JavaScript được giữ ở mức tối thiểu, và mọi thứ vẫn hoạt động ổn định (gracefully degrades) nếu Alpine không tải được.
Đó là sự cải tiến lũy tiến (progressive enhancement) được thực hiện đúng cách
– trang vẫn hoạt động mà không có JavaScript, nhưng trở nên tương tác được khi nó tải.
Cú pháp đọc rất tự nhiên:x-on:click="searchWeather()",x-text="temperature",x-bind:class="{'active': isExpanded}".
Nó mang tính khai báo giống như template của Vue nhưng tồn tại ngay trong HTML.
Các cập nhật phản ứng xảy ra tự động khi bạn sửa đổi dữ liệu.
Ưu điểm
- Không cần thiết lập — chỉ cần một thẻ
Những gì tôi đã xây dựng
Qwik
Qwik khá là độc đáo.
Nó hoàn toàn suy nghĩ lại về cách ứng dụng web hoạt động bằng một thứ gọi là “tính tiếp tục”
– trang của bạn tải ngay lập tức mà không cần JavaScript, sau đó các thành phần riêng lẻ chỉ thức dậy khi bạn tương tác với chúng.
Nó giống như có một trang web đang ngủ cho đến khi bạn chạm vào nó.
Ưu điểm
- TTFB cực thấp, với <1KB JS khi tải lần đầu
- Mở rộng rất tốt cho các ứng dụng lớn với định tuyến phức tạp hoặc nội dung động
- Trải nghiệm nhà phát triển quen thuộc, với JSX + Vite + signals + định tuyến dựa trên tệp
Nhược điểm
- Bắt buộc phải có SSR, nó không thể hoạt động hoàn toàn phía máy khách
- Đường cong học tập dốc hơn, và một số khái niệm (như tính tiếp tục và tuần tự hóa) có thể lạ lẫm với nhà phát triển lúc đầu
- Gỡ lỗi có thể phức tạp, vì logic bị chia cắt qua ranh giới máy chủ
Suy nghĩ của tôi
Nếu bạn đang làm việc trên một ứng dụng rất lớn hoặc phức tạp, đồng thời cần hiệu suất cao, thì Qwik là một lựa chọn tự nhiên.
Chắc chắn nó có cộng đồng nhỏ hơn, đường cong học tập dốc hơn và phức tạp hơn các lựa chọn khác, nhưng khi mỗi byte đều quan trọng thì đây chỉ là cái giá phải trả.
Những gì tôi đã xây dựng
Khoan đã
– Sẽ không công bằng nếu bạn xây dựng các ứng dụng khác nhau!
Đó là một ý kiến rất hợp lý, nhưng đừng lo
– tôi hiểu bạn mà!
Để so sánh các framework này một cách công bằng hơn, tôi cũng đã xây dựng một ứng dụng mini giống hệt nhau trong mỗi framework và đánh giá hiệu suất từng cái để so sánh.
Bạn có thể xem điều này tại đây:https://github.com/Lissy93/framework-benchmarks.
Có một bộ kiểm tra chung để xác nhận rằng mỗi ứng dụng đáp ứng các yêu cầu giống hệt nhau, mỗi ứng dụng sử dụng tất cả các tài sản và kiểu dáng được chia sẻ, và sau đó tôi có một tập hợp các tập lệnh đánh giá hiệu suất chạy tất cả các bài kiểm tra hiệu suất thực tế.
Những kết quả này sau đó được xử lý và đưa vào nhánhresults, cùng với một số biểu đồ và tóm tắt nằm trong readme chính và trêntrang chủ framework-benchmarks.
Kết luận
Vậy là xong, 12 framework, 12 ứng dụng (và 12 năm đau khổ).
Nếu bạn đang cố gắng chọn một framework cho dự án tiếp theo của mình, hãy xem công cụ so sánh frameworkStack Match.
Và nếu bạn thích loại nội dung này, hãy cân nhắc theo dõi tôi 🩷
Tôi là@Lissy93trên GitHub, và @lissy93 ở đây trên DEV.
Tôi xây dựng rất nhiều công cụ dành cho nhà phát triển, ứng dụng bảo mật và quyền riêng tư và những thứ có thể tự lưu trữ cho Linux, bạn có thể xem trên trang web của tôihttps://010000010110110001101001011000110110100101100001.com(vâng, tên miền thực sự dễ nhớ!)
Dù sao, cảm ơn vì đã đọc, chúc bạn viết mã vui vẻ và chúc mừng năm mới!!
Ồ, và suýt quên
– framework nào thực sự tốt nhất?
Chà, rõ ràng đó phải là [đã đạt giới hạn ký tự]
