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: VoidZero has launched Vite+.
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.
]]>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.
]]>