Biome and the Future of JavaScript Tooling

Modern web development requires an ever-growing collection of tools including formatters, linters, bundlers, and plugins. Each tool typically has its own configuration, dependencies, and performance cost. As applications grow more complex, the overhead of maintaining this toolchain becomes a real burden. Biome https://biomejs.dev/ is an open source toolchain for web projects that brings formatting and linting together in a single fast, opinionated tool. It’s built in Rust and is designed to be a drop-in replacement for Prettier and ESLint, with sensible defaults, minimal configuration, and consistent behavior across the CLI and editor environments. Biome also introduces a module graph that enables cross-file analysis, and type-aware lint rules that don’t require the TypeScript compiler. Emanuele Stoppa https://www.linkedin.com/in/emanuelestoppa/, known as Ema, is a Senior Systems Engineer at Cloudflare, a lead at Astro, and the creator and lead maintainer of Biome. In this episode, Ema joins Josh Goldberg to discuss the history of Biome, how linters and formatters work under the hood, what makes Biome’s architecture fundamentally different from the tools it replaces, and what’s coming next for the project and its community. Josh Goldberg is an independent full time open source developer in the TypeScript ecosystem. He works on projects that help developers write better TypeScript more easily, most notably on typescript-eslint: the tooling that enables ESLint and Prettier to run on TypeScript code. Josh regularly contributes to open source projects in the ecosystem such as ESLint and TypeScript. Josh is a Microsoft MVP for developer technologies and the author of the acclaimed Learning TypeScript https://www.learningtypescript.com/ (O’Reilly), a cherished resource for any developer seeking to learn TypeScript without any prior experience outside of JavaScript. Josh regularly presents talks and workshops at bootcamps, conferences, and meetups to share knowledge on TypeScript, static analysis, open source, and general frontend and web development. Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2026/06/SED1935-Biome.txt Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected] The post Biome and the Future of JavaScript Tooling https://softwareengineeringdaily.com/podcasts/biome-and-the-future-of-javascript-tooling/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  Modern web development requires an ever-growing collection of tools, including formatters, linters, bundlers, and plugins. Each tool typically has its own configurations, dependencies, and performance cost. As applications grow more complex, the overhead of maintaining this tool chain becomes a real burden. Biome is an open-source tool chain for web projects that brings formatting and linting together in a single, fast, opinionated tool. It's built in Rust and is designed to be a drop-in replacement for prettier and ES lint, with sensible defaults, minimal configuration, and consistent behavior across the CLI and editor environments. Biome also introduces a module graph

• 0:44Speaker 00

  that enables cross-file analysis and type-aware lint rules that don't require the TypeScript compiler. Amanuela Stoppa, known as Emma, is a senior systems engineer at CloudFlare, a lead at Astro, and the creator and lead maintainer of Biome. In this episode, Emma joins Josh Goldberg to discuss the history of Biome, how linters and formatters work under the hood, what makes Biome's architecture fundamentally different from the tools it replaces, and what's coming next for the project and its community. This episode is hosted by Josh Goldberg, an independent, full-time, open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ES lint,

• 1:29Speaker 00

  a powerful static analysis toolset for JavaScript and TypeScript. He is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for Developer Technologies, and a co-founder of SquiggleConf, a conference for excellent web developer tooling. Find Josh on Blue Sky, Thostodon, and dot com as Joshua K. Goldberg.

• 2:03Speaker 01

  With me today is Emmanuel Stopa, open source maintainer at CloudFlare, creator of Biome and lead at Astro. Emma, welcome to Software Engineering Daily.

• 2:12Speaker 02

  Thank you for having me, Josh. How's it going?

• 2:15Speaker 01

  Things are good. I'm excited to talk to you. You've done quite a few interesting things in tech. Recently, you've been on Astro, you joined CloudFlare, you're a creator, lead maintainer of Biome. Before we get into all that, how did you get into coding?

• 2:26Speaker 02

  Well, maybe the majority of the developers out there were like, I want to develop video games. So that's essentially why I got into coding. Things didn't plan as I thought they were. I went to university where they were supposed to teach game design, but in the year where I was supposed to join that class, there was no professor. So I had to choose another class and eventually I haven't done anything around video games. So I ended up doing PHP, Postgres and all the stuff that Web Dev was at that time. And that's how I started.

• 3:05Speaker 02

  So then it was PHP developer, jQuery and so on until like React and all the cool kids that we have now.

• 3:15Speaker 01

  Do you have any emotions that come to mind when you think about developing front-end full-stack apps in PHP and jQuery?

• 3:22Speaker 02

  Yes, because I see a lot of partners that I used to use back in the day coming up, like SSR. Before, it wasn't a thing, like React developers and it was all about SPAS everywhere. So everyone was developing single-page applications. And that SSR came back because that's how you used to do things in PHP. So like, I mean, there's nothing new here. We are just doing things as they were, just using JavaScript instead of, I don't know, PHP, C# or Java, you know, at that time, that's what we had. So it's kind of weird because like we are not inventing anything. We just, we are not inventing the will.

• 4:07Speaker 02

  There's nothing exciting, you know, it's just the same patterns using different tools, different libraries. I like the tools that we have now simplify the process. Back in the day when I wanted to do spas or islands, for example, it was a mess. Now, we know how to do this kind of things. The libraries allow us to do that. So I was like, oh, thank God, now we can do things very quick.

• 4:35Speaker 01

  It's lovely that we've learned how to do the same proper techniques, but with a lot cleaner syntax now, which brings us to kind of a transition for you. You started off as a sort of standard developer, working on apps, PHP, jQuery and so on. But at some point you transitioned to dev tooling. And one of the earliest projects that you were associated with in that space that got a lot of interesting news was Rome. Can you tell us about how that came to be and what that is?

• 4:59Speaker 02

  Yeah, so Rome, Rome Tools was a project that was supposed to be like only one tool for all your web projects. So having formatting, bundling, testing, everything in one single application or binary or whatever. And I really liked it, the mission behind it. In the past, I always struggled to maintain a lot of these dev libraries, such as formatters, lenders, bundlers, plugins. And Rome was like a breath of fresh air. And I was looking for an open source project to contribute to. So, yeah, I mean, let's do it. That's how I joined the mission.

• 5:42Speaker 02

  Rome at that time was in TypeScript. And eventually Rome got some funding. They opened the company and they joined as an employee of the tool. That's essentially how I got there. But like my passion to open source came before also Rome. I was involved into Webpack before that. I was part of the CLI team. And why? Because like I fought with Webpack a lot of times in my working experience with all the companies where I've worked. And I became a kind of an expert. I was also on Stack Overflow, answering questions and things like that.

• 6:23Speaker 02

  So I wanted to increase my knowledge around Webpack. And that's how you do it. You just go into open source and you learn stuff from the actual creators.

• 6:35Speaker 01

  How did you make that jump from learning about Webpack to contributing back to it or to helping others? It seems like kind of a scary cliff for a lot of people, a gap in difficulty levels.

• 6:47Speaker 02

  Yeah, it is. It is scary, but at the end, like, you just have to do it. It's like a leap of faith. So, and you come to understand that you can't know everything. So you have to make the peace with it and just say, I don't know this, I don't know that, but I have experience with this thing. So maybe that's your solution, maybe this is your other solution. So once you understand that you can't know anything and you have to accept that others might have the answer, just gets easy. So eventually you just do your stuff that you want to do and you try to learn what you want.

• 7:29Speaker 01

  And for you, that's been simplifying those complex tech stacks you've mentioned into something a little easier to wrangle?

• 7:35Speaker 02

  Yes, yes, exactly. Before tooling, I was in front end and it's a completely different world. Like tooling requires a lot of different knowledge from front end, but there are some similarities. There are some lessons that you can take from front end and there's accessibility, error handlings, and fighting with browsers, fighting with things that don't work in a lot of contexts. Take them into your tooling and, for example, error handling, it's the same. Like you have your user that does a mistake, you have to handle it. You have your backend that does something funky, you have to handle it. Same for tooling.

• 8:17Speaker 02

  You always have your user that he puts something via CLI, for example, and you have to essentially provide some decent feedback. So it's a different context, but at the end, it's a product. You have your users and you have to provide something good that they like. So it's not that scary and yeah, I mean, in programming, you always have the same problems, more or less, different context, but at the end, it's just about data. You get some data, you have to parse them and then do something with it. And if it doesn't work, you just send them a good feedback. If it does, you send the feedback that the user wanted.

• 9:03Speaker 01

  Functional programmers may be pleased to hear that, that everything ends up turning into a function that returns one of two types.

• 9:09Speaker 02

  Exactly.

• 9:11Speaker 01

  Let's talk about that doing something with it, because you've worked on several projects now that do something with code that build it. So at the very barest, before we go into the details, what is a builder or what is a bundler?

• 9:22Speaker 02

  Oh, well, bundler, what it is? Well, as you said, like a bundle is a linker. So it's like taking different files and just create something that is linked all together. In modern programming, now in the web ecosystem, we have a bundler that has to take a lot of JavaScript files scattered in your application and dependencies, and eventually creating something that it's pleasurable to use in the browser for you as a developer, but especially for users, your end users. So you have to ship something that doesn't break. You have to ship something that doesn't, takes a lot to download, for example.

• 10:04Speaker 02

  So you can't ship all like a file of your old dependencies. Otherwise, it's like megs of megs of JavaScript that your user is to download. And I mean, it has to deal also with a lot of different things like HTML, CSS, SASS, Less, TypeScript, CoffeeScript, Wasm now, and a lot of stuff. So a bundle nowadays is actually, from my point of view, one of the most difficult and rewarding software that you can create or contribute to, because there's a, there's a lot of to care.

• 10:42Speaker 02

  And I think it's like it's a, you learn a lot if you, anyone wants to work on it, because there's a lot of, and also source maps as well, so.

• 10:55Speaker 01

  Yeah, there's a lot going on there. Let's say that I have just the most barest of applications that uses imports and exports. I got an HTML page, a JavaScript file that imports from a couple of node modules, maybe another JavaScript file that imports that one and calls it. And I want to turn that into some dot com website, and I'm going to use a tool to do that. First of all, do I need to use a tool? In what situations can I, if any, get away without that?

• 11:20Speaker 02

  Well, you could use a tool, but also you can't. It depends on your taste. Like back in the day with PHP and this kind of things like you didn't need to. You just have your PHP file. It means your JavaScript and everything. So you had everything out of the box. Nothing's got more complex. Our users need more. The browser has more capabilities. Like we are recording our session on a browser. Something that we couldn't do 10 years or 15 years ago. So capabilities increased. We have more tools at our disposal. So even the applications got complex based on what we want to ship.

• 12:03Speaker 02

  So eventually you want to use a tool. Like it simplifies a lot of boilerplate, like setting up the page or DMS or even JavaScript doing interactions and things like that. You could do it yourself, but there's a lot of going on nowadays. So you don't want to do it and you want to focus on your app. You don't want to focus on the boilerplate. So yes, nowadays you should use a tool that simplifies all the basics. And so you can focus on creating whatever you want on the browser or even Electron where you have your native app. So you see the capabilities increased.

• 12:46Speaker 02

  We have endless possibilities.

• 12:49Speaker 01

  All right, you've convinced me. For my HTML and a couple of JavaScript files page, I know it will get more complicated, so I will use a builder or bundler. How does that actually work? How do we go from that source code split across different JavaScript files to something that gets run by users with all those optimizations you talked about?

• 13:08Speaker 02

  That's a really interesting question. I don't have a clear answer, but like as a developer of some tools that does the kind of things such as Astro, how does it work? So you have a concept of pages, which are essentially your entry points where your user lands, okay? And from there, you essentially start building your tree of dependencies, which are styles, CSS files, components, JavaScript files, anything that your page requires. And that's how your bundler works. So you have your entry points where your user needs to interact, call them pages.

• 13:53Speaker 02

  So in most of the cases are synonymous entry points or pages. And there, your bundler creates a tree of dependencies of assets, essentially, what it needs to ship in order to render and make the page functional. Of course, there are a lot of challenges like understanding the CSS files. Now these things got more complex because styles in some applications are shipped together with some components. So they are like atomic, like take for instance, Views, Belt and Astro. They have the console of components, single file components.

• 14:36Speaker 02

  And each file component can contain a piece of JavaScript, can contain a piece of HTML and a piece of styling. So when you have multiple components that are inside the tree, you also need to understand the order of how this style needs to be bundled together in order to actually not mangle the end result. Like you could have your button that is imported in the middle of the tree or in the end of the tree. And then you have to decide, okay, now what's the order? And that's what the bundler does. So it's responsible to tackle this kind of problems for you. So you don't need to fight them.

• 15:19Speaker 02

  And of course, bugs can be there, but that's what the bundler does for you. And same for JavaScript. So you have a lot of scripts importing in your tree. You have to make sure that they are imported and executed in order. So eventually your button reacts to a form submit or it reacts to an error in your form without breaking other scripts. So that's, I think, like the bundler works.

• 15:50Speaker 01

  It's interesting the way that you describe the assets, because very little, if anything, in your explanation is specific to JavaScript files. So let's say that we have a new kind of asset. Let's say I want to import some .webp image and then use it as a source string in my file. In this system, does that mean that I could have sort of arbitrary extensible plugins for different sorts of assets?

• 16:11Speaker 02

  Yeah, technically, yes. If the bundler allows you to do so. But essentially, yeah, a bundler needs to work like in a very abstract way. But then he has specialized section where he needs to understand what is actually processing. So CSS files, images, which have different extensions or different kind of encoding and things like that. We have Wasm, which also requires its own instantiation and other things. We have fonts, for example. That's another asset that needs to be treated in a certain way.

• 16:50Speaker 02

  So yeah, I mean, nowadays, we are creating bundlers that has to be designed in a generic way and extensible. So users can extend the bundler for their needs. Because not everyone needs to deal with webp images or AVIF or videos, for example. There's also this kind of asset. So in the wild now, we're creating, since webpack area or rollup, we are creating bundlers that are generic and users can extend it. So we are settling on a plugin system where users can essentially do whatever they want with the bundler.

• 17:33Speaker 01

  That users can do whatever they want yields a lot of power for users. But a lot of long-lasting web developers may remember that power comes with a cost. Let's talk about two of those costs here. Performance and configurability or ease of use. There are horror stories out there of multi-thousand line webpack configs that are slow. What would your response to that be?

• 17:57Speaker 02

  So my, let's call it belief or opinions on plugins have shifted a lot recently, especially now that I'm dealing with Biome, which is built with a native language, and Astro, which is completely different, uses plugins. So, as you said, there's a cost, and I feel like people shouldn't pay that cost. Like, you have a lot of extensibility, but yes, as Aker, that's nice. You do your project weekend, you can create your plugin, and you have a sense of power, like you're doing something great, because you're creating stuff.

• 18:41Speaker 02

  But then there's the other side of the coin, which is you are at work, you are responsible for maintaining the product of your employer, and that's the cost you pay. You have a lot of plugins, you have a lot of extension integrations that you have to deal with, and you have a cost on your application. Sure, then the bundler somehow has to be responsible of it and reduce the performance and make it faster. But at certain point, I think it's not responsibility of the bundler, of the tool, the plugin system anymore.

• 19:21Speaker 02

  It's responsibility of the maintainers of the plugin. And eventually, who pays the cost? The users. So I'm coming to a realization that we need the plugin systems just for certain things. Other things shouldn't be extended too much, but shouldn't be baked into the tool. So like, it can do it correctly, it can monitor the performance, but like, we can't give to our users all these integrations and plugins, and eventually, the performance of the tool degrades, and you end up with WebP that takes like 30 minutes to bundle your application.

• 20:04Speaker 02

  So I don't know, like we're trying to, and we keep trying to solve this problem. Like we have roll up, but now we have roll down that wants to fix it by using a different language and maybe a different architecture. But I think it's not gonna solve everything because like application are gonna be more powerful, demanding and bigger because that's how the technology works. So we're gonna see maybe in three, four years, five years, we're gonna see again the same problems and we're gonna try to solve them the same way. So I can't realization now, maybe we have to do something different.

• 20:45Speaker 02

  So that's why configurations should be static, it shouldn't be dynamic, like they should be predictable. In fact, like I know E S Lint paid this cost and that's when V nine shifted their configuration to be flat, so like it's easily debuggable. Eventually, they couldn't understand like which plugin was making a mess because it was all a recursion. Like it was difficult to debug and so they came to realization, we have to do something. They broke the ecosystem, but I think it was something that had to be done.

• 21:23Speaker 02

  Because as an open source maintainer, I understand where they were coming from and why they did it. Of course, a lot of users were not happy, but I mean, they made a mistake. They had to to fix it. Some users were not happy, but in the long run, I think it's gonna pay off.

• 21:45Speaker 01

  How do you know or how are you able to tell where that balance needs to be drawn between powerful users and comprehensive built ins?

• 21:54Speaker 02

  I don't have an answer for that, to be honest. It's very difficult to draw a line there. I think it's also a matter of try and error, like, okay, you can be a lot of very extensible. So to be honest, I don't know, I really don't know.

• 22:13Speaker 02

  Plugin system allows you to do everything, but if you give it too much, you end up breaking stuff, you end up that you can do a lot of optimizations that you could do if your plugin system was more like tight or has less feature. To give you an example, like Easlin is as a great plugin system and we have plugins everywhere. But it comes at a cost where they can't innovate now. The force of Easlin comes from its plugin system. But now they can't innovate, they can't try new things because otherwise all these plugins they could break, they could degrade without knowing.

• 22:56Speaker 02

  So that's kind of the line, like you should try to give enough power to please your developers and users, but not as much so that you can't innovate. Like you are a programmer, so as a programmer, you also want to look for new things, try new things. Because that's, I think, one of our passions. And if you can't try new things, what's the point? Like at the end, it's just doing maintenance and I don't know, it gets boring. So maybe that's why you ended up with creating new projects and trying new things.

• 23:32Speaker 01

  Yeah, that was a natural cycle where once a project gets successful, that bogs it down. I want to talk a little bit about one of the major new things that a lot of projects, including Rome and Biome and Astro are, which is native speed code. You led the conversion from Rome in TypeScript to Rome in Rust. First of all, why Rust? For those who haven't heard this hullabaloo, why are so many projects switching to specifically Rust or at least native in general?

• 23:59Speaker 02

  Why Rust? So I think like there are two main reasons or maybe three. Let's list them, then we'll count them. So first one, it's a really strict language. So when you have a dependency, there's a less risk to break it. So like it's so tight, the system that even like when you have a major, you have a less breaking changes. Or if you have them, you catch them straight away at compile time. So it gives you the safety of having a lot of dependencies, but at least they break less often as it could happen in TypeScript or JavaScript. So you have less maintenance burden for on your toling. Second was essentially speed.

• 24:43Speaker 02

  Like Rome, when it was in TypeScript, was actually great, but it suffered from a lot of memory consumption. So at that time, Rome was able to bundle itself. So it was like as a binary could bundle itself. And while it was doing that, it was consuming a lot of memory, like eight gigs of memory. It wasn't sustainable. Like it felt like it reached the limit of Node.js. So that's when we decided, okay, maybe we have to go somewhere else. You can try to do a lot of the musicians, but if you can't leverage the actual memory, like, yes, JavaScript has some tooling for garbage collection,

• 25:27Speaker 02

  but it's very, very limited. Rust as a native language allows you to manage your memory way more than JavaScript. And third point is how easy is to integrate with Wasm? So like Rust has a native bindings using the Wasm bind gen crate. So it's very easy to have your Rust code imported into Wasm, so then it can be shipped into browsers, other languages that are able to interpret Wasm and they execute it. That's really great for like a playground and things like that. So I think that's one of the reasons.

• 26:12Speaker 02

  Because like, sure, the language is very typed, but even TypeScript is typed in a different way. So it wasn't the problem. And Rust has gained a lot of traction recently for their memory safety. So you don't need to deal directly with memory like C or C++ or other similar languages, because Rust it does it for you using their borrow checker. So it takes a while to get used to, but it's the language that does it for you. So you don't need to take care about that part. So you can focus on your application.

• 26:50Speaker 01

  It sounds great. Let's jump forward in time a little bit. Rome was around the 2021, 2022 era. How did we get from Rome to Biome? And what is the difference between those two projects?

• 27:00Speaker 02

  Yeah, so for a year and a half, we were good at ROM. We were doing great, but eventually the company behind it went under. So they couldn't get any more money. So eventually they had to close. Thing is, I liked the project. Like I joined the open source project before getting hired and I wanted to continue it. So even after I left the company and I joined another company, I continue to contribute to ROM. Other people joined, so I wasn't the only one anymore. So eventually we had a team of volunteers and we shipped, we continued shipping. Eventually, like I really wanted to change the face of the project,

• 27:44Speaker 02

  but it always requires a lot of work, you know, like logo, names, website domains. So you don't want to do that, you know, you wanna, it's really annoying. But eventually we had to do it because the NPM tokens expired. So we couldn't actually ship and publish new versions on NPM anymore. So we were actually forced to do the move. And why Biome? So like James, which was the CTO at ROM at that time, had this idea in case we wanted to change ROM to call it the second ROM. So second ROM Biome, that was the idea. So I asked him, can I use it? Are you okay with that?

• 28:30Speaker 02

  Yeah, sure, go ahead. And yeah, and eventually, so ROM fell in December. And in August of the next year, we announced Biome as the new ROM. I would say the mission changed slightly because we are not focusing on the bundler, for example, because we have less resources. We don't have people dedicated to the project. So we are now focusing on formater and inter because that's what we had. So instead of going horizontally, we went vertically. So like we shipped more features into the inter and the formater. So more languages, but still like more rules, formatting capabilities.

• 29:13Speaker 02

  But like we are not focusing at the moment on the bundler or the testing suite, stuff like that. So and I think we're happy with that. We are doing still great things, so.

• 29:24Speaker 01

  Yeah, let's let's talk about those great things. Most users I've talked to are not extremely familiar with formatting and linting as concerns. They know that they clean up the code base. Maybe they know that linting does more logic formatting or well formatting white space. What does Bion do for users around formatting and linters?

• 29:42Speaker 02

  So first of all, it creates like it wants to ship a different developer experience compared to the tools that we have. So a better messages, something that you can actually action. You have your error and Bion tells you, okay, that's how you should do it or you shouldn't do it. So some users, yes, they dismiss the linters as like a nice to have. So what we're trying to do is also to teach people how to do stuff. Like we ship this lint rule that targets the dot reduce function of JavaScript and says to not use the spread operator when you return the accumulator.

• 30:24Speaker 02

  And the lint rule tells you, don't do it because it's a performance problem. And I've seen people that didn't know that. And once they know the rule, they learned something. So that's one of the missions, like we have a linter that teaches you something. Because as I told you before, not everyone knows everything. So if we get the chance to teach you something, I think we did good. So we're spreading the knowledge. So that's why our lint rules have to have a really high standard. They have to tell you why it's an error. Because if you're not able to tell why an error exists, then it's not an error. It's a moot point.

• 31:03Speaker 02

  And then like formatting, it wants to just provide a faster experience compared to the tools that we had at that time. Like I know that users in the past were kind of unsatisfied with prettier's performance, which was at that time the only widespread formater in the JavaScript world and the web world. So with Biome, we provide a very similar formatting, but at least it's faster, especially in CI's and things like that.

• 31:34Speaker 02

  But we also like want to provide an experience that is tied also to other tools like Biome knows you're getting your files, for example. So you just hook into them and it doesn't format the files that I ignored in Git. You can also integrate with your editor config, for example. So you have your edit on config, so you don't need to maintain the biome config. You just use what you already have. So it's not just about limiting and formatting, but we also like embrace the other tools so that Biome gets to know what you're using and you learn from them.

• 32:14Speaker 02

  We're doing the same with Svelte, Vue, Astro, CSS modules, Tailwind too. So since like a web dev is quite vast, we don't want to limit ourselves to just one tool, but we think we should actually embrace a lot of them. So users get to know them and you learn something that you might not know.

• 32:36Speaker 01

  You've touched on one of the really lovely parts of using Biome, which is, as you said, it's all in there. You can run the format, the winter, just from one command. How much simpler is it in your experience to configure Biome compared to how things were configured, say, five years ago?

• 32:51Speaker 02

  So I think it's actually really good and fast because you don't lose a lot of time. I still remember when I used to set up ESLint and prettier years ago and it got easier, but like the fact that you have to install three or four packages and then you have to configure ESLint to use prettier's config or plugin, I don't remember. So it was a nightmare. I mean, sure, it takes 10 minutes, but why you have to do that? I mean, you shouldn't spend so much time on these tools. And that's why Biome is there, like you have one config with sensible defaults, which

• 33:36Speaker 02

  means that you just installed the dependency and that's it. You don't need to do anything else. You just use it. If you don't like the defaults, okay. Just you can run bio in it and change the defaults and that's it. Also, you don't need to format the code that is fixed by your Linter because it's all in there. Bion does it for you and it works out to the box in your editor. So what you get in the CLI, you get it as well in your editor. You don't need to do anything like anything at all. Instead, you can install the extension, of course. But other than that, you don't need to install three extensions like prettier or ESLint. You don't need to modify any configuration.

• 34:19Speaker 02

  It's all in there, works out to the box most of the times, of course. So you see, users spend less time in tooling, setting up their tooling so they can do programming as they want. Because that's what we like to do. We don't like to set up tooling.

• 34:36Speaker 01

  Absolutely. Diving into the tooling a bit. Formatting has not changed significantly over the last few years, other than what the defaults may be or configuration. The architecture has been pretty stable. Linting, on the other hand, Biome does linting things quite a bit differently than, say, ESLint that came before. What's different about a Biome lint rule versus, say, a predecessor ESLint rule?

• 34:58Speaker 02

  Okay, so one thing that we recently shipped in Biome, type aware rules and project rules. So we know that we have TypeScript ESLint. Thank you, Josh, for what you shipped to us. So the existence of the ESLint that leverage TypeScript so they provide useful rules, such as no floating promises or no misused promises. But I know that this kind of plugins need to do something that ESLint can't provide, such as scanning the whole project or the whole dependencies.

• 35:38Speaker 02

  Because these kind of rules need to understand not just the file that you have open on your editor, but they have to resolve types, dependencies. So they need to do a lot of work in order to work. And that's something that ESLint Doesn't provide out of the box, but Biome does. So Biome in this case is able to scan your whole project before starting the actual linting, is able to collect a bunch of information so that we can provide powerful lint rules such as no import cycles.

• 36:16Speaker 02

  So is able to fly over all the import tree of your project and understand if you're actually importing the same, you're doing a cycle, is able to scan your dependencies. So it understands if you're using a dependency that is not installed in your package Jason. One thing that, for example, I recently merged is a lint rule that is able to understand if you're using a CSS class that is not defined anywhere. So Biome is able to scan the whole project, CSS files, JavaScript files, view files, all the files.

• 37:00Speaker 02

  It collects all the information and then it does the lint rule that inspects, I don't know, your component, your div or whatever, your element. It reads the classes that you used and it checks if they're actually defined somewhere in your project. And if they're not, this says, oops, you're using a CSS class that it's not defined anywhere. And it's also able to show you the actual tree of components that they were analyzed. And that's something that is provided by the Biome Module Graph, which is a language agnostic in a sense, like is able to collect multiple languages or files or assets in

• 37:44Speaker 02

  the same time, like HTML, CSS, JavaScript and so on. And I'm really proud of what it done because it's something that, like the tools that we have today, they are not able to do that, or I mean, that I'm aware of, of course. So that's what Biome is able to provide that the current tools might lack, or they don't provide out of the box.

• 38:10Speaker 01

  You've mentioned two big features now. There's typed lint rules out of the box and then there's the Biome Module Graph. Talking about typed lint rules a little bit, how does that type information work in Biome?

• 38:22Speaker 02

  Yeah, so in Biome, we've tried to do things differently, because that's essentially our way of doing things, like providing something different from what you have, so you can try it. So Biome does something called type inference. So it actually tries to collect and infer, as it says, the types of your code, like of the JavaScript TypeScript files. So the project and the efforts were led by another core contributor, and Versello actually employed the contributor to actually ship the feature. So it was a great community effort, and it required a lot of resources and time.

• 39:06Speaker 02

  But now we are able to ship lint rules that don't require the actual TypeScript compiler. So you don't need TypeScript to understand if you're using incorrectly a promise, there's a dangling promise that you have and are waiting. How does it work? Well, essentially, the engine relies heavily on the module graph in order to essentially collect and read all the files that the project uses, as well as the dependencies. So it's not just the project, but also all the libraries involved in the application. And then there's a lot of work where it tries to flatten,

• 39:49Speaker 02

  for example, expressions, functions. I don't know all the details, because the efforts were led by another co-member. But I managed to actually fix a couple of bugs there, because the engine requires a lot of tools, such as not just the module graph, but also the semantic model. So just the other day, I fixed a bug where Biome couldn't infer the type of dependency. So there was import function from lowdash, for example, and it couldn't understand if it was a promise or not. So, and I fixed it the other day by integrating the semantic model into the inference system. Or I

• 40:32Speaker 02

  I was able to ship these other rule calls, not necessary conditions, which tells you, oh, you don't need to do this kind of check. Because it's always true, like you have a variable that is always true. So it tries to infer when, for example, it changes value and things like that. And at the end, when there's the if or whatever, it tells you, oh, there's no need to do any child because this variable never changes. So it's true. So I'll please answer your question.

• 41:06Speaker 01

  Very much so. You've mentioned another type of graph now, semantic graph. What's the difference between a semantic graph and a module graph?

• 41:13Speaker 02

  So it's not called semantic graph, but it's called semantic model. So the mod graph is just essentially a data structure that just checks. Okay, so this module, so this file is imported by this other file and so on. So it's very generic. It tells you what imports, what exports, and there it is, nothing else. Semantic model is actually more specialized, is not aware of other files. It's just aware of one file and it's very specialized to the kind of file. So in JavaScript, it specializes into the understanding the various scopes inside a file.

• 41:58Speaker 02

  So you have your global scope, you have scopes inside the functions. Then you have your arrow function that don't have scopes. So you have your classes, they have a different scope. So that's what this semantic model does. For example, it checks as well if a binding is exported or not. So it does very specialized things. For CSS, for example, it focuses on calculating the specificity of your classes. So as you can see, it's very tied to the implied semantics of the language that you're handling. Surely we're going to have, for example, a semantic model for GraphQL.

• 42:42Speaker 02

  I don't know the language, other maintainers have more expertise than me, but I know they're gonna use it, they're gonna create it so they can provide specialized rules. The model graph is just a big pile of data of all your files that you have. It's basically a tree and branches and leaves. And you have your edges, you know, how they are connected to each other. So it's mostly like a spider web and you have to navigate it to understand, to collect the information that you need.

• 43:16Speaker 01

  One of the difficulties with building that rules specifically in native speed code is that many of the end users are its native speed developers. What are you in Biome doing to solve that developer interoperability difficulty?

• 43:30Speaker 02

  Well, I mean, as we mentioned, like Biome has a plugin system to try to bridge the gap. It's a plugin system based on this DSL called GreatQL. So it was chosen some time ago as a winner after a lot of discussion. So we are aware that we can do everything. And there are some requirements that are project specific. So things like that belong to your org or to your employer, to your codebase. So that's where we think a plugin is actually very useful.

• 44:14Speaker 02

  Because also like your sensitivity, things like that. So we have your this powerful DSL that Biome is able to interpret and it has its own runtime. So with these plugins, users are able to inspect the code. And just to let you know, so until now, these plugins were not able to provide code fixes. So until now, it was just, that's the rule, that's the diagnostic, that's the error and that's it. So we have now a PR that is able to actually provide a code fix. So probably in the next minor, user will be able to create. An intro that is able to auto-fix possible issues in their codebase.

• 44:57Speaker 02

  So this actually kills my point where the plugins are bad. But I think in this case are actually valid because a tool cannot know everything and it shouldn't. Like I shouldn't know about the quirks of your codebase because they are sensitive data. And that's where a plugin makes sense. You leverage the tool, uh, biome is lint, O X E, whatever. And you apply to your codebase specifically to your needs because they belong to your project.

• 45:30Speaker 01

  So it sounds like you could use code fixes from lint rules as a sort of code mod tool.

• 45:36Speaker 02

  Yes, yes, exactly.

• 45:38Speaker 01

  Love to hear that. That's really cool, though. So there's already a biome search command. And just looking through the biome js.dev/referenced/greatql page. It looks like you can do some pretty powerful matches with not that much syntax with great Q L. Have you seen a lot of developers pick this up and use it?

• 45:55Speaker 02

  So I'm not into a lot of this part of the tooling. I know that there are users that have like a 70 or more biome plugins written in great Q L. So I feel like there are users that actually leveraging the plugin system a lot. But yeah, like great Q L was born as a code mod. That's why it's so powerful. And that's why it has a lot of weird syntax. Because one of the initial objectives was to create code mods. And essentially, that's what biome could potentially do in the future.

• 46:34Speaker 02

  You could create your code mod to, I don't know, you have your reactor from 18, 19. There's a lot of changes. You have your code mod or even internally. So you're changing stuff. There's a lot of refactor, create your plugin that does the code mod, run biome, and there it is.

• 46:54Speaker 01

  Beautiful. Let's talk about the future a little bit. What are some of the big flashy upcoming features in Round Bion that you're excited about?

• 47:02Speaker 02

  Ah, that's nice. Okay, so there's a lot of going on, a lot of ideas. So one is this lint rule that I talked about that is able to catch unused classes. It's still early stages because there's a lot of components and ecosystem is big quirks. The second thing that we're working on is the watcher. So you can run biome lint dash dash watch. And then you can start typing and biome at every change. It links the new file that you just changed and it checks if there are some violations or not. And I think it's also will work for the formater, but I mean, it's still in the early stages.

• 47:45Speaker 02

  And the reason why we're able to do that is because biome has already a watcher under the hood. So we are just exposing the watcher using the CLI. One other thing that we're doing, this is just third-party contribution, so I'm not doing that much. So plugins that will be able to emit code fixes. And they will be able also to set the severity. So until now, user, they couldn't do much. So now we are making plugins more powerful and customizable to our users. We are working towards markdown support. So internally, we reached 100% coverage against common markup.

• 48:30Speaker 02

  This is also done by another third-party contributor, so that's amazing. I'm just essentially reviewing PRs and contributing with them. So it does an effort at the moment, doing a refactor of the parser while keeping the conformance to common markup to 100%. And we are setting up the formater at the moment. So if everything goes well, it's going to be part of the next minor. Yeah, I think that, I mean, there's also, we're doing a lot of lint rules for our view. And also Svelte, probably we're gonna start creating some lint rules now that we have a very good handle on this Svelte syntax. So now we can start shipping some lint rules for them.

• 49:11Speaker 02

  For Astro, I still need to investigate. I know there's a VS lint plugin for Astro, but I'm not familiar with the rules. So probably there's a room for implementing something there as well.

• 49:25Speaker 01

  It would be nice if the leader of the Astro project and the leader of the Biome project knew many of the same people together.

• 49:31Speaker 02

  Ah, yes. Which is me.

• 49:36Speaker 01

  Well, great. One of the interesting notes you brought up was editor support. Can you tell our users, what is LSP and what does that mean in this context?

• 49:46Speaker 02

  Sure. So LSP stands for Language Server Protocol. As the acronym says, it's a protocol to essentially create an editor server that works in all editor clients. Nowadays, the vast majority of editor clients support this protocol. So like BS Code, Z, WebStorm, and all the IntelliJ, sorry, JetBrains IDs, Vim, Alix. So all of them now support LSP. And this is actually quite powerful because we just need to develop the server in one place. And DDX is the same in essentially all the editors.

• 50:31Speaker 02

  So one of the BIOS' mission is to focus LSP as well, so to provide only one experience, which means that we implement the business logic in one place. And then you get the same look and feel on the CLI, the LSP in the playground. So any client, because Biome is essentially a server, you have multiple clients. And that's what we do for Robert and Nostic. So what you see in the CLI is the same thing that you see in your editor. Something that we could potentially do in biome that other tools can do is to leverage the model graph

• 51:10Speaker 02

  to implement things like the go to, you have your function, you wanna know where it's defined. So you do command click and it takes you to the definition. So that's something that biome potentially could do. So there's endless possibilities with biome because everything is central. We own the stack, we own the information, but still it requires essentially the time. So I'm setting up essentially the whole infrastructure. I have a lot of ideas, I just need the time to implement them. Now with these AI agents, I get to do things quickly because like they just write the code and then review it.

• 51:53Speaker 02

  So, yep, I'll wait to answer your question.

• 51:57Speaker 01

  That does. Before we start to wrap up, are there any other big ticket features or fixes from biome that you're excited about coming years?

• 52:04Speaker 02

  No, like I really wanna do a shout out to the actual community because like a lot of fixes, a lot of new features have been developed by other people that aren't the core team. So biome is essentially a community effort. We are just essentially the orchestrators and the manager. But we are seeing a lot of people sending fixes, sending features. As I said, the markdown parser has been done by another person, the formater as well. We are actually also working on CSS support, SASS support. So yeah, I mean, I wanna do a shout out to all the contributors

• 52:46Speaker 02

  because like a lot of things that you're using and other people are using have been shipped and created by the community essentially.

• 52:56Speaker 01

  Let's talk about the community then. Biome's been around for a few years now. It's outlasted Rome. It's clearly sustained itself. How have you been able to build a community where so many open source projects are?

• 53:07Speaker 02

  Well, I feel like Biome as a concept attracted a lot of people, as I was. So that's just one of the reasons. Second, I don't know. I have some experience in open source. I'm involved in other communities. So I learn from the other communities and I apply it to the Biome's community. I try to be friendly every time. It's not easy. That's actually very difficult as a maintainer to keep your cool. And I know that sometimes I wasn't able to. And also, like, you have to be active. Like, we have our Discord chat. And if you're able to answer questions as quickly as possible,

• 53:51Speaker 02

  people eventually acknowledge that and they like it. Because sometimes you are in a project, you file an issue or you ask a question, and then it's basically, you don't get an answer for weeks. So I feel like that's why I try to focus on quick feedback, if I'm able to. And I think like this is paying off because users seeing that activity, they see that their problems are solved, their questions are answered. Or maybe we don't have the answer, but at least there is some discussion, you know? So there's something moves every single time.

• 54:30Speaker 01

  There's something to be said about positivity. You join the Biome Discord, and there are all these fun channels. There are lots of emojis, exciting announcements. It feels like a very big project and a fun place to be.

• 54:41Speaker 02

  Yeah, we try. We try to be active, to be positive, as you said. To communicate, that's also something that since day one, I wanted to do. If there's something about Biome, anything related, just share it. Or even if it's not about Biome, share it, you know? It's, you have a link that you like, just drop it and people like it. Because it's something nice to read. And so that's essentially the mentality. You are there, you want to share something, do it. You are more than welcome to do so.

• 55:14Speaker 01

  Lovely. Let's say that I'm a listener with a large codebase, complex formatting, linting, and so on. How would I get started trying to switch things over or to evaluate to Biome?

• 55:25Speaker 02

  So Biome has a couple of commands that allows you to read the config from ESLint and prettier and create a biome config that matches as much as they can what you had before. Of course, we don't have all the ESLint rules, but at least something. Second, you can actually do a first pass of your Linter by suppressing all the violations, because you might have a lot of violations in your whole code, in the big codebase. So you do biomlint -- suppress -- suppress reason and say migration or whatever,

• 56:07Speaker 02

  and you're good to go. Maybe you can also turn off the formatting if you want, but we match 97% of prettier's formatting, so you should be good to go. At least the linting is there. It doesn't scream at you, and you can keep your codebase there, and then you can progressively address lint rules as you go. That's essentially what you could do for your migration. If you have a lot of formatting problems, one technique that I usually suggest is to have a PR, make sure the CI is green, merge it, and then goes with another PR

• 56:46Speaker 02

  that ignores the commit of formatting. So like your history is not mangled by the formatting. We do the same also in the Biome repository. So when we have these trivial changes that don't bring anything to the table, you ignore that commit, that hash, so that your history is the blame, you know, when you do a blame of the file, it doesn't show any meaningless information.

• 57:12Speaker 01

  That's a great tip. You're talking about Git revision ignoring?

• 57:16Speaker 02

  Yes, exactly. There's a Git file where you essentially can list all the commits that you want to ignore, and those commits won't appear in the history of your Git blame.

• 57:28Speaker 01

  Great. Let's say that I have a new project and I want to get started fresh with Biome. How is that different?

• 57:33Speaker 02

  So you start Biome and you're good to go.

• 57:37Speaker 02

  You could run Biome in it, which bootstrap a Biome config for you, which essentially mirrors our defaults. So it might be lengthy, but at least you can see what are our defaults. You don't need to go to the website. You can understand what's the default and then you can change it like tabs versus spaces, lint rules and so on. Other than that, we ship also a really nice tool called Biome Explain from the CLI, where you can just type Biome Explain no debugger and it shows you the docs right in the CLI.

• 58:19Speaker 02

  So if you don't have any connection and you know the name of the internet connection and you don't want to go to the website, you just type that command and you can see what the lint rule does for you.

• 58:32Speaker 01

  Speaking of which, that website is BiomeJS.dev, yes?

• 58:36Speaker 02

  Yes.

• 58:36Speaker 01

  Great. Are there any other resources or links you'd want to send people to if they wanted to learn more about Biome?

• 58:41Speaker 02

  I think the website is quite several explanatory, also the main GitHub repo. It's also a nice resource. And yeah, we try to be central, so we try to have everything in one place and the website is where everything goes. And our Discord, so BiomeJS.dev/chat and you should be good to go.

• 59:02Speaker 01

  Excellent. I like to end interviews with one non-work question. You mentioned at the very beginning that you were interested in video games. What games are you playing these days?

• 59:11Speaker 02

  So at the moment, I'm playing Assassin's Creed Shadows. I'm not a big fan of the whole saga, but I liked the last video games there because they're really focused on role playing. So you have your character, you choose your skill that you want to develop, your weapons, skills and things like that. So it's also in Japan, which I really like, so it's a really nice mix of things. I really like role playing, so GDR and things like that, RPG. Essentially, I'm not into like sports or shooting. I really like RPGs, yeah.

• 59:48Speaker 01

  Fun. Are there any lessons you've learned in programming that apply to the stories of these video games or vice versa?

• 59:57Speaker 02

  If you want to learn how to do a video game, you have to do it yourself. Just do it yourself, like a lot of people do. Indie video games, that's how I think you should start. I mean, I tried the university, it didn't pan out. So do it yourself if you have the passion and the time. I don't have the time anymore, so that's the only problem. But if you have the time and the passion to do it yourself, I mean, with the tools that we have nowadays, I think it's quite easy to pick up.

• 1:00:29Speaker 01

  All you need is time, interest, and energy?

• 1:00:32Speaker 02

  Yes.

• 1:00:33Speaker 01

  Well, great. Emma, this has been wonderful. Thank you for walking us through your history and bio and all the fun things around analyzing and linting that come with it. If people wanted to learn more about you specifically, where do you direct them to go on the internet?

• 1:00:45Speaker 02

  Well, they can go to my Blue Sky account, matipical.xyz, and the GitHub account. And yeah, I mean, that's essentially where you can find me and where I'm active. I'm not a real social person. I like to lurk and I engage less.

• 1:01:06Speaker 01

  Excellent. Well, thank you for all the info for Software Engineering Daily. This has been Emma and Josh Goldberg. Cheers, everyone.

• 1:01:12Speaker 02

  Thanks.