Hasty Treat - Vite + Parcel 2

Monday. Monday. Monday.

Open wide dev fans. Get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest TS, web development treats coming in hot. Here is Wes, Barracuda, Boss, and Scott El Toro Loco Tolinski.

CSF.

Welcome to Syntax. In this Monday, hasty treat. We're gonna be talking about some modern build tools, And we're gonna be talking specifically about Parcel and VIT VITE VIT, all of the above there. We're gonna be talking about those and a little bit about Some of the comparisons between these modern tools and some of what makes them modern. Now my name is Scott Tolinski. I'm a developer from Denver, Colorado, and with me as always is

CSF. Wes Bos. Hey. I'm excited to talk about these tools because they are

both amazing and, like, next level. So, yeah, stoked that we're getting here in web development. Well, speaking of next level modern tools, we have 2 amazing sponsors today. We're sponsored by Prismic as well as LogRocket.

Now LogRocket is the perfect place where you can see errors and exceptions happen in a video scribbleable replay, Giving you access to the network tab, the error logs, and all of the things that you know and love, in your own local debugging experience.

You ever feel like you're debugging in a black box? You can't see anything? Wes, do you watch Top Chef? No. No. I have maybe have is that the one with Gordon Ramsay? No. That's MasterChef. No. Oh, it's I watch MasterChef. Yeah. Okay. We watch TopChef. We watch MasterChef too. But in TopChef, they had a they had The challenge where they had to go into a black box room and and, like, taste some food to debug it and figure out what it was before making it. Oh, that's fun. Yeah. No. You don't you don't get any of that with LogRocket. You're not gonna be put into a Top Chef style mess black box and have to figure out what the heck's going on. You can solve errors and exceptions right there with a video replay, so check it out at log rocket.comforward/syntax where you will get 14 days for free. We are also sponsored

by Prismic, which is a headless CMS. They just raised a whole bunch of money and are Just you're gonna make a really, really awesome they already have an awesome product, and what it is is that you sign up, you create your content types, And they're really pushing this approach where instead of creating, like, a page and then assigning inputs for that specific page and then pulling them in, They're telling you, no. No. No. Go ahead and make slices, meaning that these are just sort of, like, you have a component, and that component has data. Then you make a Slice that sort of mirrors that component, and those have the inputs, an image upload, a number input, a text area, a title, things like that. And then whenever you wanna put together a page, you go and click together those slices to make an entire pizza of a website. So check it out for your next website, Prismic dot I o forward slash syntax, and they have a really funny landing page there that you just have to check out. Thank you, Prismic, for sponsoring. Cool. Alright.

Next gen bundlers, and I wouldn't even say these are just just bundlers. They are like bundlers and production ready makers, and, well, maybe we'll get into what they are. But, basically, Vite And parcel 2 are the sort of 2 tools that you use for building JavaScript applications that make that ticked all the Pain of writing configs and setting everything up yourself, they take that totally away, and they make just a really, really nice authoring experience for your JavaScript applications, and we're gonna talk about them. They are at least in my opinion, they are kind of, like, the exact same thing. There's a little bit of ups and downs here or there between the 2, but they both are awesome. So we're we're just looping them into 1 show to sort of explain what they are and why you should try them.

Yeah.

So let's talk a little bit about what makes them different, first and foremost. Like, what makes them different. Besides the fact that they're fast and there's technology behind them that makes them fast, I think the biggest thing that makes them different is the usage of ECMAScript modules to load individual files and then use hot module reloading to replace those files.

So what that means is that many times when you're using these tools, you import a file or you request The file, whether that is a TypeScript file, a CSS file, or whatever, and the build tool takes that 1 specific file and it Turns it into whatever it needs it to be at the time that you're requesting it, and then spits out something that you can use and have available into a f. A dot j s file loaded up and then have it be ready to be accessed, scoops it all in there with hot module reloading by reloading just that one Specific module, and you're good to go. Meaning that instead of changing your whole project down to save and having to rebundle, rebuild, You're just really getting rid of 1 specific file. So it's it's how fast can you recompile that file is the name of the game, And that really is why it ends up being so so fast. Yeah. Exactly. I I think, like, a lot of the stats that you read

Where these things are a 1000 times faster, a lot of those stats are build time, and the builds are very, very fast. But I think what you, As the developer listening to this are more probably concerned with is, what does the dev experience look like? Because if it takes an extra

1 or 2 seconds to actually build your JavaScript application. That's not the end of the world. Mhmm. It is, though. It is it? It is. It's the end of the world, you know, because CSF. Those those seconds, they add up, and in that time, I could master everything I needed to do to save the world from some sort of a disaster. That's true. Yeah. You're a good point. The time does add up, but these new tools are are are so fast that the speed almost becomes,

Like, unimportant entirely because they're almost too fast for you at this point. I mean, your brain can't work any faster. Yeah. And and that's amazing because Just like what 5 years ago, we are at a spot where you would save your file, and then it would have to recompile the entire thing. And then You're lucky if you had hot module reloading or you had to go and refresh the page. And that that whole process, especially if you had CSS in there, that whole process would take, Even if it takes seconds, that is very slow and very frustrating to debug. And these new tools are unreal fast. They either use HMR or fast refresh, and you see the updated CSS changes. You see the updated templating. You see the new Functionality, like, immediately on the page. That is really cool. And they also work with vanilla JavaScript really well. I remember In the past, I had issues with Parcel 1 in vanilla JavaScript because if you added an event listener to something and then it hot reloaded, then it would add another event listener. And I'm pretty sure that is gone in both of these Mhmm. Which is really nice. You don't have to worry about unbinding and rebinding,

which is great. It is great. So Let's reach under where our feet are, and let's pull the little handle and just pop open the hood, walk around in the front of the car, and let's get under that hood. The bonnet for, the bonnet. Your Brits? The yeah. Under the bonnet, and, there's no frunk in here. We have, toot I always laugh at all the the Doug D'Amiras talking about the the frunks and Stuff and all the new cars. Love a good Frank. Yeah. Love a good Frank. Under the hood here, we have 2 different tech powering the both of these build tools where Parcel is using something called SWC, which is Rust based, and Vit Vitvit uses esbuild, which is Go based.

Now I don't know if Parcel uses anything else. It might just be Parcel all the way down from there, but, Vite also uses Rollup And Rollup 2 do their production builds. And, actually, for their plug in interface as well, meaning that you can use Rollup plug ins with Vite as well.

So if you, like, need to get that Babble stuff back in there, you can use the Babble plug in. When I was using ES build server side, I had to write my own GraphQL plugin at the time because one did not exist, and I had a GraphQL loader that changed a dot GraphQL file into a JavaScript file. Right?

With, Vite, I didn't need to do that because there already existed one for roll up, and it was really easy to just install and drop it in. Yeah. That's kinda interesting thing about Parcel is that it is the bundler. Like, it's it's equivalent to, like, a webpack or roll up, but then it's also equivalent to, Vite or any of these other tools that sit on top of it. So, I don't think it has a underlying thing, except for I guess that's what SWC is. So they recently announced just in the last week or so at the time of recording is that they are now using w c, and that is the

let me pull up the notes. Is so is SWC the build tool and Parcel is the bundler?

Yeah. Actually, I think you're right there. SWC is a super fast TypeScript JavaScript compiler written in Rust. So Yeah. I think previously, Parcel was doing it all itself, but they switched it out, Which is really cool. So it's really interesting. Both of these tools don't use JavaScript to actually do the bundling. They all go to a secondary language, Rust and Go, to do all the TypeScript and JavaScript stuff. And, SWC is also what Deno is moving to.

Strapi uses it in Parcel, and then ES build is

what Vite uses. I know ES build is pretty popular as well. Is there other tools? Snowpack uses it. Snowpack, that's the one I was thinking about. It's very good, and we use ES build ourselves just plainly with just ES build. It's even very easy to get up and running. If you wonder why you would use something like Vite over just ES build by itself, it also includes, like, a development server and the hot module reloading stuff. ESBuild does not include that. ESBuild is straight up going to take your TypeScript or whatever and transform it into JavaScript faster than you can even think. That's what it's doing. Unless you are building your own development tool, you probably want to use one of these abstractions that sits on top or one of these dev tools because they give you the whole

Local host URL, and it it does all the searching for your your values. So you probably wanna use a tool like v or Parcel on top of it. And we'll talk about There are some slight differences between the 2. We'll talk about that near the end. Let's talk about how you use them. The beautiful thing about both of these tools is that they are both Based on standards, which is ECMAScript modules. So at the very basic, you have an HTML file, you have a Script tag that has a type of module. That's how you tell a browser that you're using modules, and then you point Your tool at your index, the HTML file or really any HTML. You can do multiple entries as well, And then that will look for any CSS that is needed, and it'll also look for any JavaScript that is needed. And then it will look in your JavaScript and your CSS for any images that you have, and it will compress them and and do all the the things that you're expecting from there. And it's So beautiful because, like, if you think back to, like, what we used to do with, like, Gulp, you would have to, like, point it at all of your images and all of your CSS and all of your JavaScript, script, and then you had to think ahead of what all your assets were and then load those into your app. Mhmm. This is sort of opposite as you just give it your app, And it will sort of crawl through the entire application, finding all of the little pieces that it needs.

And then by default, it has All kinds of really good adapters for the most common thing. So the ideas with these things is that they just work out of the box, for the most common use cases that you're gonna have. And we're talking React and Vue, TypeScript, Sass, PostCSS, all of those things. They just work out of the box. And then If you have something custom that you want to do, maybe you're using, I don't know, Handlebars JS or something like that, then you can load in adapters for those specific

Types of languages, then it will be able to handle those as well. Yeah. Which is it it's honestly, it's the right way to do things because you just think about, hey. You know, I have this file. I can load it up, and I don't need to worry about it. I mean, that that is to me the the nicest thing because you're thinking more about the files you're working with rather than the files that the compiler That's out. And at the end of the day, I think that that gives enough of the mental model to make it just a little bit easier on your brain. So for me, I I I really love that that flow of things where I don't have to think about it. It reminds me a lot of, I know Meteor didn't do this specifically, but It reminds me a lot of the things I liked about Meteor's different file, the way you work with files in in Meteor. So you know what? A lot of this stuff is neat. By the way, I I this is somewhat unrelated to these build tools, but related in the sense that you could import different things now. Have you seen Some of the stuff that's been going on with ECMAScript module imports where there is JSON importing natively as well as CSS importing natively No. Using the import assertions or what they're called. Import.

So import assertions Where you can now import I know JSON the JSON one is, like, here here, but the CSS one is coming.

Import Import JSON.

Oh,

I'm looking at the the proposal for this. Yeah. So the the proposal is basically you would import Config from, and then you'd point it to a dot JSON file. And then the import syntax has a new little bit at the end of it called assert, And then you assert the type of the file that you're importing. So you assert type of JSON, and then that allows you to Natively import a JSON file and have access to the properties from that as if it were an object. And it it seems like the same thing is coming for CSS, so that sounds Fantastic. Soon, we'll be able to import all sorts of stuff natively. Wow. Or even I wonder even if you could, like, import it as text. Like, I wonder if it's MIME type. Yeah. I wonder. Does it you do it on the mime? I have no idea. I've just seen this come in, and and if you're wondering why this is, like, interesting or or different than what we have Currently what we have currently, it's up to the build tool or the bundler to determine how to handle those imports, and then it it does it in its own way rather than, You know, being part of the platform. So it could lead to much more standardized ways of doing these things, less,

you know, less friction between platforms. That's really cool. I'm excited about this. It's funny. We talk about in the same breath, we talk about ES modules, which is a standard, and then we talk about importing CSS and images, which is, like, that's not part of any standard anywhere. That's just something that these tools allow you to do. And luckily, they work the same way. So if you needed to switch between one another,

you totally could. And I think that can get lost on some people because you you do. You start Working in some things and you start getting going, you import a CSS file, and that just feels like it's like what you do. Yeah. But in reality, it's the tool that's helping you do that.

Let's go through rattle through some common use cases.

So React and JSX just works out of the box.

Vue works out of the box. Have you you use Svelte with Vite. Right? Yeah. That's just built in. Right? Yeah. You don't even think about it. But there there are some of the the neater features that Vite has, like the glob imports, allowing you to import many files based on a glob that I really like that comes with Vite. So does Parcel give you glob imports? Because that Oh, that's a good question. Maybe that is a, Defining factor.

Yeah.

Glob import.

I don't see it in the docs. They do have dynamic imports, which which is like an import function you can import, But the yeah. The the glob imports is super handy. We talked about that because you can kinda make your own little router just with a couple lines of code that way. Right? Yeah. Because you could just say, hey. Import everything in this folder.

That's, basically file based routing right there. Oh, man. You know what?

I've been trying to do that. So for my TypeScript course, I've been bouncing between both Vite and Parcel Mhmm. As just a way to sort of get going on this. And one thing I wanna do is I don't wanna have to create, like, a new package JSON for every single tiny little exercise that we do. So I just wanted to, like, have, like, a listing of all of the HTML files because both of these tools allow you to, have multiple entry points. Like, you can you can go to Local host 3,000 forward slash about, and it will just give you about dot HTML. But but neither of them have, like, a A directory where you can see all of your HTML files. And I wonder I'm gonna try it after this act this podcast. I wonder if I can use Vite's Glob import to sort of render out, like, an index page. If that's the case, then I think Vite will win. Oh, that'd be fun. Yeah. That'd be cool. Little, like, little blog listing for your Your HTML your examples listing. Yeah. And then just like an easy way for instead of having to tell people to type in, like, exercise4.html.

Then you can just click on a link or maybe even, like, iframe them in to give yourself a little, Oh, yeah. Little preview? Yeah. Yeah. Okay. I'm gonna try it after this. I'm so excited about that. Now you're cooking with gas.

What else do we have here? TypeScript, both just work.

Both of them do TypeScript super well. The neither of them do type checking, if I'm correct, Because the only thing that can do type checking is TSC, which is the TypeScript thing. Eventually, SWC in is Going to,

implement types. I'm not sure if that's under the scope of what ES build will do. I don't think ES build is attempting to do anything like that. I think their their mantra is just strip the TypeScript

fast Bundling. Yeah.

And then you can run TC in parallel or run it when you need to run it. In fact, what we do is We run it manually when we want to for that stuff, and then we have it on all of our continuous integration stuff in all of our GitHub actions. So we're seeing If we somehow manage to get a little PR up there without a type compiler, we'll run-in our action and tell us that it failed. Yeah. Yeah. That makes sense. And and for most of the time you're doing,

You want your type checking in your editor, and that uses currently uses TSC, but your editor might be able to switch Just something faster once once that's available and then just having regular type checking as part of your build process, like Scott just said.

What else we have here? Custom Babel config. So I think the idea with a lot of these things is that you don't have to use Babel for a lot of these things because They do what Babble was doing for you. But that said, sometimes there's tons and there's hundreds of Babble plugins out there, and sometimes the app you've built needs a Babble Transpiler or plug in for it. So if that is the case, then there are plug ins for both of them. I believe the reason why they try to step around Babel is because the part of the reason why it's so fast is that you don't have to go through that entire Babel transform in development,

and usually, it's unnecessary to actually have to run that Transform in development as well. Yeah. That is really it. You're cutting the speed short a little bit if you're passing it through Babblex Babble Is for you know, as amazing as it is, I mean, it's been going along here for a long time in terms of, like, What it's needed to do and a lot of these tools were able to just look at this from the ground up in a modern sense and say, like, what does this need to do here? And that's probably why it's faster. Right? You anytime you you before you add all these edge cases and whatever, and imagine having edge cases for that minute amount of time and having to maintain backwards compatibility. Yeah. So we primarily don't use Babel for anything in our our stack or anything like that, and It's been much nicer to not have it than in the same regard. You hit something that requires Babble, and it makes you very upset.

I think the ecosystem right now is just assumes that you have Babel in a lot of this stuff, and I think we're starting to see a shift away from that. So there might be a little bit of pain, but I think with anything, whenever we make these, like, big 7, 10 year changes From one big tool to another, then you have a little bit of pain in the short term.

And that is sometimes why it's worth just sitting back And waiting a year or 2 on some of these tools because people are figuring out solutions to all of these problems.

Yeah. Because if you picked Flow over TS, You're gonna be a little concerned about that choice right now.

What else? They both have a custom API. So if you wanted to build your own plugins or transforms or forms or literally anything for them, you can. Both of them allow you to hook into the dev server as well. I was working on a Vee plug in To do exactly what I was just talking about with the index page Mhmm. It's about half done right now. But now that you are talking about the glob imports, I am Rethinking that decision. They're easy. They're easy to work in. So yeah. Yeah. So the final question is, which one should you use? They are both Very fast probably faster than you necessarily care about at the time. I don't know. It it depends. Like, you run your app through it and and see. Parcel 2 has been in development for over 2 years, and it's still in development. So not sure when that will launch. I've been using Parcel 2 on my own personal website for a while.

In my personal experience with doing my TypeScript course, Vite seems to work just a bit better. I'm not sure if that's because Percals 2 is in dev still, but, like, I I have never hit a An issue with Vite, and I've hit a couple little things here or there with with Parcel 2. So

Vite is is very, very good. I'm very surprised that it all just works. It's it's very good, and I've hit some snags here and there. But for the most part, it's it's only when I'm, like, really getting the weeds with some stuff. So, No. I I've I've found I haven't used Parcel 2, but my experience with it has been just very, very, very good, very, very positive.

Yeah. It's been so good that, like, you literally haven't had to look elsewhere because you've been so happy with it, which is awesome.

Totally.

I literally Was Literally. I put a screen record. I literally did a screen recording, and I hit save on my editor. And I had both Browsers open to 1 with Parcel 2 and 1 with Vite, and I, like, had to scrub to within 10 milliseconds of each other to see, like I was, like, background green, and I hit Save, and they're all very, very fast.

There was a thing where when I was working with Vanilla JS and I hit save, Vite would refresh the entire page, and Parcel 2 did a better it didn't have, like, a little quick little flash, you know, like that little Flash of unstyled content, wherein I'm not sure if it refreshed the page or it just pulled everything out and put it back in. I'm pretty sure it did the the latter, But Parcel 2 did a little bit of better job in that use case. I'll see if I can dig up the example of that as well because I'm not sure if that is still an issue. But Other than that, they are all very, very similar.

Very happy with these tools. I am just, like, thinking back to the when we used to write webpack configs that were six 100 lines or or grunt huge grunt files or Gulp tasks. And Yeah. At a point, I was, like, running a Gulp workshop.

And I'm trying to think now, could you run a couple of be or a partial workshop be? Hey, folks.

It's so accurate, And I'm so glad I I missed the whole webpack train because I saw a webpack config, and I was like, no. This is not not my style. Parcel, yeah, Parcel has always been more of my style, but still I'm so glad I got to miss miss all of that. Thank you.

Yeah. One thing is that Next. Js uses webpack under the hood, and they have they have people that write the webpack config for you. You can layer in your own custom one if you want, but I'd be interested to see if the Next. Js folks are looking at any of these tools And saying, hey.

That would be a neat thing to to do for ours. I I think that'd be kinda like, that'd be a big build because they They do all kinds of custom stuff in there, and I'm sure they have a massive custom webpack config. Yeah. But that's, it's always worth taking a look at these

These tools. Yeah. That'd be a very big build. Cool. Well, do you have any other additional thoughts on this stuff? You know, The way the way I I see any of this is just start using these tools. If you got a a project to do, start using these tools, and maybe you don't need to. Maybe you're using them Through something like SvelteKit because you heard me talk about how awesome it was, but just experience how great these tools are to work in because They will they will step your dev experience up to a degree. And and just the developer experience overall We'll we'll really, really sell you on just how cool these things are. Yeah. If you've got

any little project you wanna build or or you have an idea or you just wanna write some you just wanna write some CSS and have it fast refresh, these are the tools that you need to do. You you touch In next HTML, touch style .CSS, link it up, and you type in Vite or you type in parcel, and it will just fire up immediately.

It gives you a URL To your local and your on your local network as well. So good. So huge shout out to all the devs behind these tools because you are making my life great. CSF. Big ups. Big ups. Big ups.

Alright. That was a long episode, so we'll end it here. Thanks so much for tuning in. Catch you on Wednesday.

Peace. Peace.

Head on over to syntax.fm for a full archive of all of our shows, and don't forget to subscribe in your podcast player, or drop a review if you like this show.