AD: Meituan Chengdu R&D Center is recruiting a large number of Web front-end, iOS, Android, Java backend, QA, technical cattle, good pay, great development prospects, comfortable life, please email [email protected]

As long as it is a good thing, it can quickly get a lot of attention. No matter how qualified the elder brother is, he will soon be replaced as long as he is not as good as the new one.

Parcel has been a big hit in the front end, earning 13K stars in just a few weeks. Why has Parcel, a newcomer to front-end building tools, gained so much traction in such a short time? What advantage does he have over big Brother Webpack?

I’ve spent six months writing a comprehensive introduction to Webpack, In Plain English Webpack, which just came out and feels cut in half by the new Parcel. But in the spirit of fairness and fairness, this article will take a closer look at the two so you can see their direct similarities, differences and pros and cons to decide whether to Parcel or Webpack.

To compare them, let’s use a Parcel and Webpack as examples.

  • The project uses TypeScript+React+SCSS;
  • The Antd UI component library is used in the project, but only used components are loaded on demand, rather than all the components are packaged;
  • The project uses the Lodash library to check the build’s ability to weed out useless code (TreeShaking);
  • In order to improve the development efficiency, it is necessary to support module hot replacement.
  • SourceMap support for easy debugging;
  • Compare their first startup speed with their build speed when listening for changes;
  • In the production environment need to compress JS, CSS, CSS need to extract into separate files, and compare them in the production environment to build the file size;
  • Need to generate HTML files that will automatically load the corresponding resources;

Parcel is a sight to see

Using a Parcel after using Webpack for a long time feels like using an iPhone after using Android for a long time without worrying about details and configuration, and most of the time the Parcel is just enough and comfortable to use.

Using Parcel to fulfill the above project requirements, I just focused on writing the necessary code for the project page, and Parcel intelligently and quickly helped me build a working result.

Here’s what Parcel got me excited about:

  • Parcel can complete the above project build requirements without configuration;
  • A Parcel has built in common scenarios and dependencies, eliminating the need to install dependencies;
  • Parcel automatically detects and packages dependent resources with an HTML entry;
  • Parcel supports module hot replacement by default, truly out of the box;

Webpack, on the other hand, is much more troublesome than a Parcel:

  • You have to write a bunch of configurations;
  • Need to install a bunch of dependencies;
  • Can’t simply generate HTML automatically;

This project took me less than a minute to build and configure with Parcel and five minutes to configure with Webpack.

The Parcel still needs time to polish

Through the above project practices, Parcel currently has the following obvious drawbacks:

  • Does not support SourceMap: In development mode, Parcel does not output SourceMap and can only debug very unreadable code for now;
  • TreeShaking is not supported: Many times we use only one function in the library and a Parcel wraps up the entire library.
  • Some dependencies cause a Parcel to fail: Some Npm modules cause a Parcel to run incorrectly when your project relies on modules on Npm.

Parcel pays a price for zero configuration

In fact, zero configuration is implemented with various common scenarios as the default value, which can save a lot of work and get started quickly, but it also brings some problems:

  • Unruly node_module: Some dependent libraries may be accidentally released to Npm.babelrc postcss.config.js tsconfig.jsonThese profiles are also published, as Parcel currently assumes that the code in the project needs to be processed whenever it finds them in the directory. For example, in the mini-store library.babelrcThe file is published to Npm and the project relies on JS code in lib that has been compiled into ES5, but Parcel will use Babel to process it again. Npm does not officially specify which specifications packages published to Npm must conform to, which can make things difficult for Parcel.
  • Inflexible configurationA zero-configuration Parcel turns off many configuration items and cannot be changed in cases where the configuration is required. Such as:
    • There is no control over special handling of parts of the file to fulfill requirements such as loading on demand;
    • Unable to control the Hash value and name of the output file name
    • Unable to control build output directory structure
    • Unable to map paths to shorten import statements
    • The HTTP development server does not support the HistoryApi;

Scenarios for using a Parcel are limited

Currently Parcel can only be used to build web pages that run in a browser, which is his starting point and focus. In the software industry, there is no solution that is simple to use and can adapt to various scenarios. Even if the so-called artificial intelligence may solve this problem, artificial intelligence cannot guarantee 100% correctness.

In addition to building web pages, Webpack can also do:

  • Package libraries for publication on Npm
  • Building Node.js applications (Homogeneous Applications)
  • Building the Electron application
  • Building Offline Applications (ServiceWorkers)

Build speed vs. output file size

To build the above projects with Parcel and Webpack, collect the following data:

A data item Parcel Webpack
Build environment build time 8.310 s 9.58 s
Development environment startup time 5.42 s 8.06 s
Listen for change build times 3.17 s 2.87 s
The generated environment outputs the JS file size 544K 274K
The generation environment outputs the CSS file size 23K 23K

From the above data, you can see that a Parcel is fast to build but has a large output file

The reasons why Parcel builds quickly are similar to the reasons iOS is smoother to use than Android:

  • Parcel is better integrated and optimized because of its built-in integration, while Webpack lets third party extensions through plug-ins and Loader mechanisms that can slow down performance;
  • Parcel has multiple processes built in parallel, while Webpack is single-process built by default (Webpack also supports multiple processes);

The size of the Parcel output JS file can be caused by:

  • Does not support TreeShaking
  • The names of all files appear in the constructed JS, as shown in the figure:

The above project complete source code can be downloaded

conclusion

At this stage, Parcel is like a beta iPhone that looks nice but isn’t ready for a build environment, and if you were to use Parcel in a build environment right now, trust me you’d be in for a lot of trouble. It doesn’t matter if you step on a pit, it’s the inability to find a solution online that can solve the problem quickly.

I’m not discouraging the use of Parcel. History needs pioneers, and just like Steve Jobs did it all, we need to do it all, so I encourage you to use Parcel for small personal projects.

If Parcel solves the problems mentioned above, I won’t hesitate to use it for my next project.

Read the original