--- title: "Bun 1.4" url: https://daily.dev/posts/bun-1-4-nz2dmgftt source_url: https://bun.com/blog/bun-v1.4 type: article source: "Bun" published: 2026-08-20T14:08:27.685Z updated: 2026-08-22T21:12:08.144Z tags: ["javascript", "performance", "nodejs", "bun"] reading_time: 238 upvotes: 1 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Bun 1.4 **[Bun](https://daily.dev/sources/bun)** · 238 min read · 1 upvotes · 0 comments ## Summary Bun 1.4 is a major release rewriting the runtime from Zig to Rust, adding 1,517 newly passing Node.js test-suite tests (the biggest compatibility jump since 1.0), and fixing over 2,900 issues. It cuts idle CPU usage by 5x, reduces memory usage up to 48% for HTTP servers, and starts 50% faster on Linux and 2.5x faster on Windows. New built-in APIs include Bun.Image (faster than sharp), Bun.WebView (headless browser automation without Puppeteer/Playwright), Bun.markdown, Bun.cron(), and Bun.Terminal (PTY support). Native ReadableStream/WritableStream/TransformStream, CompressionStream/DecompressionStream, and ~3x faster bun:ffi are included, along with bun run --parallel, bun test --parallel, experimental HTTP/2 and HTTP/3 support in Bun.serve() and fetch(), directory serving, Range/conditional request handling, and Windows ARM64 support. Playwright, vitest, OpenTelemetry, dd-trace, Nuxt, testcontainers, and several other tools/packages now work out of the box. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What's new in Bun 1.4 compared to Bun 1.3? Bun 1.4 rewrites the runtime from Zig to Rust, adds 1,517 newly passing Node.js test-suite tests, and fixes over 2,900 issues. It reduces idle CPU usage by 5x, cuts HTTP server memory usage by up to 48%, and starts 50% faster on Linux and 2.5x faster on Windows, alongside new built-ins like Bun.Image, Bun.WebView, Bun.markdown, and Bun.cron(). _Track major runtime releases like this one on daily.dev before planning a Bun upgrade._ ### How does Bun.WebView compare to Puppeteer or Playwright for browser automation? Bun.WebView is headless browser automation built directly into Bun, requiring no Puppeteer or Playwright dependency. On macOS it uses the system WebKit with nothing to install; on macOS, Linux, and Windows it can drive an installed Chrome, Chromium, or Edge via CDP. It supports navigation, clicking, scrolling, JavaScript evaluation, and screenshots, with clicks registering as trusted user input. _Developers weighing browser automation tools can follow daily.dev for comparisons like Bun.WebView versus Playwright._ ### How much faster is bun:ffi in Bun 1.4? bun:ffi is up to 3.8x faster in Bun 1.4 because it now runs on FFI built directly into JavaScriptCore instead of TinyCC. A no-op call dropped from 2.13ns to 0.70ns (3.0x) and constructing a CString from a pointer dropped from 92.5ns to 24.1ns (3.8x), with a new buffer_length argument type that passes a TypedArray's length alongside its pointer. _Engineers optimizing native interop can keep up with runtime FFI improvements like this via daily.dev._ ## Community take How the wider developer community reacted, aggregated from 3 discussions and 191 comments across hackernews, lobsters (as of 2026-08-22). **TL;DR:** Reaction to Bun 1.4 centers on a big debate over its batteries-included, everything-in-the-runtime philosophy, plus a lot of discussion (and skepticism) about the AI-driven Rust rewrite and whether the release itself is credible given recent criticism of delays. **Sentiment:** 30% positive · 45% mixed · 25% skeptical **The case for** - Having common functionality (image processing, headless browser automation, parsers) built into the runtime avoids installing many small third-party dependencies and reduces supply-chain risk. - Native implementations are seen as faster and more consistent than relying on scattered ecosystem packages. - Some see the Rust rewrite as a surprisingly fast, low-cost success that silences earlier doubters. - The new Bun.WebView API is praised as a clean, appealing design for browser automation. **The pushback** - Bundling so many domains (YAML/TOML parsers, DB drivers, image handling, browser automation) into one massive binary is seen by some as scope creep that duplicates dedicated projects' expertise. - Concerns that the standard-library decisions are driven by one person's preference rather than a broader standards process. - Skepticism that an AI-heavy rewrite can be trusted long-term, with fears of quality degradation ('slop') down the road. - Doubts about the claimed rewrite timeline and cost, with some calling the release late and over budget relative to earlier promises. - Some found the changelog/release excessively long and the promotional video oddly stiff. - Bun.WebView currently lacks PDF export, a feature commenters wanted from headless browser automation. **By community** - hackernews (mixed): A long, heated back-and-forth over whether Bun's all-in-one philosophy is good or bad, layered with skepticism and jokes about the AI-driven rewrite's cost, timeline, and the promo video. - lobsters (skeptical): Discussion leans toward questioning whether the release itself is meaningful content (given it was flagged as spam) and voicing doubts about AI-authored 'slop' alongside some praise for specific new APIs. **Hottest debate:** Whether Bun's strategy of bundling everything (parsers, drivers, browser automation, etc.) into the runtime is a smart batteries-included approach or unnecessary bloat that duplicates dedicated projects. **Open questions** - Is the Rust rewrite actually stable and bug-free in real-world production use beyond Anthropic's own usage? - What is the true cost and timeline of the AI-assisted rewrite, and how should that be judged as a success or failure? - Will quality degrade over time as more AI-generated code accumulates in the codebase? **Highlights** > It's weird their promotional video repeats "you can do without installing dependencies", if I want headless browser testing is that wrong to install a project that offers that? Why would I want everything reimplemented in this massive binary? Why would Bun be anymore in touch with nuances of all these different technologies then individual projects dedicated to their own speciality? JS Runtime, Package Manager, Test Runner (both unit and headless browser), Bundler, JSX, PosgreSQL/MySQL/SQLite drivers, S3 client, Redis client, Formatter, Linter, etc. Not to mention parsers for YAML, TOML, Markdown which are easily three separate projects worth of complexity in their own right. I guess one clear downside is to get all these great features they're pushing for 1.4 you needed to wait until everything was ready. Given 1.3 was pushed out in October 2025, a 10 month release cycle across so many large technologies is tough. Before you give a pass because of the Rust rewrite Bun 1.2 was released in January 2025 I have to respect Jarred knows how to work the algorithm, 10 carefully crafted X teaser posts for this release spaced out over 72 hours https://xcancel.com/jarredsumner > — [cube00 on hackernews · 16 comments](https://news.ycombinator.com/item?id=49375049) > I've still yet to run into any enterprise project using bun in the wild. It really feels like something entirely contained within startups that would choose wildly inappropriate tech like next.js. Add in the influencer dev brainrot culture and you get these VC backed efforts to privatized publicly important projects (node.js) under control of quite evil people that have zero record of helping others. > — [shimman on hackernews](https://news.ycombinator.com/item?id=49375928) > ~3 months start to finish and the price of 1 engineer for a year, to rewrite a critical infra codebase that tens of millions of user software relies on. Truly the goalposts keep moving. This kind of project would've have been 10x the effort and price a few years ago. > — [reducesuffering on hackernews · 1 comments](https://news.ycombinator.com/item?id=49377092) > I remember when Python advertised its strong standard library. Then the batteries got old and we went hard micro dependencies. Maybe pendulum is just starting to swing back. > — [mitsuhiko on lobsters · 3 points](https://lobste.rs/s/eesu8d/bun_1_4#c_dufm3j) > The benefit of having features like this baked into the core runtime is that you can guarantee they will be consistently supported and documented for the lifetime of the project. Similar to how Django benefits from shipping its own ORM and template language because it means those things will never become unsupported or incompatible with the rest of the framework. In 2026 I think image processing is a reasonable default capability for a language runtime. Headless browser automation and markdown make sense if you expect agent frameworks to be a big client of your runtime, which feels right for Bun. > — [simonw on lobsters · 3 points, 1 comments](https://lobste.rs/s/eesu8d/bun_1_4#c_f82ase) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49374797) · 82 points · 156 comments - [hackernews](https://news.ycombinator.com/item?id=49328557) · 1 points · 0 comments - [lobsters](https://lobste.rs/s/eesu8d/bun_1_4) · 34 points · 35 comments ## Similar posts on daily.dev - [Bun v1.3.12](https://daily.dev/posts/bun-v1-3-12-f5ph0rgqu) · Bun · 140 upvotes · 2 comments --- Tags: [#javascript](https://daily.dev/tags/javascript), [#performance](https://daily.dev/tags/performance), [#nodejs](https://daily.dev/tags/nodejs), [#bun](https://daily.dev/tags/bun) [View this post on daily.dev](https://daily.dev/posts/bun-1-4-nz2dmgftt)