Bun v1.0.0 - Bộ công cụ all-in-one nhanh để chạy, build, test và debug JavaScript và TypeScript
(bun.sh)- Bun 1.0 xử lý việc chạy, build, test và debug JavaScript và TypeScript trong một công cụ duy nhất, đã được ổn định hóa và sẵn sàng cho production
- Nhắm tới vai trò thay thế Node.js, Bun hỗ trợ Node API và cơ chế phân giải module như
fs,path,net,__dirname,process, phân giảinode_modules, đồng thời các ứng dụng dựa trên Express, Koa, Hono cũng như Next.js, Remix, Nuxt, Astro, SvelteKit, Nest, SolidStart, Vite đều chạy được trên Bun - Bản build native cho Windows được cung cấp lần đầu nhưng mang tính thử nghiệm cao, hiện chỉ hỗ trợ JavaScript runtime và đã vô hiệu hóa package manager, test runner và bundler
- Trong các thay đổi từ Bun 0.8, hỗ trợ cho Next.js, Astro, Nest.js đã được bổ sung, và lệnh
bun devtừng bị ngừng hỗ trợ đã bị loại bỏ, giờ đây sẽ chạy script"dev"trongpackage.json - Các Node.js API mới được hỗ trợ gồm
child_process.fork()và IPC,fs.cp(),fs.cpSync(),fs.watchFile(),fs.unwatchFile(), và Unix socket củanode:http - Runtime tích hợp sẵn JavaScript transpiler, cho phép chạy các file
.js,.ts,.cjs,.mjs,.jsx,.tsxmà không cần dependency riêng - Hỗ trợ đồng thời ESM và CommonJS, nên có thể dùng
importvàrequire()trong cùng một file mà không cần phần mở rộng file hay cấu hình"type": "module"trongpackage.json - Tích hợp sẵn các Web Standard API như
fetch,Request,Response,WebSocket,ReadableStream, nên có thể dùng mà không cần các package nhưnode-fetchhayws - Có thể dùng hot reloading với tùy chọn
--hot, vàBun.serve()cũng nằm trong phạm vi áp dụng hot reloading - Bun API cung cấp
Bun.file(),Bun.write(),Bun.serve(),bun:sqlite,Bun.passwordđể xử lý I/O file, máy chủ HTTP/WebSocket, SQLite, cũng như hash và xác minh mật khẩu bằng bcrypt·argon2 - Package manager cung cấp
bun install,bun add,bun remove,bun update, theo cách tương thích npm: đọcpackage.jsonvà ghi vàonode_modules - Test runner
bun:testcung cấp API tương thích Jest, đồng thời ánh xạ lại import@jest/globalsvàvitestnội bộ sangbun:test - Bundler hỗ trợ bundling và minify JavaScript, TypeScript, cung cấp plugin API tương thích esbuild và JavaScript macros để chạy hàm JavaScript tại thời điểm bundle rồi inline giá trị
1 bình luận
Ý kiến trên Hacker News
Tôi đang tham gia phát triển Bun. Nếu có câu hỏi thì tôi có thể trả lời
Mong moderator đổi liên kết sang bài blog. Vì phần giải thích ở đó tốt hơn trang phát hành trên GitHub
Bài blog: https://bun.sh/blog/bun-v1.0
Điều ấn tượng nhất là có thể dùng
importvàrequire()trong cùng một file, và không cần bận tâm đến.js/.cjs/.mjshay"type": "module"Nếu không có điều này thì hệ sinh thái Node.js gần như ở trạng thái hỏng hoàn toàn, và Bun có vẻ có thể cứu nó. Tôi cho rằng điều tuyệt vời nhất ở Bun không phải hiệu năng, mà là những lựa chọn thực dụng và thân thiện với lập trình viên mà Jarred đã kiên trì theo đuổi
Chỉ là họ chọn một thỏa hiệp khác, và kết quả có khả năng là một tập hợp package khác lại không hoạt động. Tôi tò mò liệu có cơ sở nào để nói Bun đã giải được bí mật mà các công cụ khác không giải được không
Theo tôi, đây là cách đúng. Hệ sinh thái bị chia cắt của Node đã gây hại lớn cho toàn bộ ngôn ngữ và runtime
importso vớirequireNếu không dùng ứng dụng React hay giải pháp có sẵn, hệ sinh thái JS hiện đại thực sự rất đau khổ, đặc biệt là khi tạo một thư viện nhỏ. Không thể tưởng tượng nổi nó khó và phát điên đến mức nào với người mới bắt đầu
Chỉ riêng việc Bun giải quyết vấn đề đó đã là đủ lý do để thử. Tôi không ngờ mình lại có cảm giác kỳ vọng như vậy với thêm một JS runtime hay công cụ build nữa, và hy vọng nhờ đội Bun mà một ngày của tôi sẽ tỉnh táo hơn một chút
bundler, 6 tháng qua nhìn chung khá ổnRất hiếm khi có vấn đề, nhưng trước khi các dự án sửa thì tôi đã đi vòng bằng
pnpm patchvà chỉnh metadata. Có thể xem 2023 là năm của module, và tình hình cũng ổntype: modulevà.js/.cjs/.mjs/.tsTrong ứng dụng production thì tất nhiên phải rõ ràng mình dùng gì, nhưng khi prototype, nhờ hành vi khoan dung của Bun mà có thể viết code trước rồi lo phần còn lại sau
Tôi nghĩ có lẽ nên dùng một cách diễn đạt tốt hơn drop-in replacement cho bản phát hành 1.0 khi chưa triển khai toàn bộ
node:Tôi đã khá thất vọng khi hai dự án đầu tiên thử đều không thể thay thế thả vào là chạy, và giờ tôi bắt đầu nghi ngờ mọi thông điệp truyền thông của Bun
Để có bối cảnh, cả hai dự án đều dùng
osc, vốn cầndgram. Tôi tìm thấy một ticket theo dõi yêu cầu tính năng từ 9 tháng trước nhưng không có kế hoạch triển khai, và tìmdgramtrên trang công bố lần này cũng không ra gìGợi ý nhanh là nên nêu rõ các module mà Bun 1.0 chưa hỗ trợ và đưa vào phần tương thích Node.js
Sửa: Tôi đã tìm thấy tài liệu hỗ trợ Node — https://bun.sh/docs/runtime/nodejs-apis . Sẽ tốt hơn nếu liên kết nó trong release note
Nhìn sơ qua thì theo module có khoảng 17 cái đã triển khai, 17 cái triển khai một phần, và 7 cái chưa triển khai
1.0.0-betahơn là1.0.0Tôi vừa cài v1.0.0 và chạy
bun replthì thất bại với exit code 1, hóa ra REPL cố dùng cổng 3000, mà trong môi trường của tôi thì cổng đó đã được dùng. Nhìn các bug được báo trên GitHub, có vẻ sẽ còn khá nhiều vấn đề nhỏ kiểu này, nên có lẽ cần hoài nghi ở mức nào đó với mọi tuyên bốDù vậy tôi vẫn cực kỳ ấn tượng với tốc độ và kết quả đạt được. Tôi không nghĩ dự án này lại tiến đến đây nhanh như vậy, và đã tưởng sẽ mất lâu hơn nhiều. So sánh thì Deno bắt đầu sớm hơn nhiều nhưng giờ có cảm giác tụt khá xa, nên tôi định thử dùng Bun cho các dự án cá nhân
Theo kinh nghiệm cá nhân, chúng tôi đang thử Bun trên một ứng dụng lớn có hàng triệu khách hàng hiện hữu, và vấn đề duy nhất cho đến nay không phải bản thân Bun, mà là
patch-packagevẫn chưa hỗ trợ file khóabun.lockbBun chắc chắn nhanh hơn Yarn rất nhiều. Tôi nói điều đó với tư cách là người thật sự thích Yarn
“Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.”
Danh sách chi tiết có nêu rõ các module không được hỗ trợ
AWS SDK v3 không dùng được vì lỗi khi phân tích response, và vì
node:cryptochưa được triển khai đầy đủ nên không dùng được những thứ phụ thuộc vàooctokithoặcjsonwebtoken. Không cójest.resetAllMocks()nên không chạy được test, và ở một dự án khác,bun testnói lời gọi thư viện dùng chung bị sai rồi hoàn toàn không chạyVì vậy workflow cục bộ là “chạy thử bằng Bun, nếu thất bại thì chạy lại bằng Node”. Ít nhất có thể dùng như một thay thế cho npm, nhưng hiện vẫn khó tưởng tượng dùng nó để chạy service. Khi chạy tốt thì thật sự đáng kinh ngạc nên tôi rất mong chờ tương lai, nhưng nếu điểm bán hàng là tương thích Node thì tôi nghĩ khó có thể gọi là 1.0
Tôi tò mò liệu đã từng có ý định chuyển phần chat cộng đồng sang một nền tảng không phải Discord chưa
Discord đã nhiều lần được nhắc đến trên HN vì các vấn đề về khả năng tiếp cận, quyền riêng tư và sự phụ thuộc vào nền tảng độc quyền, và có vẻ cũng không thật sự phù hợp với tinh thần mã nguồn mở. [1] cũng đáng tham khảo
[1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...
Trong phần bình luận công bố Bun 0.6, một câu hỏi tương tự cũng bị downvote đến mức gần như bị gắn cờ: https://news.ycombinator.com/item?id=35970869
Trong phần bình luận công bố Bun 0.8, cùng câu hỏi đó cũng hầu như không nhận được sự quan tâm, phản ứng chỉ kiểu “các dự án khác cũng đều dùng mà…”: https://news.ycombinator.com/item?id=37244294
Thành thật mà nói, Discord là một nơi tốt để các dự án phần mềm tự do/mã nguồn mở đặt kênh liên lạc cộng đồng. Những lập luận trong bài rằng “chọn Discord là hợp thức hóa nền tảng đó và lấy đi giá trị khỏi các nền tảng FOSS” trông khá yếu. Discord thực tế là một nền tảng chính đáng, miễn phí, có nhiều tính năng hấp dẫn và khả năng tiếp cận tốt. Quan trọng hơn, việc chọn Discord không làm mất đi giá trị của các nền tảng giao tiếp FOSS
Nói “hãy dùng IRC” cũng không đúng. IRC rất khó tiếp cận với nhiều người không quen với máy tính và phần mềm
Bun được hậu thuẫn bởi vốn đầu tư mạo hiểm, nên tôi tò mò về kế hoạch kiếm tiền
Khi nhìn vào công nghệ mới, tôi cân nhắc “khả năng công nghệ này vẫn được phát triển tích cực sau N năm nữa”. Bun cần kiếm tiền theo cách nào đó, nếu không thì nguồn vốn sẽ cạn
Việc giấy phép của Bun là MIT là rất tuyệt, và đem lại hy vọng rằng dự án có thể không chết ngay cả khi công ty thất bại. Tôi mong công ty thành công, nhưng nếu đưa Bun vào sử dụng, tôi muốn biết sau này sẽ có những kiểu upsell nào
Oven sẽ cung cấp serverless hosting và tích hợp liên tục rất nhanh cho các ứng dụng JavaScript backend và frontend, và dự kiến sẽ chạy bằng Bun
Dự kiến hỗ trợ các framework frontend như Next.js, Vite, SvelteKit, SolidStart và các framework backend như Express, Fastify, NestJS
Kế hoạch là vận hành máy chủ riêng ở edge của các trung tâm dữ liệu trên toàn thế giới, và Oven muốn tích hợp đầu cuối toàn bộ JavaScript stack xuống đến phần cứng để tạo ra những khả năng mới
bun deployĐây là chiến lược phổ biến: trước hết đạt được mức độ chấp nhận lớn từ developer, rồi dẫn dắt một cách nhẹ nhàng sang hosting ứng dụng của riêng mình
Tôi đã quá vất vả khi cố theo một side project của một người, nên đã chuyển toàn bộ sang Rollup và không ngoái lại
Mối lo của một dự án có vốn đầu tư mạo hiểm và một side project ngẫu nhiên rõ ràng là khác nhau, nhưng rủi ro cuối cùng của cả hai đều là “nếu người tạo ra nó không thể hỗ trợ mình nữa thì sao”
Tức là quảng bá mọi thứ là “mã nguồn mở” để nhận bug report miễn phí, đóng góp, marketing và sự chấp nhận, rồi đẩy người dùng vào sản phẩm thương mại
Đề xuất rằng nó có thể thay thế mớ hỗn loạn nhiều tầng của các công cụ dựa trên Node rất hấp dẫn
Vì nó có thể giảm bớt
node,ts-node,nodemon,tsc,jest,ts-jest,webpack, Babel, 2 đặc tả module không tương thích với nhau, sự rối rắm của UMD, 3 trình quản lý gói và số lượng file cấu hình bùng nổ kéo theoHệ sinh thái công cụ quanh JavaScript chắc chắn là nỗi đau lớn nhất, biến ES6 + TypeScript, vốn là một ngôn ngữ khá có năng lực và dễ chịu, thành toàn việc lặt vặt. Hy vọng Bun làm được
Có lẽ cảm giác sẽ giống như khi chuyển từ CMake sang Cargo
Bài blog cho thấy rất thuyết phục đề xuất giá trị của phần mềm all-in-one đơn giản hơn
Dạo này tôi bị hấp dẫn bởi phần mềm “kèm sẵn pin” hơn là “tự mang mọi thứ đến”, nên rất mong được dùng thử Bun
Nó có cảm giác như phiên bản runtime của bộ công cụ Rome, vốn cũng từng cố thay nhiều phần mềm bằng một công cụ nhanh hơn. Rome đã thất bại và chuyển thành OSS bởi một đội mới. Tôi hy vọng Bun thành công hơn, nhưng rõ ràng đây là vấn đề khó giải
Nếu bạn trực tiếp sở hữu và kiểm soát phần cứng lẫn hệ điều hành như Apple, bạn có thể tối ưu hệ thống sâu hơn, đồng thời tạo sự yên tâm rằng mọi thiết bị sẽ hoạt động trơn tru. Bộ công cụ all-in-one giúp giảm gánh nặng phải chạy khắp nơi tìm giải pháp hoàn hảo, và khiến ta dùng giải pháp đã có ngay trước mắt
Với những ai đã dùng cả Bun lẫn Deno, tôi muốn nghe xem trong thực tế bên nào thuyết phục hơn với tư cách là người kế nhiệm Node
Trang web của Bun tuyên bố hiệu năng tốt hơn Deno rất nhiều, nên tôi tò mò liệu thực tế có đúng vậy không. Nếu đúng thì cũng muốn biết vì sao. Deno dường như cũng có mục tiêu tương tự
Tôi cũng tò mò liệu giữa hai dự án có khác biệt lớn về triết lý hay không. Chẳng hạn như Bun muốn tái triển khai đủ thứ, còn Deno muốn một cách làm mới sau Node, kiểu vậy chăng. Có ai đã dùng đủ nhiều cả hai chưa?
Cả Bun lẫn Deno đều là công cụ dựa trên vốn đầu tư mạo hiểm, nên tôi có nghi ngờ căn bản về khả năng kiếm tiền và tính bền vững
Điểm bán hàng chính của Bun có vẻ là hiệu năng, nhưng tôi hiếm khi gặp vấn đề hiệu năng lớn với Node. Nó không phải cực nhanh, nhưng khả năng đụng trần I/O cao hơn nhiều so với bị giới hạn bởi tốc độ của Node
Điểm bán hàng chính của Deno là “một Node được làm đúng cách” ở nhiều mặt như đóng gói tốt hơn, dùng ES6 triệt để, v.v., và lập luận đó có sức hút với tôi, nhưng có vẻ họ đã từ bỏ nỗ lực tạo hệ sinh thái mới và chuyển sang thêm khả năng tương thích với Node
Đồng thời, các cải tiến gần đây của chính Node như test runner riêng và hỗ trợ
.envtích hợp sẵn là điều đáng khích lệ. Vì vậy khó tìm được lý do đủ mạnh để dùng Bun hay Deno, và kể cả nếu chuyển thì cũng cần một lộ trình cụ thể để quay lại Node khi các công cụ thế hệ mới trở nên không bền vữngBun gom mọi thứ lại và làm cho chúng rất nhanh, đồng thời cố giữ tương thích với Node nhiều nhất có thể. Nó không vứt bỏ hệ sinh thái hiện có
Deno đã có góc nhìn quá đối lập với hệ sinh thái Node, và giờ đang thêm lại hỗ trợ
Nhìn từ góc độ người kế nhiệm, tôi xem Bun là lựa chọn duy nhất. Vì nó cố duy trì tương thích Node trong khi đổi mới bằng các tính năng mới
Deno trông giống một runtime thay thế cho Node đặt bảo mật làm nguyên tắc ưu tiên hàng đầu hơn, đồng thời bao gồm cả hỗ trợ TypeScript và JSX tích hợp sẵn, các công cụ như linter. Nó cũng dựa trên V8. Có vẻ gần với hình dung muộn màng của Ryan Dahl rằng Node lẽ ra nên như thế này
Về mặt kỹ thuật Bun dựa trên WebKit, nhưng tôi không rõ chính xác vì sao, và nó trông không chỉ là runtime mà giống một công cụ all-in-one tốt hơn. Nó cũng cung cấp tương thích mặc định với các framework hiện có. Cho đến cách đây không lâu Deno chưa tương thích npm, và tôi cũng tò mò không biết ban đầu họ có chủ ý như vậy không hay đó là một sự đổi hướng đang diễn ra
Tháng trước chúng tôi đã thử cả Deno lẫn Bun làm runtime thay thế. Tóm lại, với một codebase phức tạp ở mức nào đó, Bun gần như luôn chạy được còn Deno gần như luôn không chạy được
Hiện chúng tôi đang chạy toàn bộ test trên cả Node.js lẫn Bun, và đã từ bỏ nỗ lực áp dụng Deno
Sửa: có vẻ điều này đang thay đổi. Cảm ơn đã đính chính
Ban đầu dự kiến phát hành hôm qua, nhưng có một lỗi test streaming phần thân
fetch()cần sửaBài blog không được dự định công khai trước khi Bun 1.0 được đưa lên GitHub, nhưng liên kết có thể truy cập công khai và có một bug khiến bản nháp không bị ẩn trong RSS feed
Bug thực sự không nằm ở streaming phần thân
fetch(), mà ở binding JavaScriptCore khi lấy thuộc tính từ một đối tượng mà thuộc tính có thể chưa được định nghĩa. Một phần mã chỉ kiểm tra xem giá trị có phải làJSCellhay không mà không kiểm tra nó có phải object không;JSCellthường là object, nhưng những thứ như symbol hay BigInt thì không phảiJSObjectThread hôm qua: https://news.ycombinator.com/item?id=37424724
Thêm một gợi ý nữa: với kiểu cài đặt “tải từ Internet thay vì từ kho của distro”, có thể cung cấp ví dụ playbook/taskset Ansible kèm checksum phù hợp như SHA-256. Puppet cũng tương tự, nhưng sẽ phức tạp hơn một chút
Điều này có thể giúp giảm chút việc cho quản trị viên hệ thống, và nếu muốn đặt tên thì có thể gọi là SAX, tức trải nghiệm quản trị viên hệ thống
Nếu Bun có thể chạy và bundle ứng dụng TypeScript React theo mặc định, tôi thắc mắc lợi ích của việc dùng Vite.js bên trên nó là gì
Hướng dẫn trên trang chính thức cho thấy cách dùng Bun + Vite.js khi tạo ứng dụng TypeScript React, nên khá khó hiểu. [1]
Trên GitHub cũng có issue liên quan. [2]
Có phải Vite.js đảm nhiệm các kịch bản phức tạp hơn hoặc các use case nâng cao mà Bun không xử lý được không? Việc tôi dùng Vite.js chỉ ở mức bắt đầu và build với thiết lập TS+React cơ bản, nên có thể tôi đang bỏ sót điều gì đó
[1] https://bun.sh/guides/ecosystem/vite
[2] https://github.com/oven-sh/bun/issues/250
Tôi chưa có kinh nghiệm dùng Bun, nhưng hiểu rằng có thể dùng Bun thay cho Node để chạy máy chủ phát triển cục bộ, dùng Bun thay cho esbuild hoặc tsc, Rollup hay sự kết hợp của chúng để bundle, và dùng Bun thay cho Babel và TypeScript để transform
Điều Vite cung cấp là cấu hình giúp dễ thiết lập việc phát triển ứng dụng frontend và mang lại trải nghiệm nhà phát triển tốt khi làm việc cục bộ
Hiện vẫn còn độ phức tạp về cấu hình, nên tôi không nghĩ việc kết hợp cả hai là quá tốt
Khả năng tương thích với hệ sinh thái hiện có là mục tiêu cốt lõi của Bun, nên họ muốn mọi người có thể bắt đầu dùng ngay trong codebase hiện có và dần dần đưa Bun vào nhiều phần hơn
Và vì hầu hết các meta framework mới như Nuxt, SvelteKit, Astro, SolidStart, Qwik đều chạy trên Vite, điều đó có thể mở ra lộ trình áp dụng Bun
tscrồi thì tại sao cần ViteTôi nghĩ Bun không hẳn “chạy ứng dụng TypeScript React”, mà đúng hơn là cung cấp sẵn chuyển đổi JSX/TSX