/
Published on 09.02.2026
TLDR: Bun 1.3.9 ships parallel and sequential script execution, SIMD-accelerated regular expressions from a JavaScriptCore upgrade, and a raft of performance improvements across string operations, AbortSignal, and Markdown rendering. It is arguably one of the meatiest point releases in Bun's history.
Summary:
Let me be direct here: this release is dense, and if you are running Bun in production, it deserves your full attention. The headline feature is bun run --parallel and bun run --sequential, which let you run multiple package.json scripts concurrently or in order, with Foreman-style prefixed output. If you have ever wrestled with concurrently or npm-run-all, this is Bun eating that lunch. It integrates with workspace filtering so you can fan out builds across monorepo packages with a single command. The --no-exit-on-error flag is a thoughtful addition for CI pipelines where you want to see all failures, not just the first one.
But the performance section is where this release gets genuinely exciting. The JavaScriptCore upgrade brings SIMD-accelerated prefix search for regular expressions, inspired by V8's approach. When a regex has alternatives with known leading characters, the engine now scans 16 bytes at a time using SIMD instructions on both ARM64 and x86_64. Non-capturing parenthesized subpatterns with fixed-count quantifiers that previously fell back to the interpreter are now JIT-compiled, yielding a reported 3.9x speedup. String.prototype.startsWith gets DFG/FTL intrinsic treatment with constant folding delivering up to 5.76x improvement. Set and Map .size are 2-3x faster. These are not synthetic benchmarks that nobody hits -- these are operations that run millions of times in real applications.
The testing improvements deserve a callout too. Symbol.dispose support for mock() and spyOn() means you can use the using keyword to automatically restore mocks when they leave scope. No more forgotten mockRestore() calls polluting your test suite. This is the kind of developer experience polish that compounds over time.
There is also a security fix worth noting: a request smuggling vulnerability in the HTTP server chunked encoding parser was patched. If you are running Bun as an HTTP server in production, update immediately and do not wait.
What the Bun team is not talking about much, and what I think matters, is the growing gap between Bun's feature velocity and the ecosystem's ability to validate it. Ten contributors on a release this size means a lot of surface area. The HTTP/2 connection upgrade fix, the NO_PROXY fix, the Windows path normalization fix -- these are all bugs that presumably made it to production somewhere before being caught. For architects evaluating Bun: the performance numbers are stunning, but your risk calculus should include the maturity of the test coverage for edge cases in production workloads.
Key takeaways:
Tradeoffs:
Link: Bun v1.3.9
TLDR: Doug Parker from the Angular team shared Google's approach to micro frontends, which emphasizes complete isolation without shared dependencies, Protocol Buffers for communication, and a strong warning that most teams should explore alternatives first. This is not an endorsement of micro frontends -- it is a cautionary tale.
Summary:
This is refreshing and somewhat unusual: an engineer from one of the world's largest companies actively discouraging people from using the architectural pattern his company employs. Doug Parker's core message is that Google's micro frontend approach works because of Google's specific constraints -- thousands of engineers, hundreds of teams, and a monorepo the size of a small planet. The approach demands complete isolation between micro frontends, with no shared dependencies whatsoever, and uses Protocol Buffers for inter-service communication. That level of isolation has a staggering cost in bundle size, coordination overhead, and operational complexity.
The key insight Parker offers is that teams reach for micro frontends to reduce team coupling, but micro frontends are not the only tool for that job, and they are arguably one of the most expensive ones. If your actual problem is deploy independence, feature flags or modular monoliths might get you there with a fraction of the complexity. If your problem is team autonomy, organizational changes and clear API boundaries between modules can be far more effective than splitting your frontend into separately deployed applications.
What I find Parker is skirting around is the question of what happens when teams adopt micro frontends at Google scale constraints but without Google scale resources. The complete isolation requirement means duplicated dependencies, duplicated runtime overhead, and a user experience tax that gets paid in page load time and memory consumption. Parker mentions Protocol Buffers for communication, which is a heavy choice that implies a level of infrastructure maturity most organizations do not have. The gap between "this is how Google does it" and "this is how your 50-person startup should do it" is enormous, and that gap is where most micro frontend disasters happen.
For architects and team leads, the real takeaway is not about micro frontends at all -- it is about being honest about the problem you are actually solving. If you cannot articulate the specific organizational constraint that micro frontends address, and explain why a simpler approach fails to address it, then you are adding complexity without a clear return. Parker is essentially saying: we do this because we have to, not because we want to.
Key takeaways:
Tradeoffs:
Link: Ng-News 26/04: Micro Frontends at Google
TLDR: Philip O'Toole, maintainer of rqlite, discovered that AI coding agents like Claude Code and GitHub Copilot cleared years of backlog in days -- and then realized the same tools that accelerated his development also eliminated the competitive moat that complex codebases once provided.
Summary:
This article hits a nerve that a lot of open-source maintainers are probably feeling but not yet articulating. O'Toole describes using AI coding agents on rqlite, a distributed database built on SQLite and Raft, and watching years of accumulated backlog evaporate in a matter of days. The productivity boost is real and dramatic. But the uncomfortable second-order effect is the one that matters: if these tools can help him move that fast through his own complex codebase, they can help anyone else do the same thing with any codebase, including competitors.
The traditional moat for complex software projects was the sheer difficulty of understanding and modifying a large, intricate codebase. Distributed systems code, with its consensus protocols, failure handling, and subtle concurrency issues, was particularly defensible because the ramp-up time for new contributors was measured in months or years. AI coding agents compress that ramp-up dramatically. They can read, understand, and modify code across an entire repository with a fluency that would take a human developer significant time to develop.
What O'Toole is not quite confronting head-on, though he circles around it, is what replaces source code complexity as a moat. If the code itself is no longer defensible, what is? Community, perhaps. Operational knowledge. Trust built over years of production reliability. Integration depth with other tools and ecosystems. These are softer, harder-to-quantify advantages, and they are also harder to build deliberately. The uncomfortable truth is that for many projects, especially those that relied on being "too complex to fork effectively," the competitive landscape has fundamentally shifted.
For teams and architects, this has immediate strategic implications. If you are building a product whose defensibility rests on the complexity of your implementation, that defense is eroding. The investment case for open source projects shifts from "we have a complex codebase that is hard to replicate" to "we have operational expertise, community trust, and ecosystem integration that is hard to replicate." That is a very different value proposition, and it requires a very different investment strategy.
Key takeaways:
Tradeoffs: