Biome JS with Emanuele Stoppa

Welcome to Syntax. Today, we have a show for you on Biome. We have Emma Stapa on, who's the creator and maintainer of Biome, and we're gonna talk all about it. And if you want to see all of the errors in your application,

you'll want to check out Sanity at century.ioforward/ syntax. You can sign up today and get 2 months for free. Sentry is just a really incredible tool for not only tracking your performance, making sure your application has no bugs, but even just seeing what goes wrong when something goes wrong because things go wrong all the time when we're coding. And you don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on to reduce century.ioforward/ syntax. Again, we've been using this tool for a long time, and it totally rules. Alright.

Wes.

Biome is a one stop shop tool chain format ESLint, maybe even more at some point for your TypeScript, JavaScript, JSX, maybe HTML, projects at some point. It's built in Rust. It aims to create, like, a wicked fast alternative to tools like Prettier ESLint while having, like, a simple configuration. Node tool kinda do it all, actionable error message, all kinds of really neat stuff. So pretty excited about this. We're gonna talk to Emma today. He's the project lead, and, talk about where Biome came from. It was Rome at one point. Now it's Biome JS well as, like, what the the endgame is on it. So welcome. Thanks so much for coming on. Thank you for having me. Yeah. Yeah. This is this is exciting. We talked about we had a whole show on, like like, next gen JavaScript tooling.

We we talked about the Scott of all the things in this space, and and Biome was is one of the ones that we spent quite a bit of time on. So pretty excited about it. Do you want to give us a quick rundown of of who you are and what Biome is?

Sure. Sure. I watched that episode.

It was really interesting. That's good. Yeah. Yeah. I got I was curious to know what you talk about.

So, yeah, so I'm Emanuele.

EMA, short version. I'm from Italy. I live in Ireland.

I'm very passionate about open source. I've been contributing to Open Source for a long time.

I started with webpack, so a long time ago.

And then Webpack CLI, then, Rome, now, Biom and Astro. So, I'm everywhere.

What's Bos? Well, Biom, as you, maybe mentioned, it's essentially a tool chain, of the web that, wants to provide a new developer experience, around the formatting, linting, error messaging.

All in one experience, so CLI and editors.

So it's quite, it Wes to provide a lot of stuff. And in the future, we might provide also other tooling, like Type Warp, ESLint rules, compiling support from other languages. So, it takes a lot of, of the old, philosophy from Node.

So we carried over, most of the philosophy.

And, yeah, let's see how it goes.

Yeah. I think that's a a good introduction to you know, I think one of the first questions we really wanted to ask you was because we had talked about Rome on this show for little while Wes once it was announced. It was sort of announced as being, like, the the tool chain for JavaScript, and it never never came to fruition.

Can you talk a little bit about what happened to Node and how it now became Biome and what what went on there?

Yeah. So when Rome was announced, it was essentially an open source project as others. It was written in TypeScript.

It welcomed a lot of contributors.

Among those, it was me.

After a few months, the creator, Sebastian McKenzie, man managed to raise some funding and, there was a company around it. And that was part of the 1st employees.

After a few months, we decided to rewrite everything in Rust. So it was, quite a lot of work, essentially through a way a lot of things that we already had. So it's a full rewrite. It's a massive overtaking job. And eventually, we managed to launch after a year and a half, more or less, a formatter that was almost pretty compatible and the foundation of the linter.

After this, year and a half, we essentially, we were let go because the company finished all the money.

So I don't know where the money went other than paying the employees and some other expenses.

So I don't have the insights because as an employee, I don't have access to this kind of information.

Yeah. But yeah. So, no more money. We were all let go. And so there was a lot of speculation.

So I I I read I read a lot of articles. I saw a lot of videos.

Yeah. They're it's kind of wild. And, like, what I was most, like, impressed by was that, like, yeah, we didn't hear much from Rome for a couple of years. And then I saw a biome's gonna it got gonna be forked. And I thought, like, yeah. Like, that's cool, but, like, are we gonna see anything? And then, like, I don't know. Maybe maybe 3, 6 months later, I'm I'm installing it in a project and and using it. And there's there's still quite a ways to go. I'm sure you're very busy, but, I was impressed to to see that that Scott had had popped up. So was it you? Like, you said, okay. I'm gonna I'm gonna fork this thing. And then, like, now who's paying who's paying you to work on this thing?

No one.

I mean, it's it's pure open source.

Like, after we were let go, like, I was so passionate about the project, that, like, I continued working as a a, as a maintainer, as a, in my Node free time, spare time. So in the, in the meantime, I was, seeking a new job, a new position.

Eventually I landed Astro, but in the meantime, I was still working on Rome. There were already, some, people that were helping me. So it wasn't just me. Firstly, there were other people that we were able to attract, even though the community was really small.

And these few volunteers eventually became, the core team of Bio.

We we followed the project mainly because, it was unsustainable.

I didn't have all the permissions, because most of the permissions belong to to Sebastian. And as a I wasn't, I wasn't part of the company anymore. I couldn't do anything.

So I said like, maybe it's the good thing that we, we fork it. So, we leave our baggage behind, new project, a new team, new philosophy.

Yeah. Yeah. Probably too with a lot of the learnings. Right? You probably learned quite a bit, and then now you get to start essentially fresh with those those learnings. How how many people are are working on on Biome now?

So now the core team is around 6, 7 people.

I thought I'd remember the numbers, but you also have a lot of maintainers.

Cool. So we have a kind of, a ladder, where maintainers are essentially people that regularly contribute.

But then we have the core members, which are essentially the pioneers of the project. So they essentially lead, the project. They shape the roadmap.

And so I try to delegate to, to, to, to everyone, each core team member JS, has the same, rights as me. So even though I'm the lead, I'm just a face behind me. There's a there's a lot of people.

Awesome. But let's talk about, like, what does Biome actually do? I mentioned that it's sort of a replacement for a formatter, which is like like a prettier and a linter, which big one obviously is is ESLint.

I know that the original Rome had grander visions in terms of, like, also it being a test runner and Vercel other things. Is that what you're focusing on right now being a formatter and a linter?

We Yarn focusing on that.

On the side, we also, working on plug ins, for example Okay. And other, supporting new languages.

And, transformers, transformations. So, like, compiling TypeScript to to JavaScript. So that's what we want to focus.

Oh, wow. So it could be a, like, a Babel replacement or a TypeScript to JavaScript alternative?

Yes. Yes.

Awesome. And we should say, like, one of the Sebastian is was the creator of Babel. Right? So, like, obviously, he knew a lot about that space as well.

So what's wrong? What's wrong? Like, most people are probably listening to me and, like, I use Prettier. I use ESLint. And, yeah, it's a bit of a pain in the ass to get set up. But once it works, isn't it isn't it fine? Do we need more tools?

So, like, I would like to bring a different vision from the current setup.

The current setup, it's just 1.

You don't have, alternatives, that actually are good and production ready.

So that's what Viomi JS. So it wants to be, production ready. And that's why our formatter is like a pretty compatible. It has like a 97% compatibility, in terms of formatting for JavaScript and TypeScript files.

So you essentially use Prettier. There are a few exceptions Wes documented in our website, but they are really edge cases. So, I wouldn't worry too much. And if you see a different that is not an exception, it's just a bug. So you Node the bug and we aim to to reply to fix it.

And, like, yeah, you set up Prettier, you set up easily. It takes you like a 3, 4 hours, 6 hours, half a day.

You know, that's, I mean, you don't want to spend 6 hours, especially if you Yarn, an employer and spending just 6 hours to, set up a few tools. Yeah, it works at some point, but there are some projects where doing linting type checking takes, I don't know, 3 minutes, 5 minutes, 10 minutes.

I believe in some cases, this is not acceptable, especially because we pay CI times.

So you want to reduce the time as much as you can.

The build is important. So why LinkedIn must be so, damn frustrating? Also for matting. So

And to be clear, when you're talking about speed there, you're talking about, like, not set up at the speed at which the tools run.

And do you do you have any insight as to why why those tools are are currently slow and and how Biom does it faster?

Yeah. So for Prettier, for example, I think what it, it doesn't have is parallelism.

So it's not able to execute operations in parallel. Mhmm. So multithreading and stuff like that. I think, like, the modern JavaScript allows you to with Scott to use web workers. So try to use multiple CPUs.

Although I don't think Prettier right now, it does that.

So it's one thing that Biom does. It spawns essentially threads like there's no tomorrow and each each thread formats a file. And at the end, we just group all the the nothing and we we tell you what's wrong and what's not.

Then, well, I think also ESLint also doesn't have multithreading.

And one another thing I think is the issue with TypeScript.

Node Wes you use TypeScript ESLint, you also have to go back and forth to communicate with the, the TypeScript APIs or the TS Vercel. And that, that, that takes a lot of time and resources.

Oh, because TypeScript ESLint is using TSC to to do what? To get to get type type errors or to convert from TypeScript to JavaScript so it can be then, run through ESLint?

So as far as I know, what JS, the the plug in does is to actually retrieve type information of a certain part of the code that needs to to clean. So it needs to understand what's the type of this symbol, what's the type of this interface.

And based on this metadata, JS able to provide you, with a proper, linking and the message.

Oh, yeah. Especially, like, we had folks from JSR on, and they are implementing this whole, like, no slow types thing because there are certain parts of TypeScript that can make your code base extremely slow because you cannot parallelize them. Right? Like, you have to do one thing, then another, then another, and that will really get you if you need that type of thing.

Yeah. Exactly.

One other thing I think Bos is good at is caching.

Like, we do a lot of, aggressive internal caching. Mhmm. So when we parse a file and in case we reparse it due to linting or, formatting, When we reparse it, tokens that were already parsed are essentially reused. So we don't do the same work twice.

Okay.

Awesome. And the reason ESLint interesting. Like, the reason why it's fast JS you're explaining all of these things, but how much of that is also because you've you've written it in rust? Like, what was why why was there a decision to write it in rust initially Wes you're back at Rome? You're like, you know what? Maybe we should do this in Rust.

Yeah. So Rome back in the day was a Node single package without dependencies.

The only dependency was just TypeScript for type checking.

Mhmm. This JS, I wouldn't recommend this kind of project to anyone. Like dependencies are bread and butter of us developers. Like, why have to reinvent the wheel if there is a battle tested package that does that for me? Thing is because of JavaScript, that how dynamic it is sometimes, like breaking changes happen and you are not guaranteed the things to work. So Sebastian, when created Rome, wanted to have something that works all the time. Everything is owned and that's it.

It wasn't sustainable.

So with Rust, what Wes get, so we get a mature language.

So we can say that Rust is matured enough to, to be used in different kind of environments.

Strictly typed.

So when you get a dependency update, the types tell you Wes something breaks or not. So, and the language allows you for backwards compatibility. So they Yarn really good at implementing new features without breaking existing code.

And the ecosystem also is quite good. So there are tons of, really good crates used also by Deno. So if they use that and Deno is quite successful and fast. So another confirmation that Rust and the ecosystem is good.

Yeah. I'm just amazed after talking to people that run extremely large code bases.

You think about airlines, Shopify, you know, Facebook, these these types of things where speed really, really means a lot. Like like, type checking for me or, like, if I'm running a linter on my course platform and it adds, I don't know, a 10 second check to my CI. And I've I do that maybe 3 times a day with a pull request.

I add an extra 30 seconds of of compute. Whereas, like, you look at some of these code bases and I'm curious if you know of any stories or stats like this JS it's hours and hours of compute time when it's added altogether. You know? It could take 10 minutes to lint an entire project. Like, you make one little change, we gotta lint the entire code base to make sure that didn't cause an issue somewhere else in the code base. We had to type check the whole thing.

And now all of a sudden, our CI bill is ballooning because we have 5,000 developers. They're all putting ESLint 22 PRs a day. You know, that's 10,000 CI runs and they're running a couple of minutes each. And before you know it, it's 100 of 1,000 of dollars in compute every single day. So, Arnold, do you have any stories of of companies like that where they're spending tons of money or tons of time?

A story? No. But I know for a fact that, few months ago, Yagiz, probably, you know, JS one of the, Node. Js tier core maintainer.

He actually, introduced Biome at Sentry, as part of reducing times throughout the code Bos ESLint terms of bundling, linting, formatting, And actually saved a lot of time, by using Biom's Formatter and Biom's ESLint, maybe together with ESLint because Mhmm. Biom. Sanity provide all the features that some, plugins from ESLint are able to do.

And, yeah, I mean, he told me that he saved a lot of time in Sentry as part of this internal mission that he had.

And I mean, I'm quite happy, that Sentry was able to to use it JS one of the early adopters, by the way. Like, I think it's one of the first projects, that tried to to to use it. I'm quite satisfied by the the the results.

It's crazy. So I'll I'll tell you one story. We're allowed to say this because, Milan CEO of Sanity tweeted it out. So you guys made one change in their code base. This is not Biome, but it's it's the similar idea. He made a one line change in some loop to check for caching, and it saves Sentry $100,000 a year in compute. You Node? One line.

The wild wild to me that those types of things can add up, so much and just end up being a big bill at the end of the day. Yeah. Compute time. No joke if you're paying by the minute for it. Yeah.

Yeah.

So and it's very basic. How like, let's say you're hearing this. You say, I wanna give Biome a try. Yeah. What do you do to get going with Biome? Like, what does the setup process look like and how do you use it? So Viome works Scott of the box without any configuration file. So you can just do MPX

name of the package.

So biome. Jsbiomformat, and it just works.

So, doesn't need any setup, like we mentioned, at the beginning, you know, SetItUp, Prettier and ESLint all together. With Viome, like, if you wanna try it, you just do it.

You have the same, with the Versus Node extension. Like, we provide a way to to download the the actual binary from GitHub with so you don't need any installation. So if you don't if you don't have it but you still want to try it, we download the binary for you, and it just works.

Biom has really good defaults.

So we have defaults for the formatter and defaults for our ESLint rules.

And if you're happy, that's good. If you're not, you can create a configuration file and Pion will pick it up for you. So you still don't need installation.

Like, we don't need Node to, to run it. Like we, we, we have a really light dependency on Node. If you, if you install it from an Npm, We just have like a script that checks the the architecture and, of your machine and we run the the binary for you.

That's I I'll tell you. I I installed it in a couple projects. Every time I I start a new project, I think, what should I use? What should I use in this one? And, yeah, it it it just works. You know? And then I found myself, like, as I was coding, instead of, like, taking all of my, like, ESLint rules or whatever over, I started just like, alright. Just give me what you got. Yeah. Yeah. And then allow me to I just I just like, that's annoying to me. I don't like the way it formats that. That that linting error is not something I care about. Then I'll just go into the biome Scott JSON file and and add it in. And I think there's also the Node. Is this true? The code had like had a way to add the rule to to the JSON file? Maybe I'm imagining that.

I think I think I am imagining it given your I don't mind what you're talking about, Wes. Yeah. So, like, let let's say I have a a linting error in in my project that Bioms telling me about, you know, like, no no shadow variables. You know? And I'm like, I understand that, but I want to turn that off for this one.

I Oh, yeah. Imagine this. Like, I would love to be able to just click it and it would open up my biome JSON and have it configured for me that I can just put the the thing in. Oh, that Node is actually a good suggestion. No. We don't have it, it would be nice. You

can suppress the ruling ESLint. So you know, when you have your bugs quick fix, you can, we suggest you a suppression comment.

But we don't have this feature to go back to the JSON file and,

adding that. But it's good suggestion. That's good. Yeah. Thanks. Sweet. Wes, that's what I'm here for. I am curious about so biome is going towards full, prettier, compatibility.

Will you give us more options than Prettier gives us? That's always the thing people have with Prettier JS that there's not a lot of knobs to turn on Prettier. You kind of just it's opinionated on on purpose.

Yeah. We took over the we took actually the that same philosophy.

So we wanna try to keep, options as lame as possible to avoid too much bug shedding, you know, and mistakes like, pre tier acknowledge, acknowledges that has done some mistakes with the options.

So we, we also acknowledge that. So we want to carry the same, mistakes and yeah, that's it.

So we try to to restate. Doesn't mean that we won't add them. It's just, you know, we have to justify them. We have to be really good to justify these kind of options.

Yeah. Yeah. That makes sense.

And I think one of the big things for for me is that the, the reason why I haven't picked it up in all of my work yet is just because of language support.

So the language support table which we'll post is is really impressive because it seems like you guys are flying on this, language support. Every time I check it, it's a little bit different here.

But right Node, it has full support for parsing, formatting, linting in JavaScript, TypeScript, JSX, TSX, JSON, and JSONC.

So we also have partial support for Vue, Svelte, and Astro. Now since my work is mainly in Svelte, the Svelte support is only through the JavaScript aspects of Svelte or the the script aspects of Svelte.

So do you do you foresee those types of things for, like, views, Svelte, and Astra being resolved once HTML and CSS full support has been added?

Yeah. Yeah. So HTML support is on the way. Like, we're actively working on it when I have time. Yeah. Yeah. So from time to time, I create some PR with some, parsing.

Of course, this is not actually HTML, but each language has their own dialect, Astro, the has a different dialect compared to Vue or Svelte. So there are some implications that you have, we have to design, in biome.

So it's going to take more time than expected. We want to try to, to be as generic as possible, but in a really strictly typed language JS Rust, it requires, more time than, JavaScript, for example. So Yeah.

So so do you have to, like, write a whole language parser for every one of these languages? Because we had Nicholas Zakas on the show explaining how ESLint works. And, basically, they they take the file, they explode it into this nested object of what's called an AST, abstract syntax tree, and it it gives you all of the pieces of the syntax and tells you, like, oh, this is a curly bracket. This is a variable.

And then you can write rules against those specific things. So if you're writing it all in rust, you're not able to, like, lean on a lot of the the stuff that's available in JavaScript land, are you?

Yeah. Exactly. There's, at the moment, we have this constraint where we have our own or kind of a AST. So it's all really already Yarn coded. So we are not able to we might be able to use parser from another Rust crate, but we still need to map it to our own syntax.

Our syntax is quite weird. We have a it's really strictly typed and we essentially generate all everything, from a syntax document and we have a job that parses it and creates. There's a lot of code because JS a strictly typed language, you must have everything ahead of time.

So when you parse everything, you have all these slots where you essentially like a puzzle with a hole. So you basically place all the SD nodes in the right place.

That's how the parser works more or less.

That's good. And I wanna ask about, like like, plugins as well or or you I think you mentioned it earlier.

Like, one of the huge benefits to the whole ESLint ecosystem is that, like, any developer out there can go and write an ESLint plug in because it's just in JavaScript.

I don't think that's the case for Rust developers. So is if somebody wants to create a biome plug in or if that's going to be a thing at some point, is that going to be an issue? Are we gonna have to write them in Rust?

So we are exploring this. We don't think Rust is gonna be the way.

So we are exploring DSL. Actually, we are we are implementing a DSL system to, create ESLint rules and eventually using JavaScript together with the runtime to, create Lint rules.

Rust, yeah, it could be Node to have, but we think that, small rules or rules that are really domain specific to your company or to your project, makes sense in that domain. But if there's a rule that required, like, it's more generic and its benefits, the whole ecosystem, it should be ported into core and retaining Rust. That's the kind of philosophy that we want to have. So one of our core maintainers is actually working on the DSL. So we chose this DSL called gridQL.

It's quite recent.

It's based on 3 seater. We already have a parser, for the grid grid ql, files. And later news, like, the Scott maintainer that is working on that managed to actually extract the end the generic engine of the grid QL system.

He mentioned on Discord that is actually a great stepping stone towards, having this DSL, working on bio because we want to use our own engine. So we want to parse these files. We want to do all the bindings using our own AST, our own implementation, semantic model, and everything.

And once we have all the runtime, we might be able to to actually have this plugin. So a person can write a GreekQL file. We also have we're gonna have also Firmata for that. So that's how good Viome, infrastructure is.

And we're just trying. So we're going to pick up these files. We're gonna have our own our own runtime, and we're gonna export our diagnostics base on this road.

This is really cool. So I'm I'm just reading the docs for it right now, and it seems like it is very popular in the code mod space right now, which if you have a very large code base, you need to make some API changes or you need to be able to upgrade lots and lots of files, find or replace isn't gonna isn't gonna kick it. Right? You need a little bit something that's a little bit smarter about how your code works and how things are imported and and all the different syntax. So that's just cool. You could write GRITQL queries to do code mods.

So you can seen this. Do the same similar. No. I have not seen this either. Wow.

Yeah. It seems really powerful. It has a lot of great features, and potentially other new features. Also like, I think they maybe they plan to do something with the control flow because we have a a control flow feature in Viom. So imagine also binding it with a group ESLint would be would be nice. Wow. Yeah. We gotta ask about

Esno. So we talked about Esno as well, which is the very ambitious project to create a new TypeScript type checker.

In in the world right now of JavaScript tools, there are many not many, but there's a handful of tools that will take the types off of your JavaScript and give you JavaScript out the other end. And there's many tools that will convert your JSX into into just JavaScript.

But there are no tools except for the base TypeScript Node that will actually do type checking.

And Deno is one of 2 sort of projects that are trying to do this. What's the story there? You had included it initially, but it's no longer part of Biome.

So for this year, so Broadmunk 2024, warp to be quite honest and say like, we won't be able to do type checking because we like, we aren't Microsoft. Scott

Yeah. That's huge.

So what we want to do is a different approach. So be able to, like, infer types or, like, types from a JavaScript language and be able to provide more, ESLint rules based on difference of the types. So we essentially leverage TypeScript, although we won't be able probably to do the actual engine.

So like computing,

these really complex types that sometimes you see on GitHub Bos on the web, probably it's going to be quite difficult.

So it's going to be limited, but I think it's going to be a good experiment for us Mhmm. To eventually try to do something more.

Beautiful. And do you think that we will ever see another TypeScript type checker? Because I think the reason why we we don't see it is there's no spec for TypeScript.

It's a can of worms. I'm sure it's edge cases all the way down, and I can't imagine I can't imagine working on some of Wes TypeScript code bases that are for libraries, let alone the tool that actually does the type checking itself. Do you think we'll ever see that, or do you think we're gonna see, like, some, like, somebody's gonna make a new typed language that, is kind of similar to TypeScript?

Yeah. I think the 2nd option is the the more feasible Node, like, like TypeScript has some goals. So they tell you what's TypeScript for and it's an unsound type checker language.

And so that's their mission and they're quite good at it.

But, you know, they have a lot of money. So they have a lot of people that are able to actually they have also like a lot of smart people, like, the inventor of essentially .net and C Sharp. So, quite, quite, quite good.

So I don't think we will see anytime soon, a competitor of TypeScript, unless like we have a new, flow or something, different, other than TypeScript with a different mission, like, different expectations that essentially digest.

Yeah. I I often think about that. I'm like like, I understand. Yeah. We have Flow. And there's actually been quite a few things that have been popping up recently being like, Flow has some nice features that I I kinda would want, you Node, or you want the ability to, like wouldn't it be nice to be able to type an error? You know? And there's a bunch of stuff in JSX that would be would be nice to be able to have easier in TypeScript. So I often wonder, like, are we going to see the biome of TypeScript? You Node, someone's get especially once we get the types the new types proposal hit. Yeah. Are we gonna see somebody who takes that and says, alright. This is a new language, very much like TypeScript. Given these restrictions, things are gonna be a bit faster or a lot faster.

I I hope so. In that same regard, what are your thoughts on the on the types proposal?

I I looked at it. It's it's nice, but it's quite basic. Like, I think like the proposal JS just few basic examples.

So I, I don't know. I am half and half. It seems good, but I'm not sure if it has, like a good value, in a runtime as JavaScript.

Yeah. They say that these comments would be parsed as like, trivia comments, like something that we don't need it, but they still need to be parsed in order to categorize JS trivia. So there's a lot of, going on also like to consider engines like a V eight or a spider monkey, we left to essentially be the parser and be able to parse them. So I think it's more like, an effort way for having a kind of a spec for the TypeScript because what TypeScript lacks is the spec. Yeah. Yeah. That's one of the of the issues. Like, when we were writing the TypeScript parser, there were a lot of gotchas and weird things that we were not able to to understand because it there's no spec specs. So Wes.

Formal way to have a spec in the language so people can go there and read it.

And then TypeScript just adds some flavors and some logic that is meant for their goals of what they're doing. But then another compiler like Biom or Deno comes into play, they do their own flavoring of type. So there's a lot of good in here. If this pack is played quite well, the proposal goes, as it should be.

Yeah. And that that's, like, I'm on the same page as Wes, and that's why I'm not, like, chomping at the bit. Like, I think the this is gonna take years for us to figure out because this is our one time to to really get it right. And if we rush it out, just trying to make it look like TypeScript, like, maybe we should be asking ourselves, should it should it look any different? You know? Right. Yeah. It doesn't need to look like TypeScript.

Node. Exactly.

So kinda interesting stuff. Another question I have is you're one of these guys who you go to their GitHub, and it's just a a wall of green. You know? And it's just like and he Wes like, how I'm just like, like, how does somebody do this? I don't even know what my question is to you, but, like, what does your day look like if you're it's everything is you're just writing code all day long every day if it's all green like that?

No. That is misleading. Because for GitHub, also commenting something, it's a contribution.

So I don't Node all days. So Okay.

Actually, my weekend, it's essentially playing video games, doing things with my wife, doing small trips, watching TV series. So I try to have a working free and coding free time. But sometime I go to my smartphone, I check GitHub and I reply to an issue.

So. Oh, there you go. Actually, you're one of the few people if you I look at your GitHub and GitHub will split it up between review, commits, issues, and pull Wes.

And you have a higher code review than you actually do commits, which JS, like, hats off to you. Like, that's not easy going through somebody else's code and try to make understanding it, making sure everything is good.

Yeah. This is something that also my manager at Castro, praise me made praise about like, I'm able to jump on others colleagues' reviews and leave comments, even though I don't have the full picture of the features they're implementing.

What Node do, I just like to to have common sense and look at the code if it's doing if it's correct, you Node, just

and maybe sometimes just nitpicks. You know? So that's what you're doing. You're looking at the code and just glancing at it for patterns and nitpicks?

Sometimes. Yeah. So I try to to be helpful. I ask Wes.

If there are some places where the code is weird or is doing something that it shouldn't do, like, are there exceptions.

And I say, like, maybe we should document it. You know? This is something, it seems to be an anti pattern, so we Yarn doing exception for this case. Let's document it. Or I don't understand this part because it wasn't part of the TypeScript. So I asked the developer, can you expand on this, or can you document it? Is it part of the PR? So sometimes I try to to be proactive in a sense like, better patterns or less document code. I understand more or less the feature you, developer, have to help me to review it. So, like, make a good TypeScript.

Tell me what are your changes. Tell me how you're testing the feature.

And thanks to that, I will be able to give you better feedback, not just, you know, nitpicks or comments.

Yeah.

That's really interesting.

What what do you do at Astro? Are you writing Rust over there as well, or or are you slinging JavaScript like the rest of us?

Like the rest of of everyone here that is listening, TypeScript and JavaScript.

Yes. Yeah. Sometime in Go, sometime I write some Go.

The Astro compilers you're written in Go. So sometime, I do stuff in Go.

Not that often, but yeah, I mean, I also implement a few features and, and fix a few bugs in the Aster Compiler. So.

What other languages do you know? Seems like you're a pretty Vercel programmer.

Well, not that many like Rust, Vitefflow, TypeScript and JavaScript.

But back in the day, it was also like PHP and Groovy, which is a dialect of Java.

Node, yeah. Yeah, Man, that's and how did you learn Rust and Go? You just kinda picked it up, read the docs?

Yeah.

The Rust, I learned it at Node. So they give us the time and the resources to to learn Wes, essentially read the book, do exercises, and then just wing it. So write code, really bad code, but at least it's Node. And with the time, you improve.

And Go, yeah, I just tried to pick it up. The thing JS, Go is very simple language. So very simple syntax, few features Sanity doesn't add very complex things like, traits or object oriented programming.

It's just very simple, so it's really easy to pick up.

Is that why all the Go people are always mad at my JavaScript tweets? Because it's so much more complex.

Cool. Well, that's, that's pretty amazing. You know, I'm I'm Node that Biome is a little bit more supportive than last time I looked at it, I'm gonna definitely give it a whirl right now.

Is there anything that we didn't cover that you wanted to hit before we move off of the Biome topic?

Yeah. A couple of things about Biome, quite niche. So it has a built in support with VCS, so GitHub.

So like, you can run it natively, like, in prehook context using ASCII or, left hook or any, any tool that you use for these kinds of things. So you can pass the proper options in the CLI. And essentially it handles formats and links only the files that you actually change it.

And you can do the same also in CI. So if you, in CI, you can run the command with dash dash change it and a different remote.

It does that on a CI. So it doesn't format or check all the files. It's check it checks only the files that were changed. So it saves you a lot of time. Nice. That's cool.

And how does it know? Is it just using git under the hood? Like it does does it run some crazy git command to find only the changed files?

Yeah. Yeah. So you, you have to, enable it to opt in via configuration, and then it runs via like response a command, pnpm, any transit Git with the proper options.

And then we just do some parsing of the output coming from git.

Yeah. And then we just give all these files to Biom and Biom just parsed it and and Okay. And

does it, like, let's say a file change, but that file has, like, an import. Does it follow the import tree to make sure there there's no issues down the thing, or JS it just just the file that's changed?

Just the file that's changed.

Bos doesn't have a project aware, awareness yet. So Wes, we working towards this kind of, thanks.

And another thing that I forgot to say about performance ACI. So we have a CI action, a GitHub action that just set up Viom.

The good thing of this is that it doesn't, you don't need, like you don't need Node and any, package manager in order to run it. What the action does is scans your manifest, package. Json.

It checks if you have, Bos, It installs the binary from source and then runs the actual binary. So it will pick up the configuration, everything that you have.

So you don't need to install Node. Js. You don't need to install Pnpm with, the caching.

So it's gonna save you meaningful, seconds and minutes. That's a good thing. Like, being able to to not be dependent, from any runtime is actually Yeah. It can pay off.

Yeah. And now I understand. Like, one of the sponsors or I guess yeah. Node of the sponsors of this project is Netlify.

And you know why Netlify probably cares about this JS they spend a ton of money on Sure. CI. Like, that's that's a big part of their product is is the build step.

And part of that is bringing in the most recent version of Node. Js in order to run a bunch of the the tooling. So you you better bet they'd be interested in minimizing that amount, because then they can pass on that stuff to their their their users as well. I'm guessing that's is that true? I often say these things as if I know the internals of the company, but I imagine that's probably why they wanna support the project.

I hope so. Yeah. Yeah.

I hope so.

Good.

Alright. Let's move into the next section, which is supper club questions. You're curious what text editor theme and font you're using?

Oh, is it for me the question?

Yes.

Yeah. Well,

So, I just know that I use the GitHub, Dim with that colors and that's I'm not like the what Wes that font on Twitter? Oh, yeah. Oh, what was that font? You

know? Or was that I am not that guy. And you're on Versus Node? Or, I saw Biome was working on some ESLint integration as well.

Actually, my day to day job is using Web Store and the Rust Rover front. Yes.

I I prefer this kind of IDEs, since like, I started working as a web developer.

What I really like is the diff. So, you know, when you're doing some merging conflict or rebase conflict, their merging tool, automatic merging tool JS so amazing that it's, it has become part of my workflow. So without it, I can't even merge conflict resolve conflicts anymore.

Yeah.

I I really have been enjoying a lot of the UI things there. What about, what do you do to stay up to date on topics?

Well, I'm subscribed to a lot of newsletters, like, JavaScript Weekly, Node Weekly, Frontend Focus.

So a lot of, mailing lists, also Acre Acre newsletter.

Mhmm. That's that's essentially how I stay up to date and also, Twitter, for, you know, the drama and stuff.

Yeah.

Awesome.

Alright. Let's move into

sick picks and shameless plugs. Do you have a sick pick for us? What I'm currently watching now, for example, on net on Netflix is Ripley. It's an exclusive TV series that came out, like, few weeks ago and it's really good. It's all in black and white.

I don't remember the name of the actor, but he's a British actor. He played, Moriarty in Sherlock, a few years ago.

I love this actor.

And, like, it's also, like, the the whole series is is in Italy. So he actually speaks Italian and JS really good at it.

And so the mix of a spoken Italian and spoken English and, I mean, it's really good. And the story is amazing and the actor is fabulous.

Wow. Cool. That's awesome. What what part of Italy are you from?

Originally from the center of Italy. It's close to Rome. But then my family moved, and now

they live in the north of Italy next to Okay. Milan. So it wasn't it wasn't your idea to call it Rome initially? Oh,

I'm headed to, Venice and, Florence this this summer, so it'll be my first time in in Italy. I'm I'm pretty stoked. Yeah. We went last summer.

Awesome.

Love it. Yeah. Amazing cities. Yeah.

Yeah.

Last thing we have here is shameless plugs. As many things as you would like to plug to our audience.

Something that would like to to suggest. Well, I'm I'm a bit biased, but Czechastro.

Nice. It's a really great framework, really great DX, so check it out.

And, of course, Biome, Biome because as a news has been nominated JS a productivity booster in for the OS Warp 2024.

Oh, cool.

I'm biased, but I mean, it seems the community is acknowledging the efforts.

So thank you everyone.

Yeah, that's it. I mean, I don't think I have a specific other tool, to to suggest.

No. That's awesome. Awesome. Well, thanks so much for coming on. Really appreciate all of your time and all of your insights. I'm glad we could could sneak you in on one of these episodes. I'm really excited about Biome. So thanks for all your work on it, and thanks for coming on. Thanks.

Thank you very much for having me. You're welcome. Peace.

Bye.