Show HN: Nue – Ứng dụng nhẹ hơn một nút React
(nuejs.org)- Nue đặt vấn đề với các mặc định nặng nề của phát triển web hiện đại, cho rằng chỉ với HTML, CSS, JavaScript cũng có thể tạo một ứng dụng hoàn chỉnh nhỏ hơn một nút React/ShadCN
- Cùng ứng dụng đó còn được gắn engine tính toán Rust và Event Sourcing, cung cấp demo tìm kiếm tức thì và thực hiện thao tác trên 150.000 bản ghi
- Engine JavaScript đã dừng vì ngoại lệ vượt quá call stack tối đa, trong khi phiên bản Rust/WASM được đưa ra như một ví dụ xử lý tức thì cùng quy mô dữ liệu
- Thay vì các idiom của React, Nue muốn đơn giản hóa cấu trúc ứng dụng bằng cách tiếp cận ưu tiên mô hình, các hàm có thể kiểm thử, kiểu tĩnh và phụ thuộc tối thiểu
- Với các kỹ sư thiết kế/UX, Nue nhấn mạnh cách kiểm soát trực tiếp bằng CSS hiện đại thay vì hệ thống thiết kế hơn 40.000 dòng, React hook và các utility class
Demo ứng dụng nhẹ hơn một nút React
- Demo của Nue cho thấy ứng dụng có thể nhỏ đến mức nào khi tận dụng HTML, CSS, JavaScript gần với các chuẩn web
- Điểm được nhấn mạnh là kích thước toàn bộ ứng dụng nhỏ hơn một nút React/ShadCN
- Phiên bản quy mô lớn bổ sung engine tính toán Rust và Event Sourcing vào cùng ứng dụng
- Hướng tới cấu hình có thể tìm kiếm tức thì và thực hiện các thao tác khác trên 150.000 bản ghi
- Engine phiên bản JavaScript bị dừng do ngoại lệ vượt quá call stack tối đa
- Demo Rust/WASM cho thấy có thể thao tác tức thì trên 150.000 bản ghi
Cách phát triển mà Nue nhắm tới
- Với các kỹ sư Rust, Go, JavaScript, Nue nhấn mạnh hướng tận dụng các mẫu phần mềm truyền thống và tầng mô hình tách biệt hơn là các idiom của React
- Nue đặt cách tiếp cận ưu tiên mô hình làm trọng tâm
- Hướng tới các hàm đơn giản, có thể kiểm thử, kiểu tĩnh và ít phụ thuộc
- Với kỹ sư thiết kế, Nue cho rằng có thể tạo hệ thống đơn giản hơn bằng CSS hiện đại thay vì các pattern React và hệ thống thiết kế hơn 40.000 dòng
- Nêu ví dụ như
@layers, biến CSS vàcalc() - Coi trọng cách kiểm soát trực tiếp typography và khoảng cách
- Nêu ví dụ như
- Với kỹ sư UX, Nue đề xuất một luồng làm việc giảm rào cản từ React hook và utility class, đồng thời trực tiếp xử lý trải nghiệm người dùng
- Nue là một web framework tập trung vào chuẩn web và hiện đang được phát triển tích cực
- Nue xem tình huống một nút đơn lẻ nặng hơn cả ứng dụng là ví dụ về độ phức tạp ẩn của phát triển web hiện đại, và muốn xây dựng lại công cụ cùng framework theo một kiến trúc sạch hơn, vững chắc hơn
2 bình luận
Nue - Khung web ưu tiên tiêu chuẩn
Ý kiến trên Hacker News
Nhìn những phản ứng tức giận với Nue theo nhiều kiểu, tôi thấy họ giống những người phụ thuộc quá nhiều vào React mà bỏ lỡ vấn đề lớn hơn
Vấn đề là các framework khổng lồ đã biến web thành một khối chậm chạp khủng khiếp
Làm DevOps/SRE, tôi xử lý các dịch vụ như vậy hằng ngày, và gần như không thể tìm được cái nào có lần tải đầu tiên dưới 10 giây
Ngay cả trên kết nối 10G được peering trong vòng 5ms với host, một dashboard trang chủ đơn giản hay trang ghi chú cũng mất hơn 10 giây, và nếu 95% trong đó là JavaScript thì điều đó có nghĩa là web app hiện nay đã đạt tới mức phình to khổng lồ, dựa dẫm vào engine trình duyệt nhanh và kỳ vọng đã bị hạ thấp
Tôi không kỳ vọng Nue sẽ thay đổi điều này theo kiểu cách mạng, nhưng ít nhất tôi có thể ủng hộ nó
Cụ thể, một dự án React mặc định tạo bằng
pnpm create vite -t react-tscó dung lượng khoảng 60KB sau nén, còn dự án Vue tạo bằngpnpm create vite -t vue-tskhoảng 25KBCác dự án cỡ trung làm bằng React/Vue mà tôi từng làm cũng chỉ khoảng 200–300KB sau nén, không tính ảnh, và vẫn dùng được ngay cả trong điều kiện giới hạn 2G thực tế
Một dashboard đơn giản mất hơn 10 giây để tải là thứ rác rưởi có thể được tạo ra bằng bất kỳ framework nào, và cũng có thể làm được mà không cần framework
Ngược lại, nếu theo kiểu jQuery mà kéo nguyên các phụ thuộc bên thứ ba về, tình hình còn có thể tệ hơn, kiểu tải xuống 200KB chỉ để dùng 1KB thực sự
So sánh trong bài cũng ngớ ngẩn, vì toàn bộ view của React không phải là cấu trúc sẽ lớn hơn “một nút React” rất nhiều, mà là cấu trúc chi phí ban đầu + chi phí biên
Phần lớn sự phình to của web đến từ việc lập trình viên không dành thời gian cho tối ưu hóa, lazy loading, cache, giảm phụ thuộc, và còn từ hàng trăm script theo dõi mà mọi site gắn vào để vắt kiệt doanh thu
Vài năm trước tôi từng sốc khi thấy một site gắn 50 tracker, giờ thì dù có hàng trăm cái tôi cũng không ngạc nhiên
Nếu lập trình viên quan tâm, site React cũng có thể rất nhanh, và phần phình to do React thêm vào thường không phải cốt lõi
Bài của OP mô tả nút là 78KB, nhưng đó là vì tải toàn bộ React chỉ cho một nút
Có hàng trăm nút trên trang không có nghĩa là tải 78KB hàng trăm lần, nên một site React phức tạp cũng không kém hiệu quả theo kiểu đó
Nếu là kỹ sư DevOps, tôi tò mò liệu có thống kê xem trong sự chậm chạp đó, framework và mã ứng dụng thực tế mỗi phần chiếm bao nhiêu không
Ở chỗ làm có một dashboard Vue 3 SPA với hơn 20 widget, mỗi widget tự gửi request và truyền hơn 2MB JavaScript đã nén, nhưng ngay cả khi tắt toàn bộ cache, nó vẫn tải xong trong vòng 2 giây
Ý tôi là tải toàn bộ, không phải “có thể tương tác”
Tôi đồng ý rằng web có thể nhẹ hơn, nhưng “gần như không thể tìm được lần tải đầu tiên dưới 10 giây” nghe giống phóng đại, và có thể không phải do có hay không có framework
Nhân tiện, web app này cũng không phải do đội giỏi nhất trong những đội giỏi nhất làm ra
SRE chỉ được gọi giúp khi có gì đó sai, nên không có gì đáng ngạc nhiên nếu bạn không thấy những thứ chạy tốt
Ai từng làm trong các dự án chậm đều biết rốt cuộc đó là trách nhiệm của ban quản lý, và việc codebase phình to đến mức không ai cảm thấy có thể sửa nổi cũng là trách nhiệm của ban quản lý
Có thể bạn nghĩ nếu họ gọi bạn sớm hơn thì đã thiết kế được thứ tốt hơn, nhưng điều đó cuối cùng cũng là trách nhiệm của ban quản lý
Nếu mọi người bỏ hết framework khổng lồ và phần mềm trở nên hoàn hảo, ổn định, thì cũng đáng nghĩ xem SRE chính xác sẽ làm gì
Nếu nhìn công nghệ theo cách khác, tôi nghĩ có một cơ hội lớn nằm ngay trước những năng lực bạn đang có
JavaScript thuần cũng hoạt động khá tốt, và đôi khi không có JavaScript lại còn tốt hơn
Trong một dự án SAP gần đây, có một tầng Java phía trước SAP và bên trên là một ứng dụng Angular khổng lồ; mục đích của ứng dụng là quản lý bán hàng B2B cho hàng hóa vật lý, và vì tình trạng tồn kho cực kỳ quan trọng nên gần như mọi màn hình đều gửi request đầy đủ tới tầng SAP
Lý do cần một “rich client” nặng nề là không rõ ràng, và PHP có khả năng đã phù hợp hơn nhiều
Bỏ qua phần quảng cáo thổi phồng, có vẻ các tổ chức lớn dùng framework như một cách để bảo đảm thực hành lập trình đồng nhất và dễ thay thế lập trình viên, nhưng chắc chắn phải có cách tốt hơn để đạt mục tiêu đó
Cái tuyên bố sẽ thay thế React là phần này: https://nuejs.org/docs/view.html
Đây là một tầng view không có kiểu theo hướng tương tự Angular 2.0 thời kỳ đầu, còn file model chỉ là JavaScript
Tức là không có kiểu ở đâu cả; nếu nhắm vào phía Vue.js thì có thể ổn
Tuy nhiên, hiện nay phần lớn người dùng React dùng TypeScript, và hỗ trợ kiểu hạng nhất ở tầng view rất hữu ích, nên có lẽ nên đổi hướng marketing sang phía đó một chút
Đó là thiết kế có chủ ý
Hệ sinh thái React đang khiến lập trình viên gắn TypeScript tới cả CSS, và như vậy là quá đà
Nue đi theo hướng ngược lại: giữ tầng trình bày sạch sẽ và có ngữ nghĩa, để các tiêu chuẩn web làm nhiều việc, còn kiểu tĩnh như Rust hay Go tỏa sáng ở phần logic nghiệp vụ thật sự quan trọng
Nếu đi theo hướng khác, nhu cầu đó sẽ giảm đi
Bản thân Vue được viết bằng TS, và phần lớn thư viện lớn cũng được viết bằng TS
Dựa trên /r/vuejs và trải nghiệm cá nhân, tôi cũng cho rằng hầu hết ứng dụng mới đều như vậy
Tuy rất tuyệt, nhưng tôi đã đầu tư vào Svelte và SvelteKit
Sau khi không chỉ làm một ví dụ đồ chơi mà xây dựng một ứng dụng khá lớn với hàng chục form và màn hình, tôi quay lại nhìn React và nhận ra rằng nếu hiểu hooks thì React không khó đến vậy, với nhu cầu của tôi nó cũng nhẹ, và giờ nó là một công nghệ nhàm chán nên ngược lại lại tốt
Hệ sinh thái cũng khổng lồ, một ví dụ là khó thay thế các thư viện như React Query
Vì vậy tôi dự định sẽ tiếp tục dùng React trong vài năm tới, nhất là vì React Compiler đã được dùng nội bộ ở Facebook và Instagram và đã ra bản beta công khai
React Native cũng hỗ trợ React Compiler, và tôi nghĩ hỗ trợ này sẽ ngày càng tốt hơn chứ không biến mất
Khi React Compiler xuất hiện, runes của Svelte hay bản chất được biên dịch của nó sẽ không còn nhiều đất diễn
Sau runes, Svelte cho cảm giác không còn là viết JavaScript nữa mà là dùng một ký pháp trông giống JavaScript, nên tôi không thích; còn sau React Compiler, trong các tình huống phức tạp cũng sẽ không cần quá nhiều địa ngục hooks nữa
Tôi đã dùng React 10 năm, Svelte trong 3 năm gần đây, và Svelte rõ ràng là framework thế hệ mới hơn; với tôi nó hợp hơn React rất nhiều
Tuy nhiên tôi đồng ý rằng quanh hệ sinh thái vẫn còn những chỗ gồ ghề
Hiệu năng cũng tốt hơn nhiều, dù với nhiều mục đích có thể không quan trọng
Nhược điểm là Svelte trên thực tế là một ngôn ngữ, nên để nó hoạt động đúng cần compiler và công cụ phát triển chuyên dụng
Duy trì và phát triển những thứ đó đòi hỏi rất nhiều nỗ lực
Tôi thích Svelte và đã dùng gần như hằng ngày trong vài năm, nhưng để đội ngũ đạt được tầm nhìn và duy trì lâu dài thì cần nhiều nguồn lực hơn
Thật đáng ngạc nhiên khi các tập đoàn lớn như Apple đưa Svelte vào những nơi như Apple Music nhưng lại không đầu tư
https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c321...
Không biết có ai biết vì sao họ đi theo hướng này không
Nue là một web framework đang được xây dựng để cắt bỏ sự phình to của phát triển web hiện đại
Nếu một nút Vite/ShadCN/Tailwind nặng hơn 40% so với một SPA hoàn chỉnh, thì đã đến lúc làm khác đi
Nó đang được xây dựng lại từ nền tảng, ưu tiên chuẩn web và nhằm loại bỏ sự cồng kềnh
Dành cho các kiến trúc sư frontend, design engineer và người làm UX muốn một quy trình làm việc đơn giản hơn, tỉnh táo hơn
Vẫn đang trong quá trình phát triển, nhưng thay đổi đang đến
Đây là một mô hình phức tạp và kém hiệu quả, chỉ nên dùng cho các ứng dụng có tương tác cực cao như Photoshop hay Ableton Live trên web, và những ứng dụng như vậy nên rất ít
Tôi không phải frontend developer, nhưng nếu vấn đề là “tìm kiếm và thao tác tức thì trên 150 nghìn bản ghi” thì có vẻ nên suy nghĩ lại mô hình
Xem demo thì có vẻ có khoảng 100KB mã WASM không được tính đến trong phần so sánh nút React
Dù vậy xin chúc mừng dự án, và tôi thật sự tò mò xem tầm nhìn tổng thể sẽ được hoàn thiện ra sao
Nếu tính cả framework thì dung lượng sẽ tăng, nhưng các framework như vậy không được thiết kế cho một component đơn lẻ
Phải so sánh trong điều kiện tương đương thì mới công bằng
Nếu vậy, tôi tò mò Nue so với htmx hoặc các framework khác tận dụng chuẩn web hiện đại thì thế nào
Nó giống như nói UI dựa trên Visual Studio nhẹ hơn vậy
Tôi ước bài marketing này có chi tiết kỹ thuật thay vào đó
Ví dụ tôi muốn biết nó dùng cách nào để theo dõi thay đổi, là proxy kiểu Vue hay tính toán lại toàn bộ kiểu React
Ngoài ra tôi cũng không hiểu câu JavaScript “tràn stack” với 150 nghìn object
Tôi thử tự tạo một danh sách 150 nghìn object thì trên profiler, mảng và object dùng khoảng 14MB, và ngay cả khi chạy
list.find()không có index cũng không bị stack overflowNếu dùng index thì có lẽ sẽ rất nhanh và không cần WASM hay cơ chế phức tạp nào
JavaScript không chậm đến vậy
Nếu làm tính toán số học như nhân các số trong mảng lớn, mã sẽ được biên dịch và chạy khá nhanh
list.push(...objects), và có vẻ đó là nguyên nhânKhi truyền rất nhiều đối số bằng spread operator, chẳng hạn khoảng 100 nghìn đối số, vào một method cùng lúc, trong JavaScript mỗi đối số được đưa lên call stack nên được biết là sẽ gây stack overflow
Phần lớn framework mới đều bắt đầu như một phương án nhẹ hơn so với các lựa chọn trưởng thành hơn vào thời điểm đó
Chỉ điều này thôi không phải là lý do để áp dụng
Hãy quay lại đăng sau 10 năm nữa, sau khi đã thêm tất cả sự phình to mà người dùng yêu cầu và xử lý mọi trường hợp ngoại lệ mà hiện giờ còn chưa hiểu
Nếu khi đó nó vẫn nhẹ hơn một nút React thì mới đáng đưa tin
Nếu không thể nói về nó so với các tay chơi hiện có, tôi không hiểu làm sao thu hút đủ người dùng cần thiết để nó phình to được
Tùy cách tính thì đã được phát triển khoảng 6–9 năm rồi mà vẫn rất gọn
Tôi bắt đầu dùng Svelte để phát hành một widget có yêu cầu thấp dưới dạng web component, và với mục đích đó thì nó rất tuyệt
Những câu hỏi nảy ra khi xem dự án
Tôi không rõ vì sao demo https://mpa.nuejs.org/app/ lại ấn tượng, và tôi nghĩ cũng có thể tạo một web app có hiệu năng tương tự bằng React
Tôi muốn xem nhanh ví dụ code ở trang chủ nhưng lại phải lục tài liệu; xem https://nuejs.org/docs/view.html#clean-html-templating thì tự hỏi liệu nó có được lấy cảm hứng từ Svelte không
Tôi cũng muốn biết Nue nhanh và nhẹ hơn thế nào so với các công nghệ khác, đặc biệt là HTML/JavaScript thuần
Để thuyết phục rằng Nue là một framework đáng dùng, nó phải đơn giản hơn HTML+JS, hoặc ít nhất là đơn giản hơn React; markup và logic phải gần với những thứ đã quen thuộc như HTML để dễ hiểu; và trải nghiệm lập trình viên phải tốt nhờ thời gian build tốt cùng HMR
Phần này có vẻ làm tốt
Ngoài ra, cần cho thấy các chỉ số và lợi thế kỹ thuật như overhead thấp, có dựa trên WASM hay không, virtual DOM, server islands, v.v.
esbuild đã làm rất tốt điều này: https://esbuild.github.io/
Nếu tác giả dự án muốn nói rằng nút của React nặng 73KB vì nó không hoạt động nếu không có thư viện React, thì đó là một lập luận yếu
Vì trong bundle ứng dụng ở thời điểm đó, thư viện React cũng được tái sử dụng ở các phần khác
Nó gây hiểu nhầm cho mọi người, và lời hứa hẹn quá nông đến mức gần như có cảm giác xúc phạm
Để nói rõ hơn, một nút duy nhất được cài theo tài liệu chính thức của ShadCN/Vite (https://ui.shadcn.com/docs/installation/vite) sẽ nặng hơn nhiều so với một Nue SPA hoàn chỉnh
Tôi không có ý công kích lập trình viên React, mà muốn cho thấy các chuẩn web có thể lật ngược cục diện phình to như thế nào
Tôi tự hỏi có cách nào diễn đạt phép so sánh này tốt hơn không
Tôi rất thích cách tiếp cận này, nhưng demo https://mpa.nuejs.org/app/ không hoạt động đúng trên iOS Safari
Tuy nhiên cũng có thể là do phiên bản 16.7.8 của tôi đã cũ
Không cuộn được, layout và nút có các chỗ xuống dòng lạ, và nút tìm kiếm native bị nhét vào trong nút thiết kế tuỳ chỉnh nên thành ra có 2 biểu tượng
Đó là một bản sửa nhanh
Triển khai ít tính năng hơn nhiều so với component đem ra so sánh, rồi cho thấy giải pháp của mình nhỏ đến mức nào
Trên Firefox, ô bình luận bị ẩn dưới thanh menu
Có lẽ chiều cao trang bị ép bằng phần trăm hoặc
vh, điều thường nên tránhNếu cần ép, nên dùng
svhhoặcdvhTôi thắc mắc có ví dụ code không
Tôi đã tìm một chút nhưng không thấy; với một bài blog về framework mới, tôi nghĩ ví dụ code nên nằm ngay ở đầu
nue create simple-blogcho thấy một website tập trung vào nội dungnue create simple-mpalà demo SPA hôm nay, trong đó MPA nghĩa là ứng dụng nhiều trangNó cho thấy client-side routing và view transition kết nối mượt mà các trang nhiều nội dung với những view giống ứng dụng như thế nào
Mã nguồn ở đây: https://github.com/nuejs/nue/tree/master/packages/examples