Biome, Toolchain of the Web

Rate this content

Biome wants to provide an all-in-one experience for web developers while maintaining performance and quality. Emanuele, lead maintainer of the Biome project, will walk through Biome’s tools:

- A formatter with 97% compatibility with Prettier of JavaScript, JSX, TypeScript and TSX files.

- A linter that offers informative and descriptive diagnostics, with modern lint rules exclusive to Biome and others inspired by the most famous ESlint plugins.

- An opinionated import sorting. An excellent tool offered by Biome Analyser.

- First-class support for editors that support LSP. What you get from the CLI, you get in your editor.

At the end, Emanuele will discuss the plans for 2024 and what the team would like to achieve this year.

Emanuele Stoppa
Emanuele Stoppa
19 min
04 Apr, 2024


Sign in or register to post your comment.

Video Summary and Transcription

Biome is a toolchain for web projects that provides formatting and analysis. It offers high-quality diagnostics and is compatible with Prettier. Biome's analyzer includes over 200 unique lint roles and provides informative error messages. Pion, a part of Biome, aims to be fast and efficient, outperforming other tools. Biome is exploring type inference and plug-in support, and has plans to revamp its configuration in version two.

Available in Español

1. Introduction to Biome

Short description:

Today I'm going to talk about Biome, the toolchain of the web. Biome is a toolchain that wants to provide only one experience for your web projects. It offers Formatter and Analyzer, and aims to provide high-quality diagnostics. Biome is Prettier compatible and offers formatting for JavaScript, TypeScript, JSX, and TSX files. It also has the ability to format broken code as an opt-in feature.

Hello everyone. Today I'm going to talk about Biome, the toolchain of the web. Before going forward with the presentations, I will introduce who I am. My name is Emanuele Stoppa. I'm one of the core contributors of the Biome project and core contributor of the Astra project. I live in Ireland, I'm Italian, I like traveling, and I'm a avid console gamer currently playing Final Fantasy VII.

So let's go with Biome. So what's Biome? So Biome is a toolchain that wants to provide only one experience for your web projects. At the moment, Biome offers Formatter and Analyzer, and we're going to check what are those. Plus, as a mission, I must work and offer the same developer experience on the CLI and the LSP, so editors, and it wants to offer high quality diagnostics.

Now what's a modern toolchain? So well, last year I went to the GIA nation and I talked about the former Biome which was Rome and now Biome and Rome wanted to take all these tools that we wanted that you might have in your web projects and offer just one single toolchain and you use just theoretically, you just use that for everything. Although, well, I mean, let's be realistic. That is not possible at the moment. I mean like, sure, that's still the utopoistic mission, but I want to offer a different point of view of the modern toolchain. So as a modern toolchain, we want to actually own the key operations owned by the software. So parsing, diagnostics, formatting, the linter, and code suggestions, assists. So essentially the things that we actually care and around the toolchain. As a modern, we will also be informative, innovative, and want to offer features that you haven't seen before. So it's really interesting. I mean, let's see further what Biome can offer.

So let's talk about the formatter. So Biome formatter is actually Prettier compatible. It means that it formats as Prettier and we all know that Prettier offers a really nice opinionated formatting experience. Biome is 97 percent compatible by formatting JavaScript, TypeScript, JSX, and TSX files. And it also offers the same options that Prettier does, except for a few that we decided to remove because we feel they are old and not necessary anymore. And also something that Biome formatter does that Prettier can't is actually formatting broken code. Yes, exactly. That's what Biome formatter can do. It's an opt-in feature and it actually works. In this video, we have the while statement that is broken and misses a parenthesis.

2. Biome's Analyzer and Unique Roles

Short description:

You can opt in with Biome and have your formatting working out of the box. The analyzer offers linter and import sorting, with over 200 lint roles, some of which are unique to Biome. Biome also offers import sorting and follows rule pillars for informative and useful error messages.

You would use Prettier and you won't be able to do that. You can opt in with Biome and there you go, you have your formatting working just, you know, out of the box. This is one of the features that a modern toolchain such as Biome can provide.

Let's move forward with the analyzer. So the analyzer is quite a metty feature that offers things like linter and import sorting. So as a linter, Biome offers more than two hundred lint roles. Some of them are quite unique to Biome. Many of them are actually taken from ESLint and the most popular ESLint plugins. The analyzer also offers import sorting out of the box and the Biome lint roles are informative and teach you actually something. So let's see what it means.

So among all the other roles, I want to show you some exclusive Biome roles. You can't find in other linters and hopefully the other linters will adopt them. So, for example, use while or another really nice is no cost enum, which is quite quite nice and we'll see what it does. So I mean, it's not just we don't just copy paste what we have, but Biome offers something more than the existing tools have to offer. It offers also an import sorting, so import sorting Biome is just an assist role. It's just a rule different from a lint role, but still a rule that does essentially the import sorting. And we have our Biome has its own logic, which is explained in the documentation. And essentially it's a proof of how powerful is the infrastructure of Biome analyzer. And also it's informative. So internally we have this thing that we call a rule pillars. So when we create the role, we try to adhere to these pillars. And what are those? So a rule might essentially explain as a first rule explain the error to you like, okay, a rule is triggered. You actually want to know why it was triggered. But actually, we want to know the actual error. But then you also want to know why it was triggered. Like you can just say, okay, this is an error. You actually a rule should tell you why. So you know, and you learn from the actual rule. And then as a third pillar, a rule should always explain you what you should do. Okay, you get the error, you know why but now what do I do? So most of the times you get the code fix.

3. Introduction to Biome's Diagnostics

Short description:

The rule suggests how to fix the code and offers a code fix. The diagnostics provide refreshing and different error messages, including file, row, column, category, tags, message, code frame, and code action. This is just an introduction to Biome's offerings, as it is still a young tool.

So the rule suggests how you can fix your code and then you opt in with a fix. But if it doesn't have the fix, it should at least suggest to you what you should do. Like remove this or change this or just don't use that syntax. So this kind of thing and these are pillars. So they are in our documentation. We try to adhere to this. This is just an example. So we take this rule, Knock on Steam tells you about the error. It tells you why you shouldn't do this. And at the end, it offers you a code fix. Okay, perfect. We got the glimpse of a diagnostic. So diagnostic, it's usually used in my own to actually give messages to you, to the user, to the developers. And as you notice, they are quite refreshing, you know, they are different and also nice to see.

So let's break down this diagnostics, okay? Perfect. So we, as you can see, at the top left, we have the file that triggered the actual rule and we also have the row and the column of the error. And then we offer this diagnostic category, which usually in this case, it's essentially the rule name, but sometimes can be like a format check. It depends on the context. Then we have this other thing that we call tags. Tags are essentially metadata that should hint the nature of the diagnostics. So in this case, fixable means it's a diagnostic of something that you can fix. We also have like internal, which is some error that we throw internally. So it's an internal error, it's not caused by the user. Then the actual message, a code frame, more messages. So it has an I, means it's an info. We can offer additional information to the diagnostic. And then we can also have a code action that offers itself another code frame and another message. Nice, isn't it? Perfect.

So this was like an introduction to what Biome offers. And now, Biome is really young.

4. Biome's Achievements and Future Plans

Short description:

Biome won the Prettier Challenge, achieving 25% compatibility and obtaining sponsors. It has a growing community and a roadmap for 2024 that includes supporting more languages.

It was born like at the end of August, initial September, but like it achieved a lot. And I show you what. So Biome won the Prettier Challenge. So a few months ago, the creator of Prettier opened a bounty saying, OK, if you can create a Prettier alternative with Rust, I'm going to give you $10,000. Those $10,000 eventually became $20,000. And we won the challenge, Biome did. It achieved 25% compatibility, but now even more with Prettier using Rust. So that was achieved thanks to our community. The money was distributed to all the people that contributed to the challenge. Only just a few amount was kept in our open collective. The rest of the funds were distributed proportionally to the amount of contributions that people have done during the challenge. We achieved 20k weekly downloads a few days ago. So in six months, this is actually a great achievement.

We also obtained sponsors. So we have one gold sponsor and two bronze sponsors. So if you're looking for visibility, I believe Biome is a really good project. It gives you exposure to all these developers that are moving to Biome or trying Biome to have a different or even better developer experience. And it was also acknowledged by other developers in the community on Twitter. And they were actually quite happy about the user experience and the developer experience offered by Biome. We also have a really growing community with the proper governance here. All the people that essentially are part of the maintainers and contributors team.

Now, let's talk a bit about Biome in 2024. So in January, we published our roadmap. So it's a yearly roadmap. We have just a bunch of contributors and volunteers that do this in our own free time. So we can do things like big companies can do. But we want to be realistic. We want to offer something achievable. So in 2024, what we want to achieve is the following. So we want to try to support more languages.

5. Pion's Capabilities and Speed

Short description:

CSS has been completed. Next will be HTML and Markdown. We want to make our current tools more powerful and explore transformations, cross linting, plugins, and type inference. Pion is also incredibly fast, outperforming ESLint, PTR, and Dprint.

CSS has been completed. We're now working on formatting and linting. Next will be HTML and probably Markdown, more down the line. We want to offer more capabilities. So with this, we can actually make our current tools even more powerful, such as project analysis and dependencies analysis. This will allow us to provide more lint roles and more powerful and make the current rules more powerful.

Transformations such as compiling your TypeScript to JavaScript or JSX to JavaScript. Embedding formatting. So like Pretier does where you have your CSS with the template literals, this is something we would like to achieve and explore. Cross linting is a feature that maybe only Pion can do or could offer. Essentially, an example could be you have your CSS classes that are analyzed in CSS files and then you have JSX and we could actually lint if you're using like CSS classes that don't belong, that aren't defined in the CSS files. We explore plugins. We're actually exploring plugins. We have some work already there and various RFCs. So we don't know yet how a Pion plugin will look like. How can you do that? But we are actually starting, we started shaping this big and wanted topic. And also want to explore type inference. So like we don't want to actually replace TypeScript, the type check type checker. That's unrealistic. I mean, Microsoft has a huge team for that. We actually want to explore type inference. So having an infrastructure that is able to infer types inside the code and then provide lint rules that leverage this eager type inference.

So that's it for Pion. Actually no, there's one more thing that I think is that I think that's the most important thing that I haven't mentioned, but I haven't forgotten. So Pion is a freaking fast. So other than offering new features and diagnostics and all these kinds of things is actually really, really fast. So it's up to five times faster than ESLint on a single thread and is faster than PTR and Dprint in orders of magnitude. Pion leverages single threads, leverages channels, and it leverages a really great logic in terms of caching and memory management. Things that some of them are possible in the JavaScript ecosystem, but some of them aren't achievable with the tool that JavaScript offers. You don't believe me? Well, here's a small video.


Pion's Analysis Speed and Poll Results

Short description:

I downloaded three repositories, Rollup, Webpack, and the old RomTools to demonstrate the speed of Pion's analysis. The Webpack code base took a second for 6,000 files and five seconds for 13,000 files. The poll question revealed that most people answered maybe when asked if they would use Pion in a new project instead of Prettier and ESLint. Emmanuel is positively surprised and appreciates the willingness to give Pion a chance. Let's jump over to the questions.

So I downloaded three repositories, Rollup, Webpack, and the old RomTools when it was in TypeScript and see for yourself. I just run the check command, which essentially runs a formatter and the analyzer in the whole code base and I haven't printed any diagnostic for just to show you how just analyzing the files is freaking fast. And yes, as you can see, like the Webpack code base took like a second for 6,000 files and five seconds for 13,000 files in their tools repository. I mean, like the tools repository also contains like huge, huge files and complex files for testing the conformance of JavaScript files and things like that and see how long it took. So, yes, that's one of the most exciting things about Pion and it's actually real. So it actually works. So it's easy for yourself. So thank you very much and have a nice day.

Thank you so much for joining us, Emmanuel. First of all, let's jump over to the poll question actually that you post to the audience up front and let's just take a look here. So in general, you asked, would you use Pion in a new project instead of using the combo of Prettier and ESLint? And overwhelmingly, people answered, maybe. Is that a surprise to you? It's a surprise. Yeah, yeah. I'm surprised, but positively. Like, I mean, let's consider it, you know, like I know that Pion is still not as mature as these other two tools, but I mean, the fact that people are willing to give it a chance to try. I mean, it's good. I mean, Pion was born like six months ago, more or less, so it's good. Yeah. And I also feel like it's the typical, not skepticism, but obviously whatever we introduce into the code base, we're also responsible for it, right? So we don't want to be the one that introduced something completely new and then, you know, it has somebody complain about it because we introduced it recklessly. So I feel like maybe, a resounding maybe, with, you know, the second place being a lot of people saying yes, by the way, which is also really cool to see, you know, obviously that's a very, you know, developer thing to do that. Sure. Like, I'll consider it. I'll take a look at it. And I feel like, you know, maybe it's definitely a good preparation for a yes. So thank you so much, everyone, for submitting that. I feel like this is very encouraging to Emmanuel as we speak, the yeses creeping up. So let's just keep the conversation rolling here a little bit. Who knows? Maybe the yes will overtake it. I feel like that would make you a very, very happy open source maintainer, Emmanuel. Let's jump over to the questions, if we could highlight those.

Type Inference and the Need for Linting

Short description:

Type inference is a different approach being explored by Biome instead of just replacing TypeScript. Biome aims to provide enough infrastructure to replace ES lint rules that require type checking. While some may question the need for linting in JavaScript, it serves to avoid dangerous patterns and fix bugs. Other languages like Rust also require this kind of analysis. Auto formatting, like the prettier part, creates a standard across projects and facilitates code readability and consistency.

And the first question is, can you share some insights about the type inference that was mentioned in the roadmap? Sure. So, in the roadmap, we briefly explained that we want to try a different approach to, instead of just replacing TypeScript, which is now the de facto type checker of the web ecosystem, try to have a different approach instead, like using a type inference, which is different from a type checker. So it's just a matter of trying to guess as much as possible to be like an eager inference, okay, and provide the infrastructure, enough infrastructure to replace those ES lint rules that require exactly type checking. So all these rules that a lot of users are requesting, so we want to try to provide them using this type inference project. There are also already some works in the web. There's this project called ESNO that uses this kind of heuristics. And it works even for JavaScript. So you don't even need TypeScript. And that's what we want to try to achieve.

The next question, I feel like it's more of a philosophical one. Do you believe that a time will come when linting of JavaScript or TypeScript project becomes unnecessary because maintaining ES lint configuration often is a huge burden for marginal lint gain? What are your thoughts there? I don't think so. I don't see it, to be honest. Like JavaScript is a really dynamic language. And because of that, you can do everything. You can just break everything, prototype pollution, you can change everything. So linters are there just to avoid certain dangerous patterns, try to fix bugs and find things that you can find during the parsing phase. So because of that, actually I think it's something that we should actually improve in the future, have better tools that just takes care of everything. And you can just write code with peace of mind and without worrying about some security issues or things like that. That's the nature of the language. But also like other tools that are more strict like Rust and other strictly typed languages require this kind of analysis. So yeah, I mean, I don't see a future without them.

So it is kind of interesting, right? If we go and take a look at other languages like the Go language, for example, right? They sort of have the linter built into the language design, which I think is very telling. Myself, it's interesting. I kind of like this question because on the one hand, yeah, I don't even care about whether people add a semi-colon there or how many spaces they use. I feel like it's almost a silly exercise to have something in there that will constantly sort of reformat it. But what you're bringing up is actually the security thing, right? It sort of helps you avoid dangerous patterns. What would you say about the sort of the auto formatting of code? The prettier part of it, like what in your mind is sort of the benefit of that and like why is it still a good idea for projects to have Biome sort of take care of making the code pretty, essentially? Yeah, yeah. Well, looking at other languages and ecosystems, the fact of having all the same projects being more or less formatted the same is actually really good because you can jump from one code base to another and see every time the same patterns, the same way the code is actually formatted. It's actually really nice because you actually create also a standard across the whole language, apart from tiny changes that, you know, it's a formatter.

Biome's Plug-in Support and Performance

Short description:

Biome is exploring a DSL approach for linting rules, using grid QL as the query language. The team is working on creating the engine for lint rules using the DSL. JS and TypeScript APIs are requested, but will require more time and attention to performance. Biome aims to be fast and efficient.

It's actually really nice because you actually create also a standard across the whole language, apart from tiny changes that, you know, it's a formatter. So it's based on stylistic preferences. I enjoy formatters. I like them. I mean, I wouldn't live without them. So it's I mean, I like them. So I push for their usage. But I mean, there are people that don't need them. But looking at the other languages, it's a great DX, I would say. I feel like that's a really, really strong argument. Take a look at other languages. They already have it built in.

What's the current progress around plug-in support is one of our next questions. Ah, that's a great question. So progress is so we are exploring a DSL approach for linting rules. So one of the core members is actually chose this language called grid QL. So we actually have already a parser to essentially parse this query language. And we actually working now on the engine. So having a way to create lint rules using the DSL and then biome essentially gives you data analysis. So that's the initial idea of our plugins. A lot of people requested JS and TypeScript APIs. We will explore them as well. But they will require more time because it's always jumping from the binary to another the binary. So there's a lot of going on. And it will require more time in terms of performance, which is at stake here because biome needs to be fast. So that's something that we care about.

Awesome. Thank you so much. Super, super fascinating stuff to see.

Biome's Version Two and Gratitude

Short description:

Biome version two will remove deprecations and revamp the configuration based on user feedback. The CLI will also be revamped with consistent options and comments. Migration patterns will be provided to ease the transition. Emmanuel expresses gratitude for the Q&A session and thanks the audience for attending.

Super, super fascinating stuff to see. So as maybe one last question, if you could give people just a quick sort of glimpse into the future, what should users expect from biome version two?

So for v2, we're going to remove all the deprecations that we introduced when we fought biome. So like all the Rome stuff that we had, we plan to revamp the configuration because we are a toolchain. We have a big configuration. We want to refine them based on user feedback. And our other projects are tackling certain things like linting and things like that.

So we're going to also revamp the CLI with having more like comments that are the same across like options that are the same across comments. So I don't see a lot of breaking changes, but the one that we foresee, we can also provide some migration patterns so people shouldn't be too scared. We have our own migration command that takes care of everything. So we hope that to not provide too much breaking changes for v2.

Awesome. Thank you so much, Emmanuel for being here for this Q&A session. And also thank you again for this really, really amazing talk. Super excited to have you here. Thanks again, Emmanuel. Thank you for having me and I hope you enjoy my talk.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vite: Rethinking Frontend Tooling
JSNation Live 2021JSNation Live 2021
31 min
Vite: Rethinking Frontend Tooling
Top Content
Vite is a new build tool that intends to provide a leaner, faster, and more friction-less workflow for building modern web apps. This talk will dive into the project's background, rationale, technical details and design decisions: what problem does it solve, what makes it fast, and how does it fit into the JS tooling landscape.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
How Bun Makes Building React Apps Simpler & Faster
React Day Berlin 2022React Day Berlin 2022
9 min
How Bun Makes Building React Apps Simpler & Faster
Bun’s builtin JSX transpiler, hot reloads on the server, JSX prop punning, macro api, automatic package installs, console.log JSX support, 4x faster serverside rendering and more make Bun the best runtime for building React apps
The Inner Workings of Vite Build
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Inner Workings of Vite Build
Vite unbundled ESM dev server and fast HMR are game-changing for DX. But Vite also shines when building your production applications.This talk will dive into how the main pieces fit together to bundle and minify your code:Vite build as an opinionated Rollup setup.How esbuild is used as a fast TS and JSX transpile and a minifier.The production plugins pipeline.Modern frameworks (Nuxt, SvelteKit, Astro, among others) have chosen Vite, augmenting the DX and optimizations for their target use case.We'll discover Vite as a polished and extendable toolkit to craft optimized modern apps.

Workshops on related topic

Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
Hussien Khayoon
Kahvi Patel
2 authors
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.