This is a
playground to test code. It runs a full
Node.js environment and already has all of
npm’s 400,000 packages pre-installed, including
parcel-bundler with all
npm packages installed. Try it out:
This service is provided by RunKit and is not affiliated with npm, Inc or the package authors.
yarn global add parcel-bundler
or with npm:
npm install -g parcel-bundler
<html> <body> <script src="./index.js"></script> </body> </html>
See parceljs.org for more documentation!
Based on a reasonably sized app, containing 1726 modules, 6.5M uncompressed. Built on a 2016 MacBook Pro with 4 physical CPUs.
|parcel - with cache||2.64s|
There are many web application bundlers out there with huge adoption, including webpack and browserify. So, why do we need another one? The main reasons are around developer experience.
Many bundlers are built around configuration and plugins, and it is not uncommon to see applications with upwards of 500 lines of configuration just to get things working. This configuration is not just tedious and time consuming, but is also hard to get right and must be duplicated for each application. Oftentimes, this can lead to sub-optimized apps shipping to production.
parcel is designed to need zero configuration: just point it at the entry point of your application, and it does the right thing.
Existing bundlers are also very slow. Large applications with lots of files and many dependencies can take minutes to build, which is especially painful during development when things change all the time. File watchers can help with rebuilds, but the initial launch is often still very slow.
parcel utilizes worker processes to compile your code in parallel, utilizing modern multicore processors. This results in a huge speedup for initial builds. It also has a file system cache, which saves the compiled results per file for even faster subsequent startups.
Finally, existing bundlers are built around string loaders/transforms, where the transform takes in a string, parses it, does some transformation, and generates code again. Oftentimes this ends up causing many parses and code generation runs on a single file, which is inefficient. Instead,
parcel's transforms work on ASTs so that there is one parse, many transforms, and one code generation per file.
parcel is file-type agnostic - it will work with any type of assets the way you'd expect, with no configuration.
parcel takes as input a single entry asset, which could be any type: a JS file, HTML, CSS, image, etc. There are various asset types defined in
parcel which know how to handle specific file types. The assets are parsed, their dependencies are extracted, and they are transformed to their final compiled form. This creates a tree of assets.
After the bundle tree is constructed, each bundle is written to a file by a packager specific to the file type. The packagers know how to combine the code from each asset together into the final file that is loaded by a browser.
All feedback and suggestions are welcome!