I find build tooling endlessly interesting, especially right now as we’re in a juicy next-gen transitional period with players like Vite, wmr, Snowpack, and esbuild. Hugh Haworth has a good run-down of the new players, and we’ve chatted on ShopTalk about them severaltimes. I especially like it when people blog their personal journeys in moving build tools, like Ben Frain has done.
It’s not like buying a new car where the new one is faster, but they both have steering wheels and doors and brake pedals and stuff. They share a similarity in that they are trying to provide DX locally and UX (via performance) on production — otherwise their approach, what they provide, and what they expect are all quite different.
Those differences mean re-training your brain in how you expect things to work. Here’s Ben on Snowpack:
In Snowpack land, your index.html file needs to reference the transformed version of the files – even though they don’t exist on your file system.
Let me say that again as it’s jolly important. You link to files that don’t exist.
That’s just weird, right?
I always thought Parcel would have struck a nerve with the WordPress crowd harder, since you could point it at the template file where you link up your assets in a WordPress template and have it do its thing. I guess WordPress is too funky with all the wp_enqueue_style stuff and it just didn’t work?
Ben gives Snowpack a tentative thumbs up.
If you are starting a greenfield project I’d have zero qualms opting for Snowpack. It doesn’t have the depth of support documentation or stack overflow questions if you find yourself in the weeds, but generally speaking, it is solid enough to pick up and run with.
Me, next time I get a chance to play with build tools, I think my bar is going to be incredible speed. I’ve spent too much time on projects in my life where the developer experience is slow. I want smokin’ fast updates for whatever I’m working on.
Today we’re gonna talk about application bundlers — tools that simplify our lives as developers. At their core, bundlers pick your code from multiple files and put everything all together in one or more files in a logical order that are compiled and ready for use in a browser. Moreover, through different plugins and loaders, you can uglify the code, bundle up other kinds of assets (like CSS and images), use preprocessors, code-splitting, etc. They manage the development workflow.
There are lots of bundlers out there, like Browserify and webpack. While those are great options, I personally find them difficult to set up. Where do you start? This is especially true for beginners, where a “configuration file” might be a little scary.
That’s why I tend to reach for Parcel. I stumbled upon it accidentally while watching a tutorial on YouTube. The speaker was talking about tips for faster development and he heavily relied on Parcel as part of his workflow. I decided to give it a try myself.
What makes Parcel special
The thing I love the most about this bundler: it doesn’t need any configuration. Literally, none at all! Compare that to webpack where configuration can be strewn across several files all containing tons of code… that you may have picked up from other people’s configurations or inherited from other projects. Sure, configuration is only as complex as you make it, but even a modest workflow requires a set of plugins and options.
We all use different tools to simplify our job. There are things like preprocessors, post-processors, compilers, transpilers, etc. It takes time to set these up, and often a pretty decent amount of it. Wouldn’t you rather spend that time developing?
Parcel allows you to simply start developing. That’s the biggest advantage of using it as a bundler — alongside its blazing fast compiling that utilizes multicore processing where other bundlers, including webpack, work off of complex and heavy transforms.
Where using Parcel makes sense
Parcel, like any tool, is not a golden pill that’s designed as a one-size-fits-all solution for everything. It has use cases where it shines most.
I’ve already mentioned how fast it is to get a project up and running. That makes it ideal when working with tight deadlines and prototypes, where time is precious and the goal is to get in the browser as quickly as possible.
That’s not to say it isn’t up to the task of handling complex applications or projects where lots of developers might be touching code. It’s very capable of that. However, I realize that those projects may very well benefit from a hand-rolled workflow.
It’s sort of like the difference between driving a car with an automatic transmission versus a stick shift. Sometimes you need the additional control and sometimes you don’t.
Let’s create a simple site together using Parcel
Let’s take Parcel for a test drive to see how relatively simple it is to make something with it.
The basic structure
There’s no scaffolding we’re required to use or framework needed to initialize our project. Instead, we’re going to make three files that ought to look super familiar: index.html, style.scss and index.js. You can set that up manually or in Terminal:
Marvel at Parcel’s quick set up!
Let’s run the application using with Parcel as the bundler before we get into styling and scripts. Installing Parcel is like any thing:
npm install -g parcel-bundler # or yarn global add parcel-bundler
Let’s also create a package.json file should we need any development dependencies. This is also where Parcel will include anything it needs to work out of the box.
npm init -y # or yarn init -y
That’s it! No more configuration! We only need to tell Parcel which file is the entry point for the project so it knows where to point its server. That’s going to be our HTML file:
If we open the console we’ll see something like this indicating that the server is already running:
Server running at http://localhost:1234
Parcel’s server supports hot reloading and rebuilds the app as change are saved.
Now, heading back to our project folder, we’ll see additional stuff,that Parcel created for us:
Now all we do is build!
Let’s go to style.scss and see how Parcel handles Sass. I’ve created variables to store some colors and a width for the container that holds our content:
I’ve said it several times and I’ll say it again: Parcel is a great tool. It bundles, it compiles, it serves, it pre- and post-processes, it minifies and uglifies, and more. We may have looked at a pretty simple example, but hopefully you now have a decent feel for what Parcel offers and how you might start to use it in your own projects.
I’m interested if you’re already using Parcel and, if so, how you’ve been using it. Have you found it works better for some things more than others? Did you discover some neat trick that makes it even more powerful? Let me know in the comments!
Ben Frain just made some notes about the switch from Gulp to Parcel, a relatively new “web application bundler” which, from a quick look at things, is similar to webpack but without all the hassle of setting things up. One of the things I’ve always disliked about webpack is that you kinda have to teach it what CSS, HTML and JS are before making whatever modifications you want to those files. However, Parcel does a lot of the asset management and configuration stuff for us which is super neat — hence, Parcel claim that it requires “zero configuration.”
If you’d like to learn more about Parcel then there’s a great post by Indrek Lasn that details how to get started and even shows off a little bit about how Parcel is often faster than alternatives like webpack. We also just published a post by Kingsley Silas that explains how to use Parcel with React.
You may already be familiar with webpack for asset management on projects. However, there’s another cool tool out there called Parcel, which is comparable to webpack in that it helps with hassle-free asset bundling. Where Parcel really shines is that it requires zero configuration to get up and running, where other bundlers often require writing a ton code just to get started. Plus, Parcel is super fast when it runs because it utilizes multicore processing where others work off of complex and heavy transforms.
So, in a nutshell, we’re looking at a number of features and benefits:
Code splitting using dynamic imports
Hot Module Replacement to update elements without a page refresh during development
Mistakes in the code are highlighted when they are logged, making them easy to locate and correct
Environment variables to easily distinguish between local and production development
A “Production Mode” that speeds up the build by preventing unnecessary build steps
Hopefully, you’re starting to see good reasons for using Parcel. That’s not to say it should be used 100% or all the time but rather that there are good cases where it makes a lot of sense.
In this article, we’re going to see how to set up a React project using Parcel. While we’re at it, we’ll also check out an alternative for Create React App that we can use with Parcel to develop React applications. The goal here is see that there are other ways out there to work in React, using Parcel as an example.
Setting up a new project
OK, the first thing we need is a project folder to work locally. We can make a new folder and navigate to it directly from the command line:
mkdir csstricks-react-parcel && $ _
Next, let’s get our obligatory package.json file in there. We can either make use of npm or Yarn by running one of the following:
## Using npm npm init -y ## Using Yarn, which we'll continue with throughout the article yarn init -y
This gives us a package.json file in our project folder containing the default configurations we need to work locally. Speaking of which, the parcel package can be installed globally, but for this tutorial, we’ll install it locally as a dev dependency.
We need Babel when working in React, so let’s get that going:
Running the yarn run build will now build the application for production and output it in the dist folder. There are some additional options we can add to refine things a little further if we’d like:
--out-dir directory-name: This is for using another directory for the production files instead of the default dist directory.
--no-minify: Minification is enabled by default, but we can disable with this command.
--no-cache: This allows us to disable filesystem cache.
💩 CRAP (Create React App Parcel)
Create React App Parcel (CRAP) is a package built by Shawn Swyz Wang to help quickly set up React applications for Parcel. According to the documentation, we can bootstrap any application by running this:
npx create-react-app-parcel my-app
That will create the files and directories we need to start working. Then, we can migrate over to the application folder and start the server.
cd my-app yarn start
Parcel is all set up!
Parcel is worth exploring in your next React application. The fact that there’s no required configuration and that the bundle time is super optimized makes Parcel worth considering on a future project. And, with more than 30,000 stars on GitHub, it looks like something that’s getting some traction in the community.