Modern JS Toolchains (Biome, Oxc + More)

Welcome to Sanity. Today, we're going to talk about modern JavaScript toolchain. So there's been a lot of movement in this sort of area lately, a whole bunch of new tools around ESLint, compilers, transpilers, formatters, tokenizers, bundlers, macros, all kinds of stuff. Crazy. And it's it's kind of interesting because you think like a part of you is like, I do. We do. We really need all these tools Like, do we need new versions of them? But then once you hit one of the issues or sometimes you have like, oh, yeah, I've got 14 tools all working perfectly together, and I got my Versus Node set up with them. And if something breaks, I will cry. I think these new tools are solving both speed as well as for developer experience. So we're going to they're going to talk today about what are these different areas of tooling like? What are we what are we working with right now and what do the new ones look like? There's a couple that are very promising and there's a couple that are just like, I don't know, pie in the sky, people playing with ideas that I think are pretty, pretty nifty as well. So how are you doing today, Scott? Hey. Doing good.

My son is home with pink eye, so that's great.

We're just, like, you know, hoping that the pink eye does not spread.

Oh, yeah. So that's, you know, that's how it is. But, Node, all things could be Wes. You know, there's, I think there's worse kid sicknesses than pink eye maybe. Right? Like, there's no vomit involved.

There you go. Yeah. Node fever JS involved. I think I think we're doing okay. So, yeah, I'm doing alright over here. Yeah. Not a whole Scott. Node. Not a whole lot to complain about.

And specifically, I don't have that much to complain about because I'm learning all kinds of new stuff on the Syntax YouTube channel. That's right. We're on YouTube folks. Youtube.comforward/atsyntaxfm.

Check it out. Subscribe.

We have a lot of content going up there. In fact, CJ has been doing a lot of great videos, really getting deep into some of the topics that we've been covering on this show, like has, or he's, he's going into to Docker or self hosting or all kinds of cool stuff. So check it out at Syntax on YouTube.

So tooling, you know what? Like you mentioned, like, do we really need tooling? And that's like a big topic of conversation, especially on, like, tech Twitter Wes people are always like, my tools are making my life miserable.

You don't need tooling. I mean, they're they're all fine. But, like, sometimes, you know, it's like the way I think about tooling in the in the JavaScript ecosystem is like, alright. We're cutting wood. Right? Is that is a hand saw gonna do just fine? Sure. A hand saw will do the job, but might not do as good of a job. The end result might be a little bit sloppier.

It's going to take more effort.

And, you know, sometimes it's it's worth it to go out and have a little bit of pain of researching which circular saw you want and, finding out the correct one, and then just Node clean-cut. So to me, I I think the tooling is worth investing your time into.

And like you also said about there being new tools. Right? Wes, you never know exactly the pain points of your tools until you try the new thing, and the new thing is a 100 times faster. I remember in the meteor days, I was like, meteor's build process is fast enough. Why would anybody complain about this? And then I tried something else and it was way faster.

And then I tried Vite eventually Yarn down the road. Then I'm like, I can't even take 1 step backwards from Vite. Everything is so much faster and nicer with Vite.

I'm never going back to WebKit. I'm never going back to Webpack.

Yeah. Oh, Webpack. Yes. I'm never going to back to WebKit either. Never going back to Wes Webpack and doing any of that stuff. So, yeah, the the tools, you don't need need them, but they can make your life a little bit easier every step of the way even if they do add an incremental amount of pain as you go.

Yeah. I and I also think that, yeah, the new tools are a little bit trickier to get set up, but I honestly think that by the time that the masses adopt them, they become dead simple. Like, you think about, like, Vite. Like, you don't set up Vite. You see, you just run Vite, and it's a HTML file and the whole thing. Right. Like, there's no config. Yeah. You can get into and config some stuff, but it's largely config less. You're not really installing a whole lot of stuff.

The 2 and 4 stuff is there's there's no config file. It just it just works. And I I think that that's what a lot of these tools are sort of gunning for as well is that it just it just works. It's really simple, and it it makes the developer experience really, really easy. Because if you think back to, what, like, 8 6, 8 years ago, we were writing Grunt files or webpack configs that were, like, hundreds and hundreds of lines long for every single project. And now I look at some of my my projects, and it's just, I don't know, like a like a NPM config, you know? And Yeah. That's not true for absolutely everything, but it's it's certainly getting that way, especially as we sort of standardize on on a lot of these features or standard features, e s m, CSS.

And and I I used the that's the whole thing for me. As a guest, I I started out with what Grunt and Gulp and all those. You're writing configs. And then I got to go to Meteor where there was no config whatsoever.

Even to install packages, you just added a string to a file and Meteor's build tool was like, oh, there's a change in this file. Let me go get that package for you. Yeah. So when I saw people using Webpack and you have these like, I don't know, a massive config file that's, you know, 10 feet long and all these devices. Like, this is loaders for absolutely every file type.

This is the wrong direction, folks. I I like, I did not understand that at all. So, thankfully, I got to avoid most of that. But, you know, most folks did come from config, config, config, and things have gotten easier. But not only things getting easier config wise, they're also getting way faster.

And so what kind of stuff can tooling do for us? You mentioned all these different words. Right? But I think that the core way of thinking about the tooling here, JS they make your code smaller, they make your code look nicer, they make it run better, they make it easier to work in. That's really what this tooling is doing for us. And those all sound like positives to me at the end of the day. And like you said, there might be some pain here and there getting this stuff up and running, but the pain is worth it if the end result is that your process is that much nicer.

Totally.

Yeah. Big, big fan of of all kinds of JS tooling. And I'll I'm the type of guy who I'll find the latest tooling and just toss it in there. Alright. It's not ready yet. I'll come back later. You know? Totally.

And we'll we'll let you know when they're when they're ready. Yeah. You could think of syntax JS like the

timer on your microwave. You're cooking a pizza and your hands aren't ready yet. Well, we'll let you know. We'll all say, beep, beep, beep. Alright. Now it's time to figure out which, which of these tools to use. So let's talk about some of the existing tools that exist in our workflows today.

One big one that a lot of people have been using for a long time is ESLint. Linters let you know Wes there's potential mistakes, or potentially issues within your code, or even just, like quality issues, or potentially, accessibility issues, or potentially, formatting issues in some sort of ways. And linters are they've they've undergone some changes. We had like JSHint and JSLint and all this stuff. But it really feels like for the past 10 years or so, everybody's been really kind of settled on ESLint as being the linter of choice for so long. And only now are we starting to see competitors to ESLint pop up. Everybody's been pretty stoked on it for a while. Yeah. Yeah. ESLint is the reason why ESLint is is so popular is because it works with works with TypeScript. It works with JavaScript. It works with different,

like, babble Node, and there is a massive community of rules and plug ins that have been written specifically for JavaScript. So you can run you can run HTML that has script tags and run it through it, and it just works with everything.

There's been some pain around the configs, and there's a new ESLint config that has come out, and it it works beautifully.

You can also just use your old config with it. We had Nicholas Zakas on the podcast to sort of talk about that as well.

So big fan of linters. They catch a lot of the possible things, and I honestly say that linters have made me such a better coder because when you turn it on, you get all kinds of red squiggles absolutely everywhere, but you don't necessarily know why. It's frustrating. But if you look it up, there's a squiggle under it. You say, why is that potentially a bad thing? I I made a variable here, and it's saying that it is shadowing a variable that's up higher, or I'm using a variable inside of a React hook, and I didn't pass it in. Why is that a potential issue? Like, what could possibly happen? And linters are often stopping you from shooting yourself in the foot, And I found I've learned so many really interesting things about how to structure your JavaScript well.

And lots of times, I just go turn the roll off because I'm like, I understand how JavaScript works. I don't think that's gonna be an issue, or I'm gonna be writing a whole Bos of bunch of extra code just to make the squiggle go away.

And when that happens, it's like and now I'm just writing code just for the red squiggles and not for my actual end users or for my own developer experience. But you learn so much stuff if you just dive into the all these specific rules and, see why somebody is saying that this could potentially be an issue.

Yeah. And I I see more and more people occasionally being, like, maybe we shouldn't be using all these different linting, you know, frameworks and libraries because they're a pain in the butt. But let's not throw the baby out with the bathwater because I think there is, like you said, a lot of really positive things to be gleaned from that. And it's not like you can't turn the rules off that you don't want to follow.

It's pretty easy to do that inside of the config. So, you know, you don't have you don't have to be beholden to the red squiggles.

You are the master of the squiggles. They are not yeah.

If anything, I say go aggressive on your linter at first and then sort of back it off from there. And that's that's how I've gotten to my own ESLint config JS that I just went I went really aggressive out of the gate. And then over the years I've hitting been hitting things that I turn them off or I make them a little bit more lax. And like Node example is, if you have a callback with an error variable and it's like, you cannot have like, I like to have the signature where it's like the data and the error. Even if you don't use the error, it'll be, like, unused. So I can say, alright. Well, allow don't allow unused variables, but allow the unused variable if it is of the following names. And that's really nice for Amigie because, like, I don't care if I have a variable that's unused. If it's an error, sometimes I need it. And I don't wanna have to change the function signature simply if I need it or not.

Word. Yeah. Compilers is the next Node. A compiler, and maybe we'll we'll say compilers and transpilers.

A compiler will take your JavaScript code and turn it into JavaScript code.

And, generally, what you're looking at is you you take your TypeScript. You'll take Babel, which is maybe some code that doesn't necessarily have the features just yet in the browser that you're targeting or in the JavaScript runtime that you're targeting, and it will turn it into JavaScript that simply works.

Transpilers work the same way, and people use them interchangeably.

What's the difference between a compiler and a transpiler? I don't know. Do you have we've I think we've tried to answer this a couple times on the podcast. Do you have any fresh ideas on how to explain the difference between the 2?

No. And, frankly, I don't care.

So I don't. Yeah. It's not a big deal to me. Yeah. But, you know, I I think it is it's one of those things that it's used so interchangeably at this point. They they might as well just be the same thing. Yeah. I I think

I think that in languages that are not runtime interpreted, you a compiler would take your author language and make it into a runable executable.

JavaScript needs to be run at runtime, so Wes don't really have that unless, I guess, Deno has a little bit of that, and and Node. Js will kind of allow you to do that. But they're essentially the the same thing. The only, like, one thing that I'll say is that the idea of macros, which is the compiler can modify your code in such a way that how you author it and how it actually runs, it will like, for example, Svelte is a compiler.

Right? You cannot run SvelteKit or Svelte code directly in the browser.

It needs to be turned into something that can be run. And we're going to cover this thing called macros in just a second, and that is something that, in my mind, a compiler would do Wes it literally modifies how your code runs.

Word.

Formatters.

Formatters are basically the thing that makes your code look nice. And in a large part, you know, format based languages like Python or something like that, where the format is very explicit, formatting has always been very important, but JavaScript developers have always been kinda like, yeah, you know, It's the way I author it. Until Prettier came along, and Prettier is like, you know what? Here's the standard way we're gonna format. And, yeah, you can you can tweak it these following ways, but, hey, install Prettier, and I'm just going to snap your code into place.

Personally, hey, I, I love a format.

I format on save.

I like my code to be formatted. One thing that formatting does for me is it ensures that I have not missed something like missing a bracket. That's a common error that can be solved with a formatter. There's so many of these little things that are micro bugs that especially new developers hit when they're working like, Hey, why doesn't my code work? Well, so many of that can be solved with linters and formatters because they'll show you essentially if your code is snapped into place correctly, then you know that everything is as it should be.

Yeah. And it will also take a lot of the, like, nitpicking of, like, this is the way we Node. You know, this is, you must put an indentation here or, like, you hire some psycho that puts the function curly bracket on the next line. Like, all of those things are gone when you have a formatter because you simply just run the formatter, and it puts your code in the way that everybody has agreed to do it via the settings. And Prettier itself doesn't really have a whole lot of settings.

There's some things I wish it had settings for, but it's intentionally opinionated about it. And I think that's been a massive massive net positive to to the code community in JavaScript in general.

I also run it on save. There are people who only run Prettier once they're Deno, and I find that to be wild because you're when I have to, like, indent code manually like, sometimes you're running a project and it's not working or you're in a project that doesn't have it. You have to manually indent it, and it's just that's so frustrating to me now that I've been I'm just so used to having the pile of garbage that I wrote, and then you hit save and beautifully indented and all new lines and everything.

Can you imagine being concerned

with typing code with the correct indentations today? I like that is not something that I want to do. About that. Yeah. Yeah. I don't have to do that ever. Prettier is the big one. There are there are other formatters out there, JS Beautifier, whatnot. There's a couple of new ones, which we're gonna talk about in just a sec, but Prettier is the big, big one. Tokenizers and parsers, these are things that take your code and split them up so that the formatters and linters and transpilers can work.

It's actually kind of interesting that a tokenizer and a JavaScript parser is how all of these different tools work. Acorn is the really big one out there, and then the tokenizers are built with Acorn. We're not gonna spend a whole lot of top time on that, so we'll move on to bundlers.

A bundler generally will do more than Node thing. It's just a a generic tool that you use. They'll often have a dev server involved. They'll often do your transpiling and compiling. They'll do your building. They'll do your tree shaking. They'll often integrate your linters and formatters if you would like them to do that as well.

And there are several large ones out there. Webpack is a really big one. That's what Next. Js is built on.

Vite is probably everybody's darling right now. It just works beautifully.

Parcel is another really popular one and, like, modern one. I see a feet and parcel are probably, like, the 2 big, like, modern ones.

And then roll up is is what Veed actually uses under the hood. So if you have something that Veed cannot do, and this is something I've had to to dip into a few times, you generally have to you can still use Vee, but you have to dip into some of the roll up settings to get what it is that you're looking for. But the idea of most of us are doing the same thing, which is building full stack JavaScript applications, almost always the the defaults are gonna work for you just fine.

Word.

Last thing we have here is this idea of macros.

And Babel Macros were have been a thing for a while. I saw a parcel rolled out support for Macros just a couple weeks ago, and this is really cool. And this is kind of where I think, like, the the difference between a compiler and a transpiler is. So a macro will prerun JavaScript code that can be prerun.

So let's say, for example, you have, a function that adds 2 numbers together, and the output of that is needed.

It's it's only needed once. Right? And you don't need to rerun that function absolutely every single time. So what a macro will do is it will run that at build time and simply just store the output of that function in a variable. So instead of saying, like, const total equals add 1 plus 1, you you author it that way, but it will run that at build time and say Scott total equals 2, And then it just takes out all of that generation. And I I do that as well on on my course platform is I do a whole bunch of looping over my different course packages, and I set up the, the team packages. And I say, alright. Well, team package for 10 Scott this much, and it has this many seats, and a team package for 15 Scott this much and has this many seats. And that is a function that runs and generates maybe, I don't know, probably a 100 different combinations.

However, that doesn't need to be rerun every single time that I need it. It could be done at at generation time. So I could run that as a macro, and it would simply just kick out an object of all the different packages rather than having to to regenerate that. And that's how you can sort of speed up a lot of this cold start or unnecessary running via a specific macro. So that's kind of a a cool feature as well, and I'm gonna start looking at different ways that I can use that in my code bases.

Yeah. I largely haven't picked up macros for any particular reason, but thank you for explaining it like that because that was one of those ones. I see the word macro and it always like, I get macros in gaming. I get macros in Rust. But in JavaScript world, I'm always like, I got no idea where this fits into my life. So, thank you for that. Let's talk about the new tools because that's obviously what this episode is supposed to be about. Now that we've explained all of the different tools that we're using and the types of tools. We're gonna be diving into some of these newer tools that you can have on your radar. Some of these are ready to go. You can drop them in with caveats.

Others are very, like you said, pie in the sky.

So let's let's get started with the first one. I think one that a lot of people have been hearing about for a little bit is Biome.

And Biome does a few things. It's a formatter ESLint, and it's very fast.

It it tends to be oh, they it says 35 times faster, and they even have one of those little movie charts on their site, so you know that it's fast.

That's a word of warning. Sometimes when we say that, it's a little bit sarcastic because oftentimes these performance benchmarks are are here to make their product look good. Yeah. They cherry pick a specific situation.

They cherry pick a specific situation. So don't always rely on these things. That said, I think for all intents and purposes, Biome is very fast and much faster than any of the linting tools that we have today. Node, Biome is very, very usable.

That said, there is some big caveats here.

And the reason why I'm not using Biome personally right now is that it does not work in your entire application. One of the cool things about Prettier and ESLint is as, as a tag team, it's going to format my Svelte files. It's going to format my CSS. It's going to format all of my stuff, not just my JavaScript code, not just my React code. Yeah. I looked it up earlier because I think we should maybe explain what Biome does is it is

everything. It's a ESLint. So it does, like, CSS lint. It's a it's a formatter, so it kinda takes the job of prettier.

It does. I'm pretty sure it does macros as well.

Oh, really? And yeah. And you basically just install the I use biome in my last project, just to kinda get a feel for it. And you install the Biome extension, and you you turn it on for that specific project, and it works pretty good. I've I've never had issues with Prettier being slow, so it's not something that I I necessarily care too much about. But you're like you said, it doesn't work yet with everything. They're trying to get what's called an HTML parser, and I think they're trying to work on CSS parser as well. And then once you have a JavaScript parser, a CSS parser, and HTML parser, then you can start to open the floodgates for building all of the, like oh, alright. SvelteKit is is based on HTML. So, alright, we can now build the SvelteKit, extension for it. And I think once those sort of primitives are in place, we'll start seeing a whole lot of different ones for it. What I do like about it is that it's just it's one thing that just works for absolutely everything, and I'm a big fan of that.

Yeah. I I like all of that. I would like to replace all the different piecemeal things with 1 thing that just does all the thing, the everything tooling.

I posted in the show notes an image, although Wes can just pile a link to this.

And if you're watching a video, maybe Randy can throw it up on video. But it really what what it is here is this table of what's being supported right now and what's on the way. Right now, they're working on in progress HTML parsing.

They haven't started working on formatting or linting, but it's clearly on the table.

Vue, Svelte, and Astra are all partially supported.

CSS has, parsing, but not formatting and not linting, nothing for markdown. So it's it it isn't the thing that's going to replace everything for you right now, which is why I'm not using it today.

Because, yeah, straight up, if if if I have to have Prettier installed it anyways in my project, you know, next thing you know, I have, I have Prettier IVS ESLint and Biome, and that that's, like, a little too much for me. So that's why I trying to get your Versus Node to, like, use the proper

formatter for the different files, and you're it's such a pain in the butt to to try to get Versus Code to set it up exactly right, especially if you have often what people will do is they'll set up globals on their entire Versus Code. Right? You'll say, alright. I am using ESLint and Prettier as a global for every single project. However, if I do want to switch that, then you have to, like, turn it off project by project and turn these ones on project by project, and it it it starts to get to be a bit of a pain in the butt. So I'm I'm pretty stoked about Biome, though. I'm it's amazing. So Biome was Rome, and we Rome was we've talked about that many times on the show about the the past of that, but it's amazing to to see all everything coming out. Oh, looks like they just rolled out support for partial support for Astros felt in view 2 yeah. You did days ago.

Partially supported with some caveats. Yeah. Oh, yeah. Yeah. So this table JS up to date, but, yeah, it's better than the the red x that was here, like, a month ago. So, yeah, I I'm hopeful for Biome. And you you said you're not gonna you Node, Prettier JS never the thing that's slow in your process, but there is something that Prettier is doing by being slower. And it's taking up more processing, more battery.

It's slowing your computer down whether you know it or not. So if you can have a more efficient tool, heck, your computer might just last a little bit longer. You know, I don't I don't know if you you get this, Wes, but, like, anytime I'm losing a rapid amount of battery, I feel like it's always Versus Node. And who knows what it is in Versus Code? It could be the the formatters. It could be any sort of language library. It could be literally anything. There's ways to to find that out, and I did find one of my plug ins was one of those things. But if you Sanity the way, for those of you listening, that plug in was import cost. If you're using the import cost plug in, go maybe disable that thing because it it is a big batteries, battery suck. It is a performance suck, and it's yeah. I don't know what's going on there, but it's not good. So disable that plug in, and you might get some extra life out of your editor. Act actually, that's a a really good

point that that was taking a big suck of resources for you. And one of the things that a lot of these tools do is they they do the module tree. Because if if something imports something, imports something, imports something, right, it goes all the way down, you could have, like, 50 imports all the way down, and that is takes a lot of computation.

So these new tools that are often written in low level languages like Rust will be able to parse that tree much quicker than in JavaScript, And that's probably a really good use case for one of these tools JS you could rewrite the import cost, extension using I'm not sure which one of these, but one of them will will use it.

Yeah. The Totally. One other thing about, like, the downside to using these Rust things and we talked to Nicholas Zakas about this as well because we said, are you going to write rewrite ESLint in Rust? And he says, we've been looking at rewriting parts of it in Rust. However, we will never rewrite the entire thing in Rust because the benefit of the ESLint system is that literally anyone in the community can write a plug in and allow us to use it, whereas not anyone can write a Rust plug in. And I don't even think Biome has the idea the concept of plug ins yet, so it's really important to still have a a JavaScript API where people can go in and write plugins.

So that, like, like, where where does the JavaScript end and start is a tricky thing.

Totally. Alright. Next 1 on the list here is 0xc.

This is the JavaScript oxidation compiler, which is again a collection of tools. This would be kind of seen as a direct competitor to Biome. It is written in Rust.

It's very fast. Again, it's a parser, a linter.

It's a resolver. I don't know what resolver means. That's what I was just talking about. The resolver is how it figures out the dependency tree in resolving all of your modules. Gotcha.

They even say it's going to be a formatter. It's going to be a transform minifier.

It is an RS pack bundler, and it is going to be a roll down bundler.

This one is interesting, but it's it's been on my radar for some time. Because, obviously, it is trying to solve some of these same problems, and it is trying to, do so in a very, very fast way, which Scott love that. That said, they've explicitly stated that HTML is not on their road map, and it's not in their plans. They had no planning on adding that type of thing.

So for me, personally, I'm interested in it. But if I'm looking at replacing my setup with something that can't do everything, then, yeah, I, you know, I I don't know how I feel about that. So for me, that there's definitely, like, something to keep in mind with this project.

Regardless, though, the performance, everything, if you're looking for something that is fast, this is a project to keep your eye on, for sure.

Here's some some way to, like, position why do these things really need to be that much faster, especially, like, I don't work on stuff that is so large that I'm hitting these types of things. But this is Jason Miller, from Preact. He works at Shopify. Also lives in the same city as me. Also a good person to listen to on Performance Anything.

Yes.

So he says, Oxlent has been a massive win for us at Shopify. Our previous linting setup took 75 minutes to run, so we were fanning it out across 40 workers in CI.

So you sent a pull request in Shopify to I I changed this Node thing in our in our dashboard that has to run. Like, one of the steps of the pull request is you Scott lint the entire code Bos, make sure you didn't do something that is going to throw a linting error. So they had to run 40 machines at once via 75 minutes. So probably 40 machines running for 2 minutes each in order to simply just lint your code Bos. Whereas, like like, that's that's wild. And and the other thing is, like, sometimes you're running a linter on just or or a format or just on the current file.

Wouldn't it be nicer to run it on save? TypeScript has this setting as well in v s code, but it can be kinda slow running on your entire code base. And when you get into the size of applications that are something like Shopify, it's insane to think that it could take

over an hour to simply just Tolinski your code base. And Talking about fanning out, you'd have to fan me out because I'd faint if my code base took that long to, to link. Holy cow.

So it's it's wild. And even just to think about the cost savings of you're not paying for an hour's worth of compute Compute. Yeah. Every single time someone sends a pull request. Yeah. Yeah. An hour.

Like, how much does GitHub actions cost per hour? Let's look it up.

It's not it's not super cheap when you when you do a whole lot with it. And if you're using a lot of GitHub actions, can certainly, save you a lot of only a lot of time, but a lot of money for sure. Alright. GitHub

pro gives you 3,000 minutes a month, so that's 50 hours.

And, like, I I bet Shopify JS 50 50 pull requests a day, at least.

Yeah. I don't I have I have no idea. I'm just talking out of my butt. But I've exceeded mine just on, like, running tests and stuff. So Yeah. Again, speed is always Wes you're trying to get your GitHub actions. I have a theory that the GitHub actions are so hard to get working because they want you to burn up their your minutes.

That's great.

That's the whole GitHub. It's just Mhmm. It's all a front for them to burn up your CI minutes, and so you buy more.

Mhmm. Yeah. You they could simply make them easier, but that would bankrupt them.

Yeah. Next one is the Deno Formatter.

Node I haven't done, anything with Deno format.

Do you know a little bit about Deno Formatter?

Yeah. It's just, like, another nice formatter, and I'm actually kind of bummed that it it didn't catch on like it did. It's been around for a while. Deno has its own linter in its own format or kind of the the same idea.

The benefit of that is that being baked into the language that they can write it in rust because that's what Deno JS written in. And then you can just simply expose it via the the language server, and via the Deno extension. So it's kinda interesting, and I'm I'm curious or I'm kinda bummed that it didn't, like, catch on for absolutely everything.

But, like, maybe maybe part of the, like, the long run of JSR, You know? Or if we're all starting to use JSR, maybe we'll also start using one of their formatters.

Yeah. Maybe it just baked into the JSR platform. You know, I think that's a cool thing about Deno JS they are taking lessons from Rust in that regard where, you know, Rust has so many of these things baked into the platform itself. Deno seems to be taking that same approach.

ES build is also a a new tool that we've been talking about here. This is a bundler.

It will take your code. It's written in Go, and it will very, very, very quickly bundle your code for you. It will transpile or compile your code, do all that sort of stuff.

This is what Vite uses to be so fast. Vite is very fast because of a couple things. ECMAScript modules and ES build are are 2 of the main reasons.

But move over, ES build, but there is a new fast bundler in town, roll down. Have you seen a roll down, Les?

No. What's Okay. What's this built on? Is this because there's SWC and ES Bill. Those are, like, the 2 big ones. What's roll down? Well, roll down is the new,

the new hot ticket in town, and it is it is going to be it's going to replace Wes build in Vite. It is written by the Vite folks. It is written by Vite, and it's written in Rust.

And it's supposed to be compatible with Rollup.

So, basically, what they said JS, we like Rollup.

Let's just make a Rollup compatible Rust based bundler and have it be our own. So that way Wes have full control of the direction of this thing. And it is very, very, very enticing. It is, recently announced, and I'm excited to see where this goes because to me, this this seems like it's going to be the future. And it's probably not even going to be the future that you need to even think about if you're using Veeet because it's probably at some point just gonna be Vite. You know? They'll just swap it. Yeah. Like, the these some of these things are so low level that you don't really have to care

because you're just hitting NPM Scott, and whatever the robots need to do to make that, it will do. So it says the the parser and resolver so those are the 2 things we just talked about in roll down is o x c. So these tools are are multiple multiple levels deep. Right? Because roll down is written in Rust, and their Rust parser and Rust Wes m resolver are just taken directly from 0xc.

You know, the Vee folks seem to do a really good job with that where like, that's what made VeeT so great in the 1st place. It's like, oh, what if we took this really fast ES build, and then we put, like, a dev server on top of it? We made it be ESM, everything forward, and that's, you know, what makes it so fast. And that's really cool. Okay. I didn't see that. Yeah. It says that currently Vite relies on 2 bundlers, ES build and roll up, and this kind of takes that 2 bundler problem out of it. So, interesting stuff.

So one thing we haven't talked about here is TypeScript.

And a lot of these tools will do TypeScript to JavaScript via stripping types. Right? They they will compile or transpile your TypeScript, and they'll simply just find the types and take them out. And then but, you have

JavaScript. Whoever Unless, there's Wait wait a second, Wes. Why would I ever wanna do that? Isn't TypeScript there to save me?

Yes. Well, it it your TypeScript will not run, in any JavaScript environment ever.

Wherever TypeScript is running, it's being stripped of its type and being run as actual JavaScript.

However, there is a a second part of of TypeScript, which is type checking.

Actually, making sure that your code passes all of the the types checks and is type safe.

So simply by running Vite with TypeScript, it's not actually checking that your your your types are are type safe. Right? It just takes them out.

The only way right now to actually type check your JavaScript is with nodes t s c or Scott node. It's written in node.

It's but it's written by the TypeScript project, and that can be a little bit slow on very large projects. So there have been multiple efforts over the years that have been sort of, like, abandoned.

I don't know necessarily know abandon because the the efforts were just like, let's see if we can write a type checker.

And TypeScript itself doesn't have a pnpm, so there's not anything to write against, which is part of the trouble.

And There's a lot. It's it's extremely complicated.

Project. Yeah. Yeah. Trying to to do it. So there's there's been one that I've been sort of watching. It's called Deno, and, it's a TypeScript type checker, and it's really cool. So it's very, very early, but the the errors that it gives you, it's all based on static analysis, meaning that it goes through your entire code base. There's parts of TypeScript that you cannot use because it cannot be statically analyzed, and the errors that it gives you are much better than the TypeScript it can be a little bit frustrating that the the error messages in TypeScript are not better.

And the few examples that I did with Esno is the errors were much better, and the formatting was really Node. And Wow. It's really cool. It doesn't work with, like, 90% of TypeScript.

So, like, you Sanity just run this on an existing TypeScript project. You cannot even run it on some simple examples. Like, I just wrote, like, oh, just make an interface and a custom type and extend it and burnt. Node doesn't work. Right? It didn't support even that the very fundamentals there. But in the very simple examples that I had done, the errors were actually really, really good. So and I looked up the the author of this. It's like a very young developer who's just like, yeah. I'll try to build my own TypeScript type checker called Deno, and, it was part of OXC.

They took it out Oh. Since then because it's like it's it's nowhere near being ready for anyone to really use, but it's a glimmer of hope.

Wow.

Wow. That's really quick. Wow.

Yeah. I think, man, all this stuff give me hyped. I didn't know too much about that. You know, there there's also beyond just, like, even bundlers or tools. There's, like, a bunch of, like, interesting projects that are taking a bigger view in terms of how you're doing your projects. It's bundling a bunch of stuff together, making your dev process easier. And, like, we're talking about things like Vite specifically. Right? Vite is a whole dev server.

It it handles a lot of stuff. But then you have projects like SvelteKit that handle the whole request and response cycle for you. And one that has been kind of taking a little bit of, little bit of the the juice lately is this whole Pnpm JS project.

And Un JS seems to do a massive amount of stuff. When I first saw this, I was like, well, I have not been paying attention to this. This does a whole lot of things.

It it handles a ton of stuff for you, whether that is, like, your your dev server you're building or whatever. It even handles, like, WebSocket support and stuff. I mean, the the thing's pretty amazing. It's actually what powers Nuxt.

So if you've heard of Nuxt JS, which is the Vue version of Next JS, this is the thing that powers that, but you don't have to use Vue JS for it. So, this is a a newer dev tool that allows you to do a whole lot of interesting stuff for building building sites and, again, from the folks over, you know, the Vue JS folks. So it JS, it's pretty cool project.

Another one I'll say is lightning CSS. We've talked about this a few times on the show. This is from Devin Govett, who's creator of Parcel, creator of all the React ARIA, pretty much everything.

Wes should get him on the show at some point.

So lightning CSS is his CSS parser, transformer, bundler, and minifier. So it it replaces something like a CSS Node or Wes build for your CSS, and it's only for CSS. It's tail 14 is going to be using it in there as part of their tool chain as well. And I'm pretty excited about this one as well. I think it's gonna again, I don't know if you'll have to use lightning directly, but a lot of your tooling will probably pick this up in the future.

Alright. That's all of the new and upcoming I think all of the tools we talked about are written in Rust. Rust or Go. Yeah. Which is wild. Oh, yeah. Wes build is written in Go. Right?

ES build is written in Go. Yeah. But, you know, it's trend of not writing things in JavaScript. And, you know, sure enough, there is the conversation of, like, is JavaScript, you know, good enough to handle these tools? And I think, you know, there is pretty clear evidence that tools can be better written in other languages. So, you know, I'm not I'm not the the right person to say that you can't write super fast tools in JavaScript. But, it is an interesting trend, and certainly one that we're we're seeing a little bit more and more these days. And I honestly don't mind because at the end of the day, I just install the thing anyways. If there's a config file, I'll configure it there.

Not It's not like you need to know for us. Yeah.

Yes. Yeah. Totally.

Cool. Alright. Let's get into some sick pics. Do you have a sick pic for me today?

I do. It's a YouTube not only just a YouTube channel, but a YouTube video specifically.

And this one's for my movie heads out there.

Man, this video was really super good. So this is it's an hour long. So it's a type of video you're gonna wanna you're gonna wanna pull up some popcorn for. But it's called Shinobi Gedan, the 19 eighties ninja craze, and this guy really breaks down, like, film by film, the 19 eighties ninja craze from, these I mean, massively films you've never heard of. But things where they were, like, splicing together, like a certain director was splicing together films from a bunch of different films and then adding new scenes that they were recording.

They talk a lot about, like, the mustachioed American actors that appear in these films and stuff. They they talk about, just in general, the the ebbs and flows of the 19 eighties. They talk about, like, Sanity films and stuff. So this thing was really deep dive. And and the type of YouTube video that I really prefer where it's like, wow, exhaustive. It is really intense.

And this entire channel is called The Bad Movie Bible, is really great. And don't let the name get it's not like a, it's not like a how did this get made type of thing. They'll do things where it's like, here's an hour long on all of the alien knockoffs of the 19 eighties, all of the James Bond knockoffs. And he'll just go through an hour talking about all the different actors, every different country that's producing these things, the studios, and it's so so deep. And I've watched every video on this channel multiple times, and, the Shinobi Get In one is my my favorite one. The newest one, so check it out. Tons of tons of really cool stuff here.

Nightmare on Elm Street knockoffs, Die Hard knockoffs.

Just so many cool things. Great great channel.

I Scott a sick pick, something that you picked a while ago, and I only was recently able to acquire it in Node, and that is the, Bakken's, Japanese barbecue sauce. The how you say it. Yeah. But butch is a little the little octopus guy. Yeah. So this is sort of a soy sauce meets a barbecue sauce.

I don't know if I would. It's called a Japanese barbecue sauce. And you you can put it on, like, on noodles and on meat, and I put it on eggs.

And Scott had sick pick there probably over a year ago, and I've been wanting to try it. And finally, my parents a couple of months ago, my parents went to the states. So I sent them some, and they brought it back for me. And I was like, this is fantastic. So good. I just got back from the states again. I picked up every flavor I could possibly find, and I know Costco sell they sell a huge bottle of it as well.

So there's the original, a spicy, a uzu, and a miso. Now I have all 4 of them. Wow. And it is so good. Like, I put it on absolutely everything, and I can't believe I didn't get it for. My kids love it too. So if you have someone in your life that just, like, is a bit of a sauce head, you should get them a bottle of this or they sell a really cool gift box as well on their website.

Really a nice looking website as well. So

highly, highly recommend you check that on out. It's super good. We'll we'll put it on, like, salmon. We'll put it on stir fries. We're just putting on everything. Yeah. It it's got a little sweet to it. It's a little teriyaki, a little soy. It's Yeah. It's not not quite anything that you can do for. Yeah. But not not too wild in itself. So, yeah, huge fan. And their their logo is darn cute. I wanna get one of these T shirts now that I see these T shirts with the Octopus. They got a hoodie. This JS done well. Their website in general, this is a really nice looking website.

Yeah.

Very cute.

Cool.

Yeah. Shameless plugs. Check out the Syntax YouTube channel. We we set it at the drop. Check out Syntax on all the socials.

You know, get us on TikTok before they make it illegal, all that stuff. Come to Canada. We don't have Bakken sauce, but we we'll have TikTok.

Alright. That's it for today. Thanks, sir, for tuning in. We will catch you later.

Peace.

Peace.