- Bun 1.0 JavaScript और TypeScript के रन, बिल्ड, टेस्ट और डिबग को एक ही टूल में संभालता है, और अब स्थिर व production-ready है
- Node.js के विकल्प के लक्ष्य के साथ यह
fs,path,net,__dirname,process,node_modulesresolution आदि Node API और module resolution को सपोर्ट करता है, और Express, Koa, Hono तथा Next.js, Remix, Nuxt, Astro, SvelteKit, Nest, SolidStart, Vite-आधारित application Bun पर चलती हैं - Windows के लिए native build पहली बार दिया गया है, लेकिन यह बहुत अधिक experimental है, और फिलहाल केवल JavaScript runtime को सपोर्ट करता है; package manager, test runner और bundler disabled हैं
- Bun 0.8 के बाद हुए बदलावों में Next.js, Astro, Nest.js सपोर्ट जोड़ा गया है, और बंद किए जा चुके
bun devकमांड को हटा दिया गया है, इसलिए अब यहpackage.jsonकी"dev"script चलाता है - नए सपोर्ट किए गए Node.js API में
child_process.fork()और IPC,fs.cp(),fs.cpSync(),fs.watchFile(),fs.unwatchFile(), औरnode:httpके Unix socket शामिल हैं - runtime में JavaScript transpiler built-in है, इसलिए
.js,.ts,.cjs,.mjs,.jsx,.tsxफाइलें बिना अलग dependency के चल सकती हैं - ESM और CommonJS दोनों एक साथ सपोर्ट होते हैं, इसलिए file extension या
package.jsonमें"type": "module"सेटिंग के बिना भी उसी फाइल मेंimportऔरrequire()का उपयोग किया जा सकता है fetch,Request,Response,WebSocket,ReadableStreamजैसे Web standard API built-in हैं, इसलिएnode-fetchऔरwsजैसे package के बिना इन्हें इस्तेमाल किया जा सकता है--hotविकल्प के साथ hot reloading का उपयोग किया जा सकता है, औरBun.serve()भी hot reloading के दायरे में आता है- Bun API के रूप में
Bun.file(),Bun.write(),Bun.serve(),bun:sqlite,Bun.passwordदिए गए हैं, जो file I/O, HTTP/WebSocket server, SQLite, bcrypt·argon2 password hash और verification को संभालते हैं - package manager
bun install,bun add,bun remove,bun updateदेता है, और यहpackage.jsonपढ़करnode_modulesमें लिखने वाला npm-compatible तरीका अपनाता है - test runner
bun:testJest-compatible API देता है, और@jest/globalsतथाvitestimport को अंदरूनी तौर परbun:testपर remap करता है - bundler JavaScript और TypeScript bundling तथा minify को सपोर्ट करता है, और esbuild-compatible plugin API के साथ bundle समय पर JavaScript function चलाकर values को inline करने वाले JavaScript macros भी देता है
1 टिप्पणियां
Hacker News की राय
मैं Bun development में शामिल हूँ। अगर सवाल हों तो जवाब दे सकता हूँ
अच्छा होगा अगर moderator link को blog post में बदल दें, क्योंकि वह GitHub release page से बेहतर समझाता है
blog post: https://bun.sh/blog/bun-v1.0
सबसे प्रभावशाली बात यह है कि
importऔरrequire()को एक ही file में इस्तेमाल किया जा सकता है, और.js/.cjs/.mjsया"type": "module"की चिंता नहीं करनी पड़तीइसके बिना Node.js ecosystem लगभग पूरी तरह टूटा हुआ लगता है, और Bun शायद उसे बचा सकता है। मेरे हिसाब से Bun की सबसे बड़ी चीज़ performance से ज़्यादा Jarred द्वारा लगातार किए गए practical और developer-friendly choices हैं
उसने बस अलग trade-off चुना है, और उसके चलते packages का कोई और set काम न करे, इसकी संभावना काफी है। मैं जानना चाहूँगा कि क्या कोई आधार है मानने का कि Bun ने वह रहस्य सुलझा लिया है जिसे दूसरे tools नहीं सुलझा पाए
मेरे हिसाब से यही सही तरीका है। Node के बंटे हुए ecosystem ने पूरी language और runtime को बहुत नुकसान पहुँचाया है
importबनामrequireकी वजह से कई घंटे परेशान रहाअगर आप React app या ready-made solution इस्तेमाल नहीं कर रहे हैं, तो modern JS ecosystem वाकई दर्दनाक है, खासकर छोटी library बनाने वाले के लिए। शुरुआत करने वालों के लिए यह कितना कठिन और सिर-खपाऊ होगा, कल्पना भी नहीं कर सकता
सिर्फ यह तथ्य कि Bun उस समस्या को solve करता है, उसे आज़माने की पर्याप्त वजह है। मैंने नहीं सोचा था कि एक और JS runtime या build tool को लेकर ऐसी उम्मीद महसूस होगी, और Bun team की वजह से लगता है मेरा दिन थोड़ा ज़्यादा sane रह पाएगा
bundlerresolution strategy आने के बाद पिछले 6 महीने कुल मिलाकर ठीक रहेबहुत कम बार problems आईं, लेकिन projects के fix करने तक
pnpm patchऔर metadata edits से workaround करता रहा। 2023 को modules का साल मान सकते हैं, और माहौल ठीक हैtype: moduleऔर.js/.cjs/.mjs/.tsसे रास्ता निकालते समय जितना बेवकूफ महसूस होता है, वैसा कभी नहींproduction apps में बेशक यह स्पष्ट होना चाहिए कि आप क्या इस्तेमाल कर रहे हैं, लेकिन prototyping में Bun के permissive behaviour की वजह से पहले code लिख सकते हैं और बाकी की चिंता बाद में कर सकते हैं
node:को पूरा implement न करने वाली 1.0 release के लिए drop-in replacement कहने से बेहतर wording नहीं मिल सकती थी क्या?जिन पहले दो projects पर मैंने कोशिश की, वे drop-in replacement नहीं निकले, इससे काफी निराशा हुई और अब Bun की सारी communication पर शक होने लगा है
context के लिए, दोनों projects
oscइस्तेमाल करते हैं, जिसेdgramचाहिए। 9 महीने पुराना feature request tracking ticket मिला, लेकिन implementation plan नहीं था, और इस announcement page परdgramsearch करने पर कुछ नहीं मिलताएक quick suggestion: Bun 1.0 में जिन modules का support नहीं है उन्हें साफ-साफ लिखकर Node.js compatibility section में डालना अच्छा होगा
edit: Node support docs मिल गए — https://bun.sh/docs/runtime/nodejs-apis . release notes में इसका link देना अच्छा होगा
सरसरी तौर पर देखने पर modules के हिसाब से लगभग 17 implemented, 17 partially implemented, और 7 unimplemented दिखते हैं
1.0.0से ज़्यादा1.0.0-betaजैसा लगता हैअभी v1.0.0 install करके
bun replचलाया, लेकिन exit code 1 के साथ fail हो गया; पता चला REPL port 3000 इस्तेमाल करने की कोशिश कर रहा था, जो मेरे environment में पहले से use में था। GitHub पर reported bugs देखकर लगता है ऐसी छोटी problems काफी होंगी, इसलिए सभी claims को कुछ हद तक skepticism से देखना चाहिएफिर भी speed और output ने बहुत गहरा impression छोड़ा। मुझे नहीं लगा था कि यह project इतनी जल्दी यहाँ तक पहुँच जाएगा; लगा था इसमें बहुत ज़्यादा समय लगेगा। तुलना करें तो Deno बहुत पहले शुरू हुआ था, लेकिन अब काफी पीछे लगता है, इसलिए personal projects में Bun आज़माने का सोच रहा हूँ
anecdotal तौर पर, करोड़ों मौजूदा customers वाली एक बड़ी application में Bun test कर रहे हैं, और अब तक एकमात्र problem Bun की नहीं बल्कि यह है कि
patch-packageअभीbun.lockblock file support नहीं करताBun निःसंदेह Yarn से बहुत तेज़ है। यह मैं Yarn को सच में पसंद करने वाले व्यक्ति के तौर पर कह रहा हूँ
“Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.”
detailed list में unsupported modules साफ बताए गए हैं
response parsing के दौरान error आने से AWS SDK v3 इस्तेमाल नहीं कर सका, और
node:cryptoपूरी तरह implemented न होने सेoctokitयाjsonwebtokenपर निर्भर चीज़ें इस्तेमाल नहीं कर सका।jest.resetAllMocks()नहीं है, इसलिए tests नहीं चला सका, और एक दूसरे project मेंbun testshared library call गलत बताकर बिल्कुल चला ही नहींइसलिए local workflow है: “Bun से run करके देखो, fail हो तो Node से फिर run करो।” कम-से-कम npm replacement के रूप में इस्तेमाल किया जा सकता है, लेकिन अभी services चलाने के लिए इसका इस्तेमाल सोचना मुश्किल है। जब यह काम करता है तो सच में शानदार लगता है, इसलिए भविष्य को लेकर उत्साह है, लेकिन अगर selling point Node compatibility है तो इसे 1.0 कहना मुश्किल लगता है
उत्सुकता है कि क्या community chat को Discord के बजाय किसी और platform पर ले जाने पर विचार हुआ था
Discord accessibility, privacy और proprietary platform lock-in की वजह से HN पर कई बार चर्चा में रहा है, और यह open source की भावना से भी बहुत मेल खाता नहीं दिखता। [1] भी देखने लायक है
[1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...
Bun 0.6 announcement के comments में भी ऐसा ही सवाल लगभग flag होने जितने downvotes पा गया था: https://news.ycombinator.com/item?id=35970869
Bun 0.8 announcement के comments में भी वही सवाल लगभग ध्यान नहीं खींच पाया, और प्रतिक्रिया कुछ ऐसी थी कि “दूसरे projects भी तो सब इस्तेमाल करते हैं…”: https://news.ycombinator.com/item?id=37244294
सच कहें तो Discord free और open source software projects के लिए communication रखने की अच्छी जगह है। लेख में यह दावा कि “Discord चुनने से आप उस platform को वैधता देते हैं और FOSS platforms से value छीनते हैं” काफी कमजोर लगता है। Discord सच में एक वैध platform है, free है, इसमें कई आकर्षक features हैं और accessibility भी अच्छी है। सबसे बढ़कर, Discord चुनने से FOSS communication platforms की value खत्म नहीं हो जाती
“IRC इस्तेमाल करो” कहना भी सही नहीं है। Computers और software से परिचित न होने वाले बहुत से लोगों के लिए IRC बहुत मुश्किल से accessible है
Bun venture funding पर आधारित है, इसलिए इसकी monetization plan को लेकर जिज्ञासा है
नई technology देखते समय मैं सोचता हूं कि “N साल बाद भी इस technology के actively develop होने की कितनी संभावना है।” Bun को किसी न किसी तरह पैसा कमाना होगा, वरना funding बंद हो जाएगी
Bun का license MIT होना शानदार है और यह उम्मीद देता है कि company बंद हो जाए तो भी project मरना जरूरी नहीं। मैं चाहता हूं company सफल हो, लेकिन अगर Bun adopt करता हूं तो जानना चाहूंगा कि आगे चलकर किस तरह की upsell होगी
Oven backend और frontend JavaScript apps के लिए बेहद तेज serverless hosting और continuous integration देगा, और यह Bun से powered होगा
यह Next.js, Vite, SvelteKit, SolidStart जैसे frontend frameworks और Express, Fastify, NestJS जैसे backend frameworks को support करेगा
योजना दुनिया भर के datacenters के edge पर अपने servers चलाने की है, और Oven JavaScript stack को hardware तक end-to-end integrate करके नई संभावनाएं बनाना चाहता है
bun deployजैसी किसी चीज के जरिए JS app hosting से पैसा कमाएगापहले बड़े पैमाने पर developer adoption हासिल करना, फिर उन्हें धीरे-धीरे अपनी application hosting की ओर ले जाना—यह एक आम strategy है
एक व्यक्ति के side project का पीछा करते-करते इतनी मेहनत करनी पड़ी कि सब कुछ Rollup पर ले गया और फिर पीछे मुड़कर नहीं देखा
Venture-funded project और किसी random side project की चिंताएं साफ तौर पर अलग हैं, लेकिन अंतिम risk दोनों में यही है: “अगर बनाने वाला मुझे support न कर पाया तो क्या होगा”
सब कुछ “open source” के रूप में promote करके free bug reports, contributions, marketing और adoption हासिल करना, फिर उसे commercial product की ओर धकेलना—यही तरीका है
Node-based tools की परत-दर-परत बनी अव्यवस्था को replace कर पाने का प्रस्ताव बहुत आकर्षक है
क्योंकि इससे
node,ts-node,nodemon,tsc,jest,ts-jest,webpack, Babel, आपस में मेल न खाने वाली 2 module specifications, UMD की उलझन, 3 package managers और उनकी वजह से तेजी से बढ़ती configuration files कम हो सकती हैंJavaScript के आसपास का tooling environment निश्चित रूप से सबसे बड़ा pain point है, और यह ES6 + TypeScript जैसी मूल रूप से काफी सक्षम और pleasant language को पूरी तरह झंझट बना देता है। उम्मीद है Bun यह कर पाएगा
यह शायद CMake से Cargo पर जाने जैसा महसूस होगा
Blog post ज्यादा सरल all-in-one software के value proposition को बहुत convincing तरीके से दिखाता है
इन दिनों “सब कुछ खुद लेकर आओ” के बजाय “batteries included” software ज्यादा आकर्षित करता है, इसलिए Bun आजमाने का इंतजार है
यह उन Rome tools के runtime version जैसा लगता है, जो कई software को एक तेज tool से replace करना चाहते थे। Rome असफल हुआ और नई team के OSS में बदल गया। उम्मीद है Bun ज्यादा सफल होगा, लेकिन यह निश्चित रूप से हल करने के लिए कठिन समस्या है
Apple की तरह अगर आप hardware और operating system को खुद own और control करते हैं, तो system को गहराई से optimize कर सकते हैं और यह भरोसा भी दे सकते हैं कि सभी devices smoothly काम करेंगे। All-in-one tool suite perfect solution खोजने के लिए इधर-उधर भागने का बोझ घटाता है और सामने मौजूद solution इस्तेमाल करने देता है
जिन लोगों ने Bun और Deno दोनों इस्तेमाल किए हैं, उनसे सुनना चाहूँगा कि असल में कौन सा ज़्यादा भरोसेमंद Node successor लगता है
Bun की वेबसाइट दावा करती है कि इसकी performance Deno से कहीं बेहतर है, लेकिन जानना चाहता हूँ कि क्या सच में ऐसा है। अगर है, तो क्यों, यह भी जानना चाहूँगा। Deno के भी मिलते-जुलते लक्ष्य दिखते हैं
यह भी जानना चाहता हूँ कि क्या दोनों projects के बीच बड़ा philosophical difference है। जैसे, शायद Bun हर चीज़ को फिर से implement करना चाहता है, और Deno Node के बाद का कोई नया तरीका चाहता है—ऐसा कुछ? क्या कोई है जिसने दोनों को पर्याप्त इस्तेमाल किया हो?
Bun और Deno दोनों venture-funded tools हैं, इसलिए monetization और long-term sustainability को लेकर बुनियादी शक है
Bun का मुख्य selling point performance लगता है, लेकिन Node में मैंने बड़े performance issues बहुत कम झेले हैं। यह बेहद तेज़ नहीं है, पर Node की speed से पहले I/O constraints से टकराने की संभावना कहीं ज़्यादा होती है
Deno का मुख्य selling point बेहतर packaging, ES6 का पूरा इस्तेमाल वगैरह कई मायनों में “ठीक से बनाया गया Node” था, और वह दावा आकर्षक लगा था, लेकिन लगता है कि नया ecosystem बनाने की कोशिश छोड़कर Node compatibility जोड़ने की तरफ चला गया है
साथ ही, Node के अपने test runner और built-in
.envsupport जैसी हाल की improvements उत्साहजनक हैं। इसलिए Bun या Deno इस्तेमाल करने की कोई मजबूत वजह ढूँढना मुश्किल है, और अगर switch भी करूँ तो नई पीढ़ी के tools के unsustainable हो जाने पर Node पर वापस लौटने का ठोस रास्ता चाहिएBun सब कुछ साथ में bundle करके बहुत तेज़ बनाता है, और जहाँ तक हो सके Node compatibility बनाए रखने की कोशिश करता है। यह मौजूदा ecosystem को छोड़ता नहीं है
Deno ने Node ecosystem के प्रति बहुत टकराव वाला दृष्टिकोण अपनाया था, और अब फिर से support जोड़ रहा है
successor के नज़रिए से Bun ही एकमात्र विकल्प लगता है। क्योंकि यह Node compatibility बनाए रखते हुए नए features से innovate करने की कोशिश करता है
Deno security को first principle मानने वाला alternative Node runtime ज़्यादा लगता है, और इसमें TypeScript व JSX का built-in support, linter जैसे tools भी शामिल हैं। यह V8-based भी है। देर से ही सही, यह Ryan Dahl के उस विचार के करीब दिखता है कि Node को कैसा होना चाहिए था
Bun technically WebKit-based है, हालांकि ठीक-ठीक क्यों, यह नहीं पता, और यह सिर्फ runtime नहीं बल्कि बेहतर all-in-one tool जैसा लगता है। यह मौजूदा frameworks के साथ भी default compatibility देता है। Deno कुछ समय पहले तक npm-compatible नहीं था, और मैं सोचता हूँ कि क्या शुरू से उसका इरादा यही था या फिर बीच में direction बदली गई
पिछले महीने हमने alternative runtime के तौर पर Deno और Bun दोनों test किए। संक्षेप में, थोड़े complex codebase में Bun लगभग हमेशा चलता है और Deno लगभग हमेशा नहीं चलता
अभी हम सारे tests Node.js और Bun दोनों पर चला रहे हैं, और Deno adopt करने की कोशिश छोड़ दी है
Edit: लगता है यह बदल रहा है। सुधार के लिए धन्यवाद
मूल योजना कल release करने की थी, लेकिन
fetch()body streaming test में एक failure था जिसे fix करना थाblog post को Bun 1.0 के GitHub पर आने तक public नहीं होना था, लेकिन link publicly accessible था और RSS feed में drafts छिपा न पाने वाला bug था
असली bug
fetch()body streaming में नहीं था, बल्कि JavaScriptCore binding में था, जहाँ किसी ऐसे object से property ली जा रही थी जिसकी property defined न भी हो सकती थी। code के एक हिस्से ने यह check नहीं किया कि value object है या नहीं, सिर्फ इतना check किया कि वहJSCellहै;JSCellआम तौर पर object होता है, लेकिन symbol या BigInt जैसी चीज़ेंJSObjectनहीं होतींकल की thread: https://news.ycombinator.com/item?id=37424724
एक अतिरिक्त hint के तौर पर, “distro repository नहीं, internet से download करके install” करने के तरीके के लिए सही SHA-256 जैसे checksum के साथ Ansible playbook/taskset examples दिए जा सकते हैं। Puppet के लिए भी ऐसा ही, हालांकि वह थोड़ा ज़्यादा complex होगा
इससे system administrators का थोड़ा काम कम हो सकता है, और अगर इसे कोई नाम देना चाहें तो SAX, यानी system administrator experience कह सकते हैं
अगर Bun TypeScript React ऐप को सीधे चला और bundle कर सकता है, तो उसके ऊपर Vite.js इस्तेमाल करने का फायदा क्या है, यह जानने की जिज्ञासा है
आधिकारिक साइट की guide TypeScript React ऐप बनाते समय Bun + Vite.js इस्तेमाल करने का तरीका दिखाती है, इसलिए confusion होता है। [1]
GitHub पर भी इससे जुड़ा issue है। [2]
क्या Vite.js उन ज़्यादा complex scenarios या advanced use cases को संभालता है जिन्हें Bun handle नहीं कर पाता? मेरा Vite.js इस्तेमाल बस basic TS+React setup से शुरू करके build करने तक है, इसलिए हो सकता है मैं कुछ miss कर रहा हूँ
[1] https://bun.sh/guides/ecosystem/vite
[2] https://github.com/oven-sh/bun/issues/250
मैंने अभी Bun इस्तेमाल करके नहीं देखा है, लेकिन मेरी समझ है कि local dev server चलाने के लिए Node की जगह Bun, bundling के लिए esbuild या tsc, Rollup या उनके combination की जगह Bun, और transformation के लिए Babel और TypeScript की जगह Bun इस्तेमाल किया जा सकता है
Vite जो देता है वह frontend application development को आसानी से configure करने और local काम के दौरान अच्छा developer experience देने वाली configuration है
अभी इसमें configuration complexity है, इसलिए मुझे नहीं लगता कि दोनों को combine करना बहुत अच्छा है
मौजूदा ecosystem के साथ compatibility Bun का core goal है, इसलिए मकसद यह है कि लोग इसे अपने existing codebase में तुरंत इस्तेमाल करना शुरू कर सकें और धीरे-धीरे और हिस्सों में अपना सकें
और Nuxt, SvelteKit, Astro, SolidStart, Qwik जैसे ज़्यादातर नए meta frameworks Vite पर चलते हैं, इसलिए Bun adoption का रास्ता खुल सकता है
tscहोने पर Vite की जरूरत क्यों हैमुझे लगता है Bun “TypeScript React ऐप चलाता है” से ज़्यादा, JSX/TSX transformation built-in देता है