Biome, Toolchain of the Web

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.

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.

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.

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.

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.

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.

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.

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.

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.