Bun 1.2 रिलीज़: Node.js compatibility, S3 और Postgres built-in

 (bun.sh)
1 पॉइंट द्वारा GN⁺ 2025-01-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Bun 1.2 full-stack JavaScript/TypeScript डेवलपमेंट टूल बनने के लक्ष्य के साथ, Node.js compatibility और runtime, bundler, testing व package manager को साथ में विस्तार देने वाली एक बड़ी रिलीज़ है
  • हर बदलाव पर Node.js test suite चलाकर compatibility verification को मजबूत किया गया है, और node:http2, node:dgram, node:cluster, node:zlib, node:v8 support जोड़ा गया है
  • नई built-in APIs Bun.s3 और Bun.sql S3-compatible object storage और Postgres access को runtime के अंदर लाती हैं, जिससे external client dependency घटती है
  • package manager ने default lockfile को binary bun.lockb से JSONC-based bun.lock में बदला है, और .npmrc, bun publish, bun patch, bun outdated, bun run --filter जोड़े हैं
  • bun run working directory, Bun.build() failure handling, server.stop() return value, bun -p, और sourcemap defaults बदल गए हैं, इसलिए मौजूदा projects को migration impact जांचना चाहिए

Node.js compatibility मजबूत की गई

  • Bun 1.2 ने compatibility सुधारने की प्रक्रिया बदलकर Bun में हर बदलाव पर Node.js test suite चलाने का तरीका अपनाया है
    • पहले bug fixes मुख्य रूप से GitHub issues या npm package execution failure reports पर आधारित होते थे, लेकिन यह तरीका बड़े refactoring को मुश्किल बनाने वाले “whack-a-mole” जैसा था
    • Node.js repository की हजारों test files को Bun पर port किया गया है, और हर commit पर ये tests चलाकर compatibility verify की जाती है
  • Node.js tests में कभी-कभी internal implementation details और exact error messages verify किए जाते हैं, इसलिए Bun ने कुछ tests में internal bindings को अपने stubs से बदला या verification को name और code पर केंद्रित किया
    • Bun जहां तक संभव हो Node.js के error messages से match करता है, लेकिन अगर name और code समान हों तो कभी-कभी ज्यादा मददगार message भी देता है
  • नए support किए गए Node.js modules और features
    • node:http2: HTTP/2 server creation support, gRPC servers के लिए भी जरूरी
    • node:dgram: UDP socket bind/connect support
    • node:cluster: कई Bun instances चलाकर कई CPU cores पर काम distribute किया जा सकता है
    • node:zlib: JavaScript implementation को native code में दोबारा लिखा गया है और यह Bun 1.1 से 2 गुना तेज है
    • node:v8: getHeapSnapshot, writeHeapSnapshot से Bun heap को Chrome DevTools में inspect किया जा सकता है
  • Bun 1.2 में node:http2 server Node.js से 2 गुना तेज है
  • node:http compatibility में सुधार और Bun HTTP server optimization की वजह से express Node.js की तुलना में HTTP requests को अधिकतम 3 गुना तेजी से process करता है
  • V8 C++ API इस्तेमाल करने वाले C++ add-ons का support भी जोड़ा गया है
    • Node.js V8 का उपयोग करता है, जबकि Bun JavaScriptCore का, इसलिए implementation कठिन है
    • Bun ने JavaScriptCore के ऊपर V8 की public C++ API implement की है ताकि cpu-features जैसे packages काम कर सकें
    • V8 C++ API support जटिल है, इसलिए अधिकांश packages में अभी भी कुछ missing features हो सकते हैं, और node-canvas@v2 व node-sqlite3 जैसे packages के लिए support लगातार बेहतर किया जा रहा है

Built-in S3 API Bun.s3

  • Bun 1.2 ने S3-compatible object storage को handle करने वाली built-in API Bun.s3 जोड़ी है
    • इसे Amazon S3, Google Cloud Storage, Cloudflare R2 जैसी S3 API implement करने वाली services के साथ इस्तेमाल किया जा सकता है
    • file read, write और delete को Web standard Blob-compatible API से handle किया जाता है
  • s3.file() S3 file के लिए lazy reference return करता है, और इसे text(), json(), arrayBuffer(), stream() जैसी Bun File API के समान तरीके से इस्तेमाल किया जा सकता है
  • Bun का S3 client JavaScript में नहीं, बल्कि native code में लिखा गया है
    • Node.js में @aws-sdk/client-s3 इस्तेमाल करने के तरीके की तुलना में S3 bucket file download 5 गुना तेज है
  • write features में write() और writer() मिलते हैं
    • write() string, Uint8Array, Blob, Response आदि upload कर सकता है
    • writer() बड़ी files के लिए multipart upload करता है
  • presign() किसी खास file upload की अनुमति देने वाला presigned URL बनाता है
    • इससे users को credentials expose किए बिना या bucket पर अनावश्यक access permissions दिए बिना सीधे S3 पर upload कराया जा सकता है
  • Bun.serve() के साथ इस्तेमाल करने पर new Response(s3.file(...)) server द्वारा S3 file download करके फिर भेजने के बजाय presigned URL पर redirect करता है
    • इससे memory, time, और server द्वारा file download करने की bandwidth cost घटती है
  • s3:// URLs को Bun.file() और fetch() में भी इस्तेमाल किया जा सकता है
    • fetch("s3://...") से upload, download और delete किया जा सकता है
    • default S3Client AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY जैसे environment variables से configure होता है

Built-in Postgres client Bun.sql

  • Bun 1.2 ने Postgres support वाला built-in SQL client Bun.sql जोड़ा है
    • Bun पहले से built-in SQLite client देता था, और इस release में SQL database support का दायरा बढ़ाया गया है
    • MySQL support जोड़ने वाला pull request भी मौजूद है
  • Bun.sql tagged-template literal से SQL execute करता है
    • JavaScript values को SQL parameters के रूप में pass किया जा सकता है
    • string escaping और prepared statement अपने आप इस्तेमाल करके SQL injection को रोका जाता है
  • results column names को keys के रूप में रखने वाली objects की array के रूप में return होते हैं
  • native code implementation और कई optimizations का उपयोग किया गया है
    • automatic prepared statement
    • query pipelining
    • binary wire protocol
    • connection pooling
    • structure caching
  • लोकप्रिय Postgres clients को Node.js में इस्तेमाल करने की तुलना में row reads अधिकतम 50% तेज हैं
  • API postgres.js से inspired है, और इसे इस तरह design किया गया है कि existing code से Bun built-in SQL client पर migrate करना आसान हो

पैकेज मैनेजर में बदलाव

  • Bun 1.2 ने default lockfile को binary bun.lockb से text-based bun.lock में बदल दिया है
    • bun.lockb ने bun install को npm की तुलना में लगभग 30 गुना तेज़ बनाने में मदद की थी, लेकिन GitHub पर उसकी सामग्री देखना मुश्किल था और pull request review व merge conflict resolve करना कठिन था
    • Dependabot जैसे tools के लिए भी lockfile पढ़ना मुश्किल था
  • bun.lock एक JSONC file है
    • comments और trailing comma को support करता है
    • pull request diff देखना आसान हो जाता है, और trailing comma से merge conflict की संभावना कम होती है
  • नए project bun.lock generate करेंगे
    • मौजूदा bun.lockb project automatic migration के बिना binary lockfile को support करते रहेंगे
    • bun.lockb को लंबे समय तक support किया जाएगा और bun add, bun update भी इसे update करते रहेंगे
    • bun install --save-text-lockfile से नए text lockfile में migrate किया जा सकता है
  • text lockfile पर switch करने के बाद भी bun install, Bun 1.1 से 30% तेज़ हो गया है
  • package.json में comments और trailing comma इस्तेमाल किए जा सकते हैं
    • require() और import() भी ऐसे package.json को पढ़ सकते हैं
    • यह JavaScript ecosystem में हर जगह व्यापक रूप से supported feature नहीं है, इसलिए इसे “at your own risk” इस्तेमाल करने की सलाह दी गई है
  • .npmrc support जोड़ा गया है
    • project root और home directory की .npmrc पढ़ता है
    • registry, scoped package, private registry authentication settings के लिए इस्तेमाल किया जा सकता है
  • नए package manager commands और options
    • bun run --filter: कई workspace में एक ही script को साथ-साथ चलाना
    • bun outdated: outdated dependencies की जांच
    • bun publish: npm publish का विकल्प, .npmrc authentication, tarball packing, OTP और package.json edge cases handling को support करता है
    • bun patch: dependencies में किए गए बदलावों को patches/ के .patch file में save करता है और bun install के समय automatic apply करता है
    • --omit=dev|optional|peer: installation से dev, optional, peer dependencies को exclude करना
    • CA certificates को bunfig.toml, CLI flags और .npmrc में configure किया जा सकता है
    • bundleDependencies और bun add में package.json indentation preserve करने का support भी है

टेस्ट रनर सुधार

  • bun test JUnit XML reporter को support करता है
    • bun test --reporter=junit --reporter-outfile=junit.xml से Jenkins, CircleCI, GitLab CI जैसे CI/CD tools को test results भेजे जा सकते हैं
    • bunfig.toml में भी JUnit reporting configure की जा सकती है
  • code coverage में LCOV reporter जोड़ा गया है
    • bun test --coverage --coverage-reporter=lcov से coverage/lcov.info generate होता है
    • --coverage-dir से output directory बदली जा सकती है
  • expect().toMatchInlineSnapshot() से inline snapshot support मिलता है
    • bun test -u या --update-snapshots से test file के अंदर snapshot update किए जाते हैं
    • toThrowErrorMatchingSnapshot() और toThrowErrorMatchingInlineSnapshot() भी इस्तेमाल किए जा सकते हैं
  • test.only() अब --only flag के बिना भी काम करता है
  • expect() API में Jest, Vitest, jest-extended जैसे matchers जोड़े गए हैं
    • toContainValue(), toContainKey(), toHaveReturned() series
    • दूसरे argument के रूप में custom error message pass किया जा सकता है
  • jest.setTimeout() और setDefaultTimeout() से current scope या module का default test timeout बदला जा सकता है

बंडलर और बिल्ड फीचर्स

  • Bun 1.2 HTML import को support करता है
    • HTML file को Bun.serve के static option में देने पर, HTML के अंदर मौजूद <script> और <link> को automatically bundle करके static route के रूप में expose करता है
  • bun build --compile cross-compilation को support करता है
    • Linux पर Windows या macOS binary बनाई जा सकती है, और उल्टा भी संभव है
    • Windows build में icon setting और console window hide करने के options इस्तेमाल किए जा सकते हैं
  • bun build --bytecode bytecode cache generate करता है
    • eslint जैसे applications का startup time 2 गुना तेज़ कर सकता है
    • .jsc file संबंधित .js file का bytecode cache रखती है, और execution के लिए दोनों files जरूरी हैं
    • bytecode cache source code से 8 गुना बड़ा हो सकता है, इसलिए startup time improvement के बदले ज्यादा disk space लेता है
  • bun build --format=cjs से CommonJS output format specify किया जा सकता है
    • पहले केवल ESM support था
    • पुराने Node.js versions को target करने वाली libraries या applications बनाना आसान हो गया है
  • CommonJS detection बेहतर हुआ है
    • जब file ambiguous हो, तो ऊपर मौजूद "use strict" directive को CommonJS के आखिरी heuristic के रूप में इस्तेमाल करता है
    • require.main === module को import.meta.main में rewrite किया जाता है, ताकि इसे import statements के साथ इस्तेमाल किया जा सके
  • plugin API में onBeforeParse() hook जोड़ा गया है
    • इसे JavaScript नहीं, बल्कि N-API addon के रूप में implement करना होगा
    • Rust, C/C++, Zig जैसी compiled languages में parsing से ठीक पहले source code को लगभग बिना overhead के handle किया जा सकता है
    • यह plugin और framework authors के लिए advanced API है
  • build options भी बढ़ाए गए हैं
    • --env="PUBLIC_*" से environment variables को bundle में inject करना
    • --drop=console जैसे तरीके से function calls हटाना
    • banner/footer जोड़ना
    • Bun.embeddedFiles() से standalone executable के अंदर शामिल files की list देखना
    • --ignore-dce-annotations से गलत dead-code elimination annotations को ignore करना
    • --packages=external से package dependencies को bundle में शामिल न करने की setting

CSS बंडलिंग

  • Bun 1.2 ने नया CSS parser और bundler implement किया है
    • यह LightningCSS के काम से derived है, और Rust से Zig में फिर से लिखा गया है ताकि Bun के JavaScript/TypeScript parser, bundler और runtime के साथ integrate हो सके
  • bun build ./index.css से कई CSS files और @import, url, @font-face references को एक CSS file में combine किया जा सकता है
  • JavaScript और TypeScript code से .css files import की जा सकती हैं
    • JavaScript module graph में imported CSS और @import rules को हर entrypoint के लिए एक CSS file में flatten करता है
  • Bun.build() API से भी CSS और JavaScript को उसी API में bundle किया जा सकता है

Bun रनटाइम API में जोड़

  • Bun.serve() static property के जरिए static routes को support करता है
    • path को key के रूप में और Response object को value के रूप में पास किया जाता है
    • static routes, fetch() handler में सीधे process करने की तुलना में 40% तक तेज़ हैं
    • response body, header और status code memory में cache होते हैं, इसलिए JavaScript allocation और garbage collection नहीं होता
    • server.reload() से static routes को फिर से load किया जा सकता है
  • Bun.udpSocket() Bun API के रूप में UDP socket देता है
    • node:dgram भी support है, लेकिन Bun.udpSocket() मौजूदा Bun.listen() जैसा modern API है
    • एक ही syscall से कई UDP datagram भेज सकता है और OS backpressure को handle करता है
  • Bun.file() delete(), unlink(), stat() को support करता है
    • stat() Node.js fs.stat() के Stats object जैसे format में metadata return करता है
    • S3 files के लिए भी यही API इस्तेमाल किया जा सकता है
  • Bun.color() color parsing, normalization और conversion देता है
    • CSS, ANSI color code, RGB, HSL आदि को support करता है
  • dns.prefetch() DNS records को पहले से fetch करके startup पर DNS cache को warm कर सकता है
    • dns.getCacheStats() से DNS cache की स्थिति check की जा सकती है
  • अन्य utilities
    • Bun.inspect.table(): console.table की तरह table-format string return करता है
    • Bun.randomUUIDv7(): sorting और databases के लिए उपयुक्त monotonic UUID v7 बनाता है

SQLite client में सुधार

  • Bun का built-in SQLite client query.as(Class) से query results को class instances में map कर सकता है
    • getter, setter और method जोड़े जा सकते हैं
    • performance कारणों से class constructor, default initializer और private field support नहीं हैं
    • यह relationship management या SQL generation नहीं करता, इसलिए ORM नहीं है
  • query.iterate() rows को एक साथ memory में load किए बिना iterator के रूप में process करता है
    • query object खुद भी for loop से iterate किया जा सकता है
  • strict option on करने पर query parameters में $, @, : prefix छोड़े जा सकते हैं
    • parameter missing होने पर error throw करता है
  • db.run() result में बदली गई rows की संख्या और आखिरी inserted row ID check किया जा सकता है
    • changes
    • lastInsertRowid
  • safeIntegers option 64-bit integers को truncate हुए number की जगह BigInt के रूप में return करता है
    • इसे database level या query level पर set किया जा सकता है
  • JavaScript using syntax से statement और database को scope खत्म होने पर automatically close किया जा सकता है

JavaScript से C compile और run करना

  • Bun 1.2 ने JavaScript से C को compile और run करने के लिए experimental support जोड़ा है
    • bun:ffi के cc() API का इस्तेमाल करता है
    • यह बिना अलग build step के JavaScript से C system library इस्तेमाल करने का तरीका है
  • Bun में tinycc built-in है
    • gcc या clang के उलट, simple C code को milliseconds में compile कर सकता है
    • जरूरत पड़ने पर C code compile करके run किया जा सकता है
  • N-API इस्तेमाल करने वाला C code भी support करता है
    • node-gyp build step के बिना, सिर्फ Bun होने पर काम करता है

musl और Alpine Linux support

  • Bun 1.2 ने glibc की जगह musl libc इस्तेमाल करने वाले Linux distributions के लिए Bun builds जोड़े हैं
    • Alpine Linux जैसे environments में इस्तेमाल किया जा सकता है
    • Linux x64 और aarch64 को support करता है
  • Docker में oven/bun:alpine image इस्तेमाल की जा सकती है
  • musl छोटे container images संभव बनाता है, लेकिन Bun के glibc version की तुलना में थोड़ा धीमा रहने की प्रवृत्ति है
    • कोई खास वजह न हो तो glibc इस्तेमाल करने की सलाह दी जाती है

JavaScript language features

  • import attributes support जोड़ा गया है
    • import json from "./package.json" with { type: "json" } की तरह JSON, text, TOML आदि को explicitly import किया जा सकता है
    • dynamic import() में भी इस्तेमाल किया जा सकता है
  • using और await using support करता है
    • scope से बाहर निकलने पर [Symbol.dispose] या [Symbol.asyncDispose] call होकर resources को automatically clean up करता है
    • Bun.spawn(), Bun.serve(), Bun.connect(), Bun.listen(), bun:sqlite आदि कई Bun APIs में support है
  • Promise से जुड़े नए APIs
    • Promise.withResolvers(): promise, resolve, reject को एक साथ बनाता है
    • Promise.try(): synchronous या asynchronous function को promise में wrap करता है
  • Error और byte array APIs
    • Error.isError(): prototype chain में बदलाव या node:vm cross-realm स्थितियों में भी Error होने की स्थिति को ज्यादा सटीकता से check करता है
    • Uint8Array.toBase64() / Uint8Array.fromBase64()
    • Uint8Array.toHex() / Uint8Array.fromHex()
  • iterator helper जोड़े गए हैं
    • map, flatMap, filter, take, drop, reduce, toArray, forEach, find
  • Float16Array support करता है
    • 16-bit floating-point arrays में precision 32-bit की तुलना में कम होती है, लेकिन memory efficiency ज्यादा होती है

Web API में जोड़

  • TextDecoderStream और TextEncoderStream को support करता है
    • ये TextDecoder और TextEncoder के streaming versions हैं
    • Bun में TextEncoderStream Node.js की तुलना में 30 गुना तक तेज़ है
  • TextDecoder के stream option को support करता है
    • chunk पूरा UTF-8 code point न हो तब भी उसे बड़े stream के हिस्से के रूप में process किया जा सकता है
  • bytes() method जोड़ा गया है
    • Response, Blob, Bun.file() आदि में stream data को Uint8Array के रूप में return करता है
    • मौजूदा arrayBuffer() के बाद Uint8Array बनाने की प्रक्रिया को कम करता है
  • streaming fetch() upload support करता है
    • बड़े files या ऐसी data streams upload करने में उपयोगी है जिनकी content length पहले से पता नहीं होती
  • console.group() और console.groupEnd() implement किए गए हैं
  • URL.createObjectURL() को support करता है
    • Blob से URL बनाकर fetch(), Worker, import() में इस्तेमाल किया जा सकता है
    • Worker script भी Bun transpiler से गुजरती है, इसलिए TypeScript syntax इस्तेमाल किया जा सकता है
  • AbortSignal.any() कई AbortSignal को combine करता है, ताकि किसी एक के abort होने पर parent signal भी abort हो जाए

व्यवहार में बदलाव और migration के ध्यान रखने योग्य बिंदु

  • bun run की working directory बदल गई है
    • पहले shell की मौजूदा working directory का उपयोग होता था
    • Bun 1.2 में package.json की parent directory को script working directory के रूप में उपयोग किया जाता है
    • यह बदलाव npm, yarn के व्यवहार से मेल कराने के लिए है
  • bun test अब tests के बीच होने वाली uncaught error या rejection को failure के रूप में रिपोर्ट करता है
    • पहले ऐसी errors को test failure के रूप में treat न किया गया हो सकता था
  • server.stop() अब Promise<void> लौटाता है
    • इससे in-flight HTTP connection बंद होने तक इंतज़ार किया जा सकता है
  • Bun.build() failure पर resolved result के logs में error डालने के बजाय reject करता है
    • अगर पुराना व्यवहार चाहिए, तो throw: false सेट किया जा सकता है
  • bun -p अब Node.js से मेल खाते हुए bun --print का alias बन गया है
    • पहले यह bun --port alias था
  • bun build --sourcemap का default inline source map से बदलकर linked source map हो गया है
    • अगर पुराना व्यवहार चाहिए, तो --sourcemap=inline उपयोग करें

प्रदर्शन सुधार

  • Bun 1.2 में कई execution paths में performance improvements शामिल हैं
    • node:http2: 2 गुना तेज़
    • node:http के जरिए S3 upload: 5 गुना तेज़
    • path.resolve(): 30 गुना तेज़
    • fetch() DNS resolution: 2 गुना तेज़
    • bun --hot: memory usage 2 गुना कम
    • macOS fs.readdirSync(): छोटे directories पढ़ना 5% तेज़
    • String.at(): 44% तेज़
    • बड़े string input के atob(): अधिकतम 8 गुना तेज़
    • fetch() gzip data decompression: 30% तेज़
    • बड़े input के Buffer.from(string, "base64"): 6 गुना~30 गुना तेज़
    • बड़े string input के JSON.parse(): 2 गुना~4 गुना तेज़, object input 6% तेज़
    • कुछ Bun.serve() applications का throughput: अधिकतम 2 गुना बढ़ा
    • Error.captureStackTrace(): 9 गुना तेज़
    • छोटी files के fs.readFile(): अधिकतम 10% तेज़
    • string argument वाले console.log(): 50% तेज़
  • Windows में JavaScriptCore का JIT सक्षम किया गया है
    • पहले JIT केवल macOS और Linux पर उपलब्ध था
    • Windows पर JavaScript कुल मिलाकर अधिक तेज़ी से चलता है
    • उदाहरण के तौर पर Object.entries() 20%, Array.map() 50% तेज़ हो गया है

installation और upgrade

  • नए installation commands
    • curl -fsSL https://bun.sh/install | bash
    • powershell -c "irm bun.sh/install.ps1 | iex"
    • npm install -g bun
    • brew tap oven-sh/bun के बाद brew install bun
    • docker pull oven/bun
  • पहले से installed Bun को bun upgrade से upgrade करें

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-25
Hacker News की राय

  • समझ नहीं आता कि third-party database और external S3 library को core/standard library में क्यों डाला जा रहा है
    ऐसी चीज़ों के लिए optional libraries बेहतर नहीं होंगी? ऐसे runtime को standard library में क्या शामिल करना है, यह बहुत सावधानी से चुनना चाहिए
    अभी से यह project ऐसा लगने लगा है जिसमें kitchen sink की तरह सब कुछ ठूंस दिया जा रहा हो

    • मेरे हिसाब से यही रुख Bun के चर्चा में आने की वजहों में से एक है
      batteries included तरीका कई जगह लोकप्रिय है और चुना जाने वाला रास्ता है
      TypeScript setup भी मुश्किल है, Webpack, S3, Postgres, Jest वगैरह भी ऐसे ही हैं, इसलिए files और streams तक simplified access भी काफी दिलचस्प है
      देखते हैं distributed deployment providers कैसे सामने आते हैं
    • मेरी जानकारी में Bun ने VC funding ली है, इसलिए कभी न कभी इसे पैसे कमाने होंगे, और मेरा अनुमान है कि इसे all-in-one runner बनाकर किसी न किसी तरह vendor lock-in पैदा करने की कोशिश हो सकती है
      बेशक मैं गलत भी हो सकता हूं, लेकिन ऐसी dependencies को core/standard library में डालना वाकई ज्यादा समझ में नहीं आता
    • कई लोगों ने Bun के author Jared से यही बात कही है, लेकिन Jared की सोच यह है कि Bun में default project के लिए जरूरी सब कुछ होना चाहिए
      लगता है उनका मानना है कि core में डालने से इसे third-party libraries की तुलना में ज्यादा optimize किया जा सकता है
      व्यक्तिगत रूप से मुझे यह गलत approach लगती है और लगता है Jared की ambition कुछ ज्यादा बढ़ गई है, लेकिन आखिरकार यह उनका passion project ही है
    • मैं पूरी तरह सहमत हूं कि optional libraries बेहतर हैं
      Bun की भाषा में कहें तो “Bun cloud-first JavaScript runtime बनने का लक्ष्य रखता है। यानी cloud में production applications चलाने के लिए जरूरी सभी tools और services को support करता है”, लेकिन यह बात बहुत भरोसा नहीं दिलाती
      यह खास design choice Node से भी बदतर दिखती है
    • यह Bun की managed provider service के लिए है
      VC-backed software की समस्या हमेशा यही रही है कि ऐसी integrated features कोई unique चीज़ देने की कोशिश करती हैं, दूसरे शब्दों में lock-in बनाना चाहती हैं

  • अब तक Bun इस्तेमाल करने का experience बहुत अच्छा रहा है
    नए project में TypeScript/Jest/React/Webpack setup करते समय जगह-जगह breaking changes की वजह से हमेशा झिझक होती थी, लेकिन Bun में यह अपने आप संभल जाता है और मेरे use case में बिना दर्द के बस काम करता है
    S3, SQL जैसी third-party library integrations पर कुछ कहना मुश्किल है, लेकिन कम से कम लगता है कि वे सबसे आम और सबसे ज्यादा मांगी जाने वाली चीजों पर focus कर रहे हैं
    अच्छा है कि यह Node.js tool ecosystem में वह sanity ला रहा है जिसकी जरूरत थी

    • ऊपर बताए गए frontend tech stack में Bun असल में क्या फर्क लाता है, यह जानने की उत्सुकता है
    • React/TypeScript projects तो Vite या Next.js से भी अच्छी तरह setup होते रहे हैं
      लगता है आप इस बात को कम आंक रहे हैं कि बाकी tools भी इस दौरान काफी बेहतर हुए हैं
    • Bun शानदार है
      मेरे लिए यह productivity cheat code जैसा है
      ChatGPT को Bun अच्छी तरह नहीं पता, इसलिए productivity में थोड़ा नुकसान होता है, फिर भी मुझे Bun पसंद है

  • इसमें अच्छी बातें बहुत हैं, लेकिन चिंता है कि कहीं कुछ default behavior बहुत ज्यादा magic की तरह hidden behavior की तरफ तो नहीं जा रहा
    new Response(s3.file(...)) इस्तेमाल करने पर S3 file को server पर download करके user को भेजने के बजाय, Bun user को S3 file के pre-signed URL पर redirect कर देता है
    default के तौर पर यह काफी चौंकाने वाला विकल्प है, और अगर आप S3 bucket को सीधे expose नहीं करना चाहते तो इसे बंद कैसे करें, यह भी बिल्कुल साफ नहीं है

    • Bun जिस क्षेत्र को खोलने की कोशिश कर रहा है, उसका सम्मान है, लेकिन अगर creator को Twitter पर follow करें तो decision-making अल्पकालिक results और convenience की ओर काफी झुकी दिखती है, और उस magical behavior के गहरे असर को हल्के में लिया जाता है
      शुरुआत में इस project से उम्मीद थी, लेकिन social पर दिखने वाले बिखरे हुए और निजी तौर पर अक्सर खराब लगने वाले design decisions देखकर long-term direction पर भरोसा नहीं होता
      अगर इसे v0.x में रखा होता तो ठीक था, लेकिन 1.0 रिलीज कर दिया है तो API surface बढ़ाने का standard कहीं ज्यादा ऊंचा होना चाहिए था
    • response में stream पास कर दें
      Response(file.stream())
    • समझ आता है कि ऐसा क्यों किया गया, लेकिन यह design मुझे पसंद नहीं है
      व्यक्तिगत रूप से यह side effects वाले मजबूत behavior जैसा लगता है, और पढ़ने में ऐसा दिखता है जैसे URL नहीं बल्कि file content return हो रहा हो
      फिर भी यह भी जानना चाहूंगा कि bucket exposure में परेशान करने वाली बात क्या है
      यह pre-signed URL है, इसलिए व्यापक access permission भी नहीं देता
      बेहतर होता कि Response((file(...).getPresignedURL())) जैसी explicit API होती, या environment variable या Bun config से इस behavior को on करने का option होता

  • बैटरी शामिल होना बड़ा फर्क पैदा करता है
    Fetch API, Service Workers, Web Components, ES6+, WebRTC जैसे web API अब V8 और WebKit runtime दोनों में native हो गए हैं—मुझे यह इसलिए पसंद है
    हालांकि इसकी भी एक हद होनी चाहिए
    S3 शायद बहुत आगे जाना हो सकता है, लेकिन SQL driver समझ में आते हैं
    फिर भी सवाल यह है कि कितना शामिल किया जाए
    database बहुत सारे हैं; क्या उनमें से आधे के driver शामिल करने चाहिए?
    उस स्तर पर भी अतिरिक्त code काफी बढ़ जाएगा और executable धीमा हो सकता है
    और ऐसे sensitive API को Bun में डालने से security भी छूट सकती है
    कल्पना कीजिए किसी script या path की समस्या के कारण eval चल जाता है और Bun पूरी source file को private S3 पर upload कर देता है—उस पल खेल खत्म है

    • “अतिरिक्त code बढ़ने से executable धीमा हो जाता है” क्या वाकई ऐसा है, यह जानने की जिज्ञासा है
      code runtime पर कैसे load होता है, इस पर निर्भर करते हुए यह लगभग नज़रअंदाज़ करने लायक हो सकता है, ऐसा मैंने देखा है
      अगर code loading केवल import statement दिखने पर trigger होती है, तो असल में speed overhead नहीं है, है ना?
      static रूप से link होने पर भी, सिर्फ code मौजूद होने की वजह से executable इतना धीमा क्यों हो कि ध्यान देने लायक हो, यह मुझे ठीक से समझ नहीं आता
      memory में load होने वाला executable सचमुच थोड़ा बड़ा हो जाएगा, लेकिन शायद महसूस होने वाली slowdown नहीं होगी
    • पहले HN पर इस बात पर चर्चा हुई थी कि browser SQLite को first-class support क्यों नहीं देते; वही तर्क Bun पर भी लागू हो सकता है
      मुख्य बात यह है कि library maintenance की जिम्मेदारी किसकी है, और SQLite बदलने पर उस library को कैसे बदला जाए
      अगर SQLite में bug हो तो Bun में उसे कैसे fix करेंगे?
      किन versions में fix जाना चाहिए?
      runtime का patch उसके ऊपर चलने वाले code के व्यवहार को बदल सकता है; अगर users ने पुराने behavior के हिसाब से workaround बना रखे हों तो उसे कैसे handle करेंगे?
      कुछ हद तक ये समस्याएं हल की जा सकती हैं, लेकिन इनके साथ नुकसान भी आते हैं
      किसी बिंदु के बाद यह runtime नहीं बल्कि platform बन जाता है, और उसके साथ अलग जिम्मेदारियां और समस्याएं आती हैं
    • S3 को शामिल करने के पक्ष में तर्क यह लगता है कि S3-compatible API लागू करने वाली object storage services बहुत हैं
      यह असली web standard तो नहीं है, लेकिन बहुत लोग इसे de facto standard की तरह target करते हैं
    • “अतिरिक्त code बढ़ने से executable धीमा होता है” कहा गया, लेकिन article में सचमुच benchmark हैं और बताया गया है कि Bun सबसे तेज Node.js solution से दोगुना तेज है

  • हाल ही में एक customer production में Bun इस्तेमाल कर रहा था
    सुना कि speed और simplicity की वजह से Bun का development experience अविश्वसनीय रूप से अच्छा है
    developer experience लंबे समय में बड़ी भूमिका निभाता है
    अगर codebase या process बिखरे हुए हों, तो FAANG-स्तर का compensation न देने पर आप अच्छे लोगों को खो देंगे

  • मैंने अभी Bun इस्तेमाल नहीं किया है, लेकिन feature list इतनी लंबी है कि यह सब robust और bug-free होगा या नहीं, इस पर संदेह है
    उम्मीद है मैं गलत साबित होऊं, और किसी भविष्य के project में इसे चलाकर देखने का इरादा है
    project management के नजरिए से थोड़ा confusion है कि जब यह अभी Node.js 100% compatible भी नहीं है, तो S3 support पर समय क्यों लगाया जा रहा है
    Next.js बहुत बड़ा ecosystem है; अगर Next.js customers को ला सकें तो S3 support से कहीं ज्यादा growth मिल सकती है

    • 100% compatibility marketing के लिहाज से अच्छी जीत है, लेकिन long-tail compatibility average user के लिए शायद ज्यादा फर्क न डाले
      रोजमर्रा में पूरी Node.js API surface में से आप सच में कितना इस्तेमाल करते हैं?
      उसके अंदर के अजीब edge cases पर आप सच में कितना निर्भर हैं?
    • “project management के नजरिए” वाली बात यह मानकर चलती है कि project क्या है, यह पता है
      काम करने वाले लोग भी robot नहीं हैं
      कुछ काम समझने में समय लेते हैं, और उस दौरान दूसरे काम भी किए जा सकते हैं
      हर काम एक ही व्यक्ति नहीं करता
      कहा जाता है “Next.js customers को लाने से ज्यादा growth होगी”, लेकिन किस चीज़ की growth?
      उससे पैसा नहीं बनता
      यह VC-backed project है, और लक्ष्य Bun को मुफ्त में देकर दुनिया भर के सभी users हासिल करना नहीं है
    • लंबी feature list के सब robust और bug-free होने पर संदेह है, खासकर यह बात खटकती है कि यह Zig में लिखा गया है
      Zig में memory safety बहुत कम है
      अगर आप किसी ऐसे variable को reference करें जो अब alive नहीं है, तो segmentation fault के बजाय यह किसी arbitrary असंबंधित memory तक पहुंच जाता है
      कहा जाता है कि debug और safe mode में भी ऐसा ही है[0]
      क्या ऊपर से ऐसा memory liveness system चढ़ाना इतना मुश्किल है जो variable names को dead state में mark करे और dead होने पर access रोके?
      आखिर में बात “undefined behavior इस्तेमाल मत करो”[1] पर आ जाती है
      इसलिए internet-facing webserver जैसी जगहों पर मैं Zig से बनी कोई चीज़ नहीं रखना चाहूंगा
      [0] : https://news.ycombinator.com/item?id=41720995
      [1] : https://github.com/ziglang/zig/issues/16467#issuecomment-164...
    • यह बहुत robust भी नहीं है, और bug-free भी नहीं
      पिछले साल इस्तेमाल किया था, लगातार crash हो रहा था
    • bun add ने package.json के spaces और indentation preserve न करने वाला bug fix किया, और अब कैसी भी अजीब indentation हो, उसे preserve करता है—यह item काफी मजेदार है
      पता नहीं किसने ऐसी मांग की, और क्यों लगा कि इस पर code लिखना worth है

  • HTML imports शानदार और कूल हैं
    कहा गया है कि Bun 1.2 में HTML imports support होने से पूरे frontend toolchain को एक single import statement से replace किया जा सकता है
    शुरू करने के लिए Bun.serve के static option में HTML import पास करें

    import homepage from "./index.html";

Bun.serve({  
  static: {  
    "/": homepage,  
  },

  async fetch(req) {  
    // ... api requests  
  },  
});
    • जिज्ञासा है कि यह, उदाहरण के लिए, Vite को कैसे replace करने देता है
      क्या hot module replacement, CSS preprocessing, Vue SFC compiler जैसे framework-specific plugin loading संभव हैं?
      static file serving कोई खास नई चीज़ नहीं है, इसलिए लगता है मैं कुछ miss कर रहा हूं

  • मुझे लगा था कि Node.js के प्रतिस्पर्धी विकल्प जितना तय-शुदा असफल होने वाला कोई प्रोजेक्ट नहीं होगा, लेकिन इसे एक बार आज़माना अच्छा रहा
    मुझे text files और SQLite DB updates संभालने वाली कई standalone scripts बनानी थीं, और TypeScript, bun:sqlite [1], bun $ Shell [2] को बिना config files या local npm dependencies manage किए सीधे इस्तेमाल कर सका
    उसके बाद नए JS/TypeScript projects में भी इस्तेमाल किया, जहाँ built-in bundler [3] और test support [4] भी काम आए और dependencies install होना भी तुरंत पूरा हो गया
    हर चीज़ का तेज़ी से तुरंत चल जाना सच में quality-of-life improvement है, और अब Bun नए JS project के लिए पहली पसंद बन गया है
    [1] https://bun.sh/docs/runtime/shell
    [2] https://bun.sh/docs/api/sqlite
    [3] https://bun.sh/docs/bundler
    [4] https://bun.sh/docs/cli/test

    • मेरे साथ भी ऐसा ही है
      मैं भी इसी सोच में था कि “ऐसी चीज़ें तो अगले साल npm में भी आ जाएँगी, फिर इसका क्या मतलब”
      आखिरकार Bun इस्तेमाल किया और सचमुच हैरान रह गया
      developer experience के छोटे-छोटे हिस्से जुड़कर बड़ा फर्क पैदा करते हैं
      मेरे project में Bun वाकई next-gen जैसा लगता है

  • कुछ समय पहले पहली बार Bun इस्तेमाल किया और अनुभव शानदार रहा
    मेरे सभी projects TypeScript इस्तेमाल करने के लिए Webpack या Vite configured रखते हैं, और एक बार setup हो जाए तो लगभग पूरी तरह काम करते हैं, लेकिन setup अपने-आप में झंझट वाला है और छोटी scripts के लिए इसके लायक नहीं
    इसके उलट Bun सीधे चल गया
    CLI में TS को “सीधे” चलाने के लिए node-ts या जो भी tool था, उसके साथ 10–30 मिनट तक जूझता रहा; “module नहीं है”, “import/require इस्तेमाल नहीं कर सकते”, “ESM/CJS” जैसे डरावने messages झेलता रहा, और आम fixes जैसे package.json module type बदलना, tsconfig बदलना, import/require तरीका बदलना—सब आज़मा लिया
    करीब 200 lines की script चलाने की कोशिश में आखिरी विकल्प के तौर पर Bun पर switch किया, तो यह बेहतरीन तरीके से चल गया

    • अब latest Node.js भी ऐसे मामलों में “बस TS चलाओ” support देता है
      node --experimental-strip-types index.ts
      अगर latest Node नहीं है, तो tsx package मेरे लिए ठीक चला
      ts-node से बेहतर था
      हालांकि दोनों options type information को बस हटा देते हैं, और Bun भी यही करता है

  • दिशा पसंद आ रही है
    खासकर S3 और Postgres native support शामिल करना बहुत सही है, क्योंकि यह मौजूदा “खुद framework जोड़-तोड़कर बनाओ” वाली स्थिति का एक विकल्प हो सकता है
    Rails और Laravel जैसे सभी web frameworks में यह standard है, और JS ecosystem को भी इससे बड़ा फायदा मिल सकता है
    मेरे हिसाब से अगला कदम migrations और schema management, और factory setup अच्छे से कर सकने वाला बेहतर default test experience होना चाहिए