• A Future Without Webpack
  • By FredKSchott
  • Translation from: The Gold Project
  • This article is permalink: github.com/xitu/gold-m…
  • Translator: Badd
  • Proofreader: MarchYuanx, Sunui

May there be no Webpack in the future

NPM packages installed with @pika/ Web run directly in the browser. Do you need a bundler?

The year is 1941. Your name is Richard Hubbell. You work at an experimental New York television studio owned by CBS. You’re about to host a major television newscast, one of the first television shows in the world, and you’re on in 15 minutes. You know what you’re gonna do later?

In a world where all people know is radio, you believe what you know. And what you know at the moment is that you have to read the press release. “Hubbell’s television news shows were almost scripted, occasionally cutting to a map or a still picture.” It will be a while before people see the actual footage on the TV news.

As a JavaScript developer in 2019, I feel the same way. We already have this new JavaScript module system (ESM) that can run directly in a Web environment. But every time we develop something, we still have to use the packaging tools. Why on earth?

Over the past few years, the popularity of JavaScript packaging has shifted from being optimized for production only to being packaged for every development. Like it or not, it’s hard to deny that packaging tools add a perverse level of complexity to Web development, an area that has always prided itself on the spirit of source visibility and ease of use.

@pika/ Web is trying to save Web developers from packaging hell. It’s 2019, and you should be using packaging tools because you want to, not because you have to.

Credit: @stylishandy

Why are we packing

JavaScript packaging is just new wine in old bottles. In the past (ha ha, about six years ago), it was common practice to compress and merge JavaScript files in a production environment. Doing so will speed up the site load and bypass the HTTP/1.1 parallel request bottleneck.

How did this optimization become an absolutely necessary part of the development process that would have been better with or without it? Here’s the crazy part: Most Web developers never specifically ask for packaging. Instead, packing is just a side effect of what we really crave — NPM.

NPM — which at the time stood for “Node.js package management tool” — was on its way to becoming the largest code registry ever built. Front-end developers want to be a part of it. The only problem is that its Node.js style module system (common.js or CJS) can’t run in a Web environment without being packaged. Hence Browserify, Webpack, and other modern Web packaging tools.

Get a feel for creating the React app: You need to install more than 1300 dependencies to run Hello World

Complex Stockholm syndrome

These days, it’s almost impossible to develop a Web project without using a packaging tool like Webpack. Take the Create React App (CRA) shortcut. When you want to Create a project quickly, but you need to install over 1300 different dependencies, the bloated node_modules folder is 200.9MB in size. You just want to run “Hello World”!

Like Richard Hubbell, we all get so bogged down in packaging tools that it’s too easy to overlook how different things could be. We now have so many great modern ESM dependencies available (almost 50,000 on NPM!) . What prevents us from using them directly in a Web environment?

Well, there are a couple of reasons. 😕 It is extremely easy to write your own Web native ESM modules, and there are indeed some non-dependent NPM packages that can run directly in a Web environment. Unfortunately, the vast majority of NPM packages don’t work. The package itself inherits the dependencies of its dependencies, or the special way the NPM package imports the dependencies by the package name.

That’s why @pika/ Web was created.

Pika /web: Web application without packaging.

Modern NPM dependencies installed with @pika/ Web can run directly in the browser, even though the dependencies themselves have their own dependencies. One step at a time. It is not a build tool, nor is it (in the traditional sense) a packaging tool. @pika/ Web is a install-time tool that greatly reduces your desire to use other tools and even eliminates Webpack or Parcel stumbling blocks altogether.

NPM install && NPX @ ✔ @ pika pika/web/web installed web - native dependencies. [s] 0.41Copy the code

@pika/web looks at the package.json file, checks all dependencies in “dependencies” that export valid ESM module entry points, and installs them in the local web_modules folder. @pika/ Web works for all ESM packages, even if some packages have internal dependencies on ESM hybrid common.js.

Installed dependency packages work in the browser because @pika/ Web packages each into a separate ESM mode.js file that the Web environment can support. For example, the entire “preact” package corresponds to the file web_modules/preact.js. Such a mechanism can deal with possible defects within the package while preserving the original package interface.

“Wait a minute! You might say, “Well, that’s a different place to pack. Change the soup and change the medicine!”

That’s right! @pika/ Web uses an internal packaging mechanism to output NPM dependencies for web native support, which is the main reason many of us use packaging tools in the first place!

With @pika/web, all the trouble with the packaging tool is absorbed internally by the tool at installation time. You don’t have to look at a single line of configuration code for the packaging tool if you don’t want to. But, of course, you can continue to use other tools you like: those that improve the development experience (Babel, TypeScript) or those that optimize the product (Webpack, Rollup).

This is the spirit of @pika/ Web: Pack because you want to, not because you have to.

P.S. Oh yeah,My source visible again!

performance

Installing each dependency the @pika/ Web way (as a single JavaScript file) gives you a huge performance boost over most packaging tools: dependency caching. When you package all your dependencies into one big vendor.js file, every time you update a dependency, you have to force users to download the entire vendor.js file again. With @pika/web, updating a dependency package does not cause the user to re-cache all dependencies.

@pika/ Web helps you get rid of the performance drag caused by packaging tools. Redundant same code in multiple packages, slow first screen loading due to useless or irrelevant code, pits and bugs caused by upgrading the Webpack ecosystem… All of these articles and tools are evidence that people are struggling to deal with the side effects of packaging tools.

To be clear, not packaging source code is not always perfect. For the compression effect in the process of network transmission, large size JavaScript files are better than small size, fine-grained files. Under HTTP/2, browsers spend more time parsing requests that import multiple small files before sending subsequent requests.

It’s a trade-off between performance, cache efficiency, and the complexity you can live with. Again, this is the spirit of @pika/ Web: Pack because you want to, not because you have to.

Pika Web development strategy

@pika/ Web has completely changed the way we do Web development. Here’s how we built pika.dev, and we highly recommend that you use @pika/ Web for your next Web app in 2019:

  1. When starting a new project, don’t introduce a packaging tool. Write code in modern ESM syntax and install NPM dependencies that run directly in a Web environment with @pika/ Web. No tools are needed.
  2. You can always add tools. If you need strong typing, add TypeScript. If you need to use experimental JavaScript functionality, add Babel; If you need to compress your JavaScript code, add a Terser. More than half a year later, pika.dev is still well on its way to this stage of development.
  3. When you feel the need and have time to use a packaging tool, try adding a simple packaging tool to your project. Test its performance. Does the first screen load quickly? What about the second screen? If everything is ok, arrange it!
  4. Optimize the configuration of the packaging tool as the development process progresses.
  5. When you have a budget, hire a Webpack specialist. Congratulations! If you have the resources to hire a Webpack expert, you’re officially done.

Want to see some examples? There are there!

  • A simple project: [source code] [Online Demo]
  • A Preact + HTM project: [source code] [Online Demo]
  • Electron., Three js… Click here to see the full examples

If you find any errors in the translation or other areas that need improvement, you are welcome to revise and PR the translation in the Gold Translation program, and you can also get corresponding bonus points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

Diggings translation project is a community for translating quality Internet technical articles from diggings English sharing articles. The content covers the fields of Android, iOS, front end, back end, blockchain, products, design, artificial intelligence and so on. For more high-quality translations, please keep paying attention to The Translation Project, official weibo and zhihu column.