When I wrote Next Generation Tooling for Developers last year, I added a section about the business models of the companies behind these tools. Astral and VoidZero were both venture-backed, and I wondered how they would eventually make money, given that the tools themselves are free and open source. My guess was that they would keep the tools free and sell paid services on top, like Astral’s pyx and VoidZero’s Vite+. I was right to wonder about the business models, though things took a different direction than I had anticipated.
Since then, these companies have been acquired:
So the business model, at least for now, turned out to be a simpler one than I expected: get acquired by a bigger company.
Cloudflare has been the most hands-off of the three. With Astro, as far as I can tell, they haven’t changed much beyond improving compatibility with Cloudflare’s own platform, and they have been clear that Astro stays MIT-licensed and works with every deployment target, not just theirs. They also set up an Astro Ecosystem Fund, and committed a million dollars to an independent Vite fund when they bought VoidZero. So far this looks like a company that mostly wants the tools to keep doing what they were already doing.
OpenAI bought Astral in March 2026, and so far it has been quiet. uv and Ruff still work the way they did. The main concrete change I’ve seen is that OpenAI’s Codex now uses uv instead of pip, which according to OpenAI saves a lot of compute time. Simon Willison wrote a good piece about the acquisition if you want more detail.
Bun is the one that has actually changed.
Anthropic bought Oven earliest, back in December 2025. Claude Code now ships as a Bun executable, so Anthropic has a clear reason to invest in it.
The official line is that not much changes. Bun stays MIT-licensed, the same team keeps working on it, and the roadmap is roughly the same. What changed is how the code gets written. According to RedMonk, most commits to Bun are now made by bots rather than people, and contributions from outside developers have dropped off. Jarred Sumner, Bun’s creator, said his team hasn’t been typing code themselves for many months.
The clearest example was when the team used Claude to rewrite around 960,000 lines of Bun from Zig to Rust in six days. It passed almost all of the tests, but the result included over 13,000 unsafe calls, and plenty of people were not impressed. There were also memory leaks bad enough that some Claude Code sessions were using more than 14GB of memory.
There is also an interesting backstory to why the rewrite happened at all. Zig, the language Bun was originally written in, has a strict no-AI policy. Andrew Kelley, Zig’s creator, has banned AI-assisted contributions entirely, calling them “invariably garbage” and arguing they just flood a small review team with low-quality patches. Since the Bun team now writes most of their code with Claude, this put them in an awkward spot. They ended up running a fork of Zig instead, though Zig’s maintainers said those changes wouldn’t have been welcome upstream anyway, AI aside. Rather than maintain that fork forever, the team rewrote Bun in Rust, and that rewrite has now been merged into Bun’s main branch.
My theory is that this had more to do with Zig than with Rust. The usual argument for Rust is safety, but the AI-generated rewrite has thousands of unsafe calls in it, so they aren’t really writing safe Rust anyway. To me it looks less like a careful technical decision and more like a culture clash. Anthropic now builds Bun almost entirely with AI, and Zig’s leadership thinks that whole approach is a mistake. It’s hard to keep building on a language whose maintainers consider your way of working garbage. Rust doesn’t come with that conflict, so I suspect that, more than anything about the language itself, is why they switched.
So the changes are real, even if they are more about how Bun is built than where it is going. I’m honestly not sure how I feel about it. On one hand it’s an interesting look at what AI-driven development at this scale actually looks like. On the other hand, I’m not sure I’d want to depend on a runtime while it’s in the middle of being rewritten by an AI.
When VoidZero first announced Vite+, the plan was a mixed license: free for individuals, open source projects, and small businesses, with paid tiers for startups and enterprises. That matched what I had assumed, a paid layer sitting on top of the free tools.
However, VoidZero changed their mind even before the Cloudflare acquisition. They decided the mixed license didn’t feel right and open-sourced Vite+ under the MIT License in March 2026. Around the same time, Evan You announced Void, a Vite-native deployment platform, as the thing they would actually charge for. So the paid-service idea didn’t disappear, it just moved from the tooling to a hosted platform around it. Then Cloudflare bought the whole company anyway.
All this comes at a time when I have already invested the time into learning most of these tools and integrating them into my development workflows. In recent months, I have been using uv, Ruff, oxlint and oxfmt, and Astro in many projects, both personal projects and production projects for clients. The fact that the tools got acquired by large tech companies should hopefully give them the stability to continue being developed, while staying faithful to what made these projects loved in the first place.
These tools are still open source, which I also pointed out in the original article. If one of the new owners ever does something the community really dislikes, the tools can be forked, and that has happened plenty of times before with other projects. But a fork only gets you the code, not the people. A lot of what made these tools good was that small, focused teams were putting a lot of energy into them. An acquisition can keep funding that work, or it can quietly point it somewhere else, and the license doesn’t tell you which. The Bun rewrite is a good example: forking 960,000 lines of AI-generated Rust with 13,000 unsafe calls is not much of a safety net.
So the business-model question I asked last year finally has an answer. It wasn’t pyx or Vite+, it was getting acquired. Given that these were venture-backed companies from the start, that was probably always where this was going.
Featured image by Andre Taissin on Unsplash.
]]>Here’s how I like to setup new Node.js projects, with linting and formatting using Oxc.
I wrote about Oxc (The JavaScript Oxidation Compiler) in Next Generation Tooling for Developers. When I first wrote this article, Oxc already included a linter (oxlint, which can replace ESLint), but the formatter was not available yet. Since then, VoidZero has continued the development of Oxc, not only launching Vite+ but also launching a formatter (oxfmt, which can replace Prettier). With the combination of oxlint and oxfmt, I now have a modern-alternative to ESLint + Prettier. Note that this might not work as a replacement in all existing projects that rely on specific configurations of ESLint and/or Prettier. However, for new Node.js projects, I will strive to go with the Oxc stack.
The two main reasons I prefer Oxc is speed and ease of configuration; as I have explained in Next Generation Tooling for Developers, the Rust-based tools are noticeably faster. In addition, they have a more modern design with more intutive configuration. In particular, ESLint has become a nightmare to configure after the breaking changes in ESLint v9.
These tools can be run in a project without being installed or added to package.json using npx commands:
npx oxlint@latestnpx oxfmt@latestFor consistent usage in an npm project, Oxc packages can be added as devDependencies.
npm install --save-dev oxlint@latest oxlint-tsgolint@latest oxfmt@latestConfiguration files for Oxlint are written in JSON, with support for comments (JSONC). Oxlint will automatically search for files named .oxlintrc.json and automatically use those. But you can name the file anything when you are using the --config CLI option.
Use the --init option to initialize a .oxlintrc.json file:
## If installed
./node_modules/.bin/oxlint --init## If not installed
npx oxlint@latest --initBy default, oxfmt automatically tries to find the nearest .oxfmtrc.json or .oxfmtrc.jsonc file from current working directory. If not found, default configuration is used.
Also you can specify your config file by -c yourconfig.jsonc flag.
Almost all format options are compatible with Prettier’s options. So you may finish your setup by just renaming .prettierrc.json to .oxfmtrc.jsonc.
Use the --init option to initialize a .oxfmtrc.json file:
## If installed
./node_modules/.bin/oxfmt --init## If not installed
npx oxfmt@latest --init--init option).
The prettier-init tool can be used to help bootstrap configuration:
npx prettier-init@latest
mv ".prettierrc.json" ".oxfmtrc.json"scripts block in package.json
For easy and consistent usage across the project, add to the scripts block in package.json:
"scripts": {
"lint": "oxlint --type-aware --type-check .",
"lint:fix": "oxlint --type-aware --type-check . --fix",
"lint:fix-all": "oxlint --type-aware --type-check . --fix --fix-suggestions --fix-dangerously",
"format": "oxfmt .",
"format:check": "oxfmt . --check"
},Commit and push all relevant files that were changed or added:
git add ".oxfmtrc.json" ".oxlintrc.json" "package.json" "package-lock.json"
git commit -s
git pushFeatured image by Gabriel Heinzer on Unsplash.
]]>In recent months I have been learning about Astral: High-performance Python tooling. I first learned about Astral’s tools from this article: I’m Switching to Python and Actually Liking It and have started using uv and ruff. This led me to try to find similar tools for other languages.
I am not focusing on AI tools in this article. I have other articles on this subject (such as Agentic CLI Tools Comparison).
The projects below have a few things in common. The projects are led by companies which have similar missions to develop modern tooling for developers. All of the tools below are open-source under the MIT License.
Most of the tools are written in modern compiled languages such as Rust or Go. Many of the tools boast significant performance improvements compared to previous tools, as well as a more modern design with better Developer Experience (DX or DevEx).
As a result, these tools tend to feel both faster and easier to use than the tools that they aim to replace.
Astral’s Mission
We build high-performance developer tools for the Python ecosystem.
Our mission is to make the Python ecosystem more productive.
By building tools that enable developers to ship great software, faster.
Tools that change how we work.
Rye is another tool that was maintained by Astral, however it is no longer developed and uv is considered “the successor project from the same maintainers”.
The Mission
We are building a unified high-performance toolchain for JavaScript: including parser, transformer, resolver, linter, formatter, minifier, bundler, test runner, and meta framework support. Our mission is to make the next generation of JavaScript developers more productive than ever before.
Web Infra
We are from ByteDance, our goal is to build an open technical ecosystem to promote the development of frontend technology.
All of the tools mentioned above are primarily developed and maintained by companies. This raises the question, if the tools are FOSS (Free and Open Source), what are their business models?
ByteDance of course owns TikTok. They make enough money already and can afford contributing to open-source if they so chose. My theory is that ByteDance likely wants to continue contributing to open-source to put them in the same positive light as Western tech companies (for example Meta, who developed many open-source projects including React, Docusaurus and Llama).
On the other hand, Astral and VoidZero are both venture-backed. While they can afford to lose money for a period while gaining users, eventually they will want to find a way to extract value. In the past, when the founders of the companies were asked about this, they gave somewhat vague statements.
However, more recently, Astral introduced pyx (a Python-native package registry):
Beyond the product itself, pyx is also an instantiation of our strategy: our tools (uv, Ruff, ty, etc.) remain free, open source, and permissively licensed — forever. Nothing changes there. Instead, we’ll offer paid, hosted services like pyx that represent the “natural next thing you need” when you’re already using our tools: the Astral platform.
It is likely that VoidZero will go for a similar strategy in the future, by introducing paid services that go alongside the free tools.
The tools themselves are still FOSS, and all are licensed under the permissive MIT License. These companies know that if they ever attempt to change the license or terms for these tools, the community will immediately fork the projects (as has happened many times in the past with other open-source projects).
UPDATE: A lot has changed since I first wrote this article. Both Astral and VoidZero have gotten acquired by tech companies. I wrote about this in a follow-up article: Tech Companies Are Acquiring My Favorite Tools.
I have listed a lot of tools from these companies, of course I have not tried all of the tools mentioned above.
I have been using Astral’s projects, uv and Ruff, and had good experience with both, and I want to try ty as well. As I’m getting more into TypeScript development with React, Docusaurus and Cloud Development Kit (CDK), I have been trying out some of the TypeScript tools as well.
In the case of Docusaurus, I tried Docusaurus Faster which uses Rspack (by Web Infra), as well as SWC and Lightning CSS. This makes it almost as fast as Rspress (another project by Web Infra). The difference in build times is immediately noticeable compared to building Docusaurus with Webpack.
The speed difference is also felt in uv; compared to pip, uv downloads the same packages noticeably faster. I have further explained my love for uv in uv is incredible.
Ruff works well as both a Linter and Formatter. Ty does the same for type checking in Python.
Besides the speed, I have also noticed these tools tend to be easier to use than the older, less modern tools that the aim to replace. The focus on Developer Experience (DX or DevEx) is apparent.
Recently, I have been trying out TypeScript Linters and Formatters and wrote about the Rust Alternatives. Oxc looks promising, it currently has a Linter, while the Prettier-compatible Formatter is still under development. Once the Formatter is ready, I will try using Oxc (instead of ESLint + Prettier), at least for projects that don’t require specific ESLint plugins that aren’t yet supported by Oxc.
Out of all the projects I listed here, Vite is probably the most widely used. It’s popular enough to have gotten its own documentary: Vite: The Documentary - YouTube
I have been using Vite for React apps, notably CALMe. Ever since create-react-app has been deprecated, I have been consistently seeing Vite as one of the top recommendations, including in the React Documentation: Creating a React App and Build a React app from Scratch.
Vite is being integrated with Rolldown: Rolldown Integration | Vite
Featured image by Anton Savinov on Unsplash.
]]>I have recently learned about uv and the uv workflow. Since then, I’ve been using uv a lot more, both for personal projects and at work!
My conclusion is: if your situation allows it, always try uv first. Then fall back on something else if that doesn’t work out.
While reading more about uv, I found these two articles:
What’s interesting, is that these both of these articles each link to older articles where they each extensively compared tools for Python dependency management.
The articles reach similar conclusions, in that the existing tools can be useful but have limitations. However, both articles have been updated to have disclaimers at the top:
This article is really old.
If you want to see how I manage my dependencies since 2024, the short answer is uv, and the long answers are:
Spoiler: Everything got pretty good.
THIS ARTICLE HAS BEEN WRITTEN BEFORE UV EXISTED. UV SOLVES MOST OF THOSE PROBLEMS. YOU CAN TELL PEOPLE TO “SIMPLY” USE UV.
As far as I am aware, the authors were not inspired by each other. They both tried to solve the problems of Python dependency management, found the previous tools lacking, and now love uv.
I have personally not compared every single Python dependency management tool, but do give weight to the opinion of those who have. In the past, I have heard about tools like virtualenv, pyenev, poetry and others, and decided to simply stick with pip and venv. However, after hearing increasingly good things about uv, I decided to try it myself. I have now used it for several projects, both work and personal projects. My conclusion: it’s good.
I don’t know if I will be using uv for every project. As good as uv is, I am still sometimes hesitant to add a new build dependency. I also had some concerns about the venture-backed nature of uv (which I addressed in when writing about the Business Model in Next Generation Tooling for Developers).
At the same time, uv works really well and is even fun to use, so I’ll probably trend towards using it more often than not. The fact that the tool is open source and strives to conform to Python PEP standards also makes me feel comfortable using it. For example, uv works with pyproject.toml. In theory, I could replace uv with another tool in the future but still use the same file. I looked at what it takes to use pyproject.toml on its own and found this article: Python packages with pyproject.toml and nothing else | Simon Willison’s TILs. This shows me that it’s possible to work this way without using a tool like uv, however using uv makes things much easier!
Featured image by Point Blanq on Unsplash.
]]>