如果您需要一间小屋，为什么要开始
仅有一堆原木？ (If you need a cabin, why startwith a mere pile of logs?)

In the land of JavaScript, no one is king for long.

在JavaScript领域，没有人能长期成为国王。

Just last year Grunt was effectively dethroned by Gulp. And now, just as Gulp and Browserify are finally reaching critical mass, Webpack threatens to unseat them both. Is there truly a compelling reason to change your front-end build process yet again?

就在去年， Grunt被Gulp有效地废th了 。 现在，就像Gulp和Browserify终于达到临界点一样， Webpack威胁要让他们两个都坐下来。 是否有一个真正令人信服的理由， 再一次改变你的前端构建过程？

Let’s consider the merits of each approach.

让我们考虑每种方法的优点。

Browserify(和朋友…) (Browserify (and friends…))

Browserify is conceptually simple. Hey, see all these cool packages on npm? Let me wrap those up for ya so you can use those in the browser. Handy. Thanks Browserify! Yet this simplicity is also its Achilles heel. Chances are you have a long list of other things you need to get done like minifying, bundling, linting, running tests, etc.

Browserify在概念上很简单。 嘿，在npm上看到所有这些很酷的软件包吗？ 让我来包装一下，以便您可以在浏览器中使用它们。 便利。 谢谢Browserify！ 然而，这种简单性也是它的致命弱点。 您可能还有很多其他需要完成的事情，例如缩小，捆绑，整理，运行测试等。

Sure, Browserify has a rich ecosystem of transforms to help get things done. But to wire all this up, you’re on your own. So you’re going to reach for a JavaScript build automation tool like Grunt or Gulp. These tools work great, but configuring them properly is a time-consuming process. After you’ve worked with Grunt or Gulp for long, you start to realize a long list of things you do for every project. Wouldn’t it be nice to start with a more powerful and opinionated tool that made more assumptions about your build process?

当然，Browserify具有丰富的转换生态系统，可以帮助您完成工作。 但是，将所有这些连接起来，您就自己一个人。 因此，您将接触到诸如Grunt或Gulp之类JavaScript构建自动化工具。 这些工具可以很好地工作，但是正确配置它们是一个耗时的过程。 与Grunt或Gulp长期合作之后，您开始意识到针对每个项目要做的一长串工作。 从功能更强大，见多识广的工具入手，对您的构建过程进行更多假设，这不是很好吗？

If you think of your build process like a unique log cabin, then Browserify with Gulp/Grunt is like starting off here:

如果您将构建过程视为一个独特的小木屋，那么带有Gulp / Grunt的Browserify就像从这里开始：

Webpack (Webpack)

Webpack attacks the build problem in a fundamentally more integrated and opinionated manner. In Browserify you use Gulp/Grunt and a long list of transforms and plugins to get the job done. Webpack offers enough power out of the box that you typically don’t need Grunt or Gulp at all. Yep, sorry, that shiny new skill you just mastered is already nearly useless. Uh…yay? Sigh. Welcome to life on the front-end.

Webpack从根本上更加集成和自觉地攻击了构建问题。 在Browserify中，您可以使用Gulp / Grunt以及大量的转换和插件来完成工作。 Webpack开箱即可提供足够的功能，您通常根本不需要Grunt或Gulp 。 是的，很抱歉，您刚刚掌握的闪亮新技能几乎已无用。 嗯...是吗？ 叹。 欢迎来到前端生活。

But hey, that’s the price of progress. With Webpack you can declare a simple config file to define your build process. Woah, a config file? Yes, if you migrated from Grunt to Gulp because you prefer code over configuration, that may sound like a step backward. But configuration isn’t necessarily a bad thing.

但是，这就是进步的代价。 使用Webpack，您可以声明一个简单的配置文件来定义您的构建过程。 哇，配置文件？ 是的，如果您从Grunt迁移到Gulp是因为您更喜欢代码而不是配置，那么这听起来像是倒退了一步。 但是配置不一定是一件坏事。

Configuration-based systems are preferable to imperative systems if they make the right assumptions about your goals up front.

如果基于配置的系统预先对您的目标做出正确的假设，则它们比命令式系统更可取。

I find Webpack does just that. Webpack assumes you need to move files from a source directory to a destination directory. It assumes you want to work with JavaScript libraries in various module formats like CommonJS, and AMD. It assumes you’ll want to compile various formats using a long list of loaders. Sure, you can do all this via Browserify and Gulp, but you have to do more wiring yourself. And you’re manually wiring together two totally separate technologies.

我发现Webpack就是这样做的。 Webpack假定您需要将文件从源目录移动到目标目录。 假设您想使用各种模块格式JavaScript库，例如CommonJS和AMD。 假设您要使用一长串的加载程序来编译各种格式。 当然，您可以通过Browserify和Gulp完成所有这些操作，但是您必须自己做更多的接线。 您将两种完全独立的技术手动连接在一起。

The integrated nature of Webpack really shines when you consider the stories for working with other assets like images and CSS. Webpack is smart enough to dynamically inline your CSS and images when it makes sense. You can simply include these assets like you do with JavaScript today. Want to use CSS? Easy:

当您考虑与其他资产(例如图像和CSS)一起使用的故事时，Webpack的集成本质确实令人眼前一亮。 Webpack足够聪明，可以在需要时动态内联CSS和图像 。 您可以像今天使用JavaScript一样简单地包含这些资产。 要使用CSS吗？ 简单：

require("./stylesheet.css");

Huh? Why not simply reference CSS the old way? Well, Webpack will consider the size of this file. If it’s small, it’ll inline the stylesheet! If it’s long, it’ll minify the file and give it a unique name for cache busting. This same story works for images as well using the url loader plugin.

?？ 为什么不简单地以旧方式引用CSS？ 好吧，Webpack将考虑此文件的大小。 如果太小，它将内联样式表！ 如果太长，它将缩小文件并为缓存清除指定一个唯一的名称。 使用url loader插件，同样的故事也适用于图像 。

img.src = require(‘./glyph.png’);

Webpack will base64 encode this image if it’s small enough that it makes sense. Slick!

如果图像足够小，Webpack将对该图像进行base64编码。 光滑！

Since Webpack is totally aware of your build process, it can intelligently split your resources into bundles. This comes in handy on larger SPAs. Your users will be served only the files they need for a given page instead of a single monolithic JavaScript file.

由于Webpack完全了解您的构建过程，因此可以智能地将您的资源分成多个包 。 这在大型SPA上很方便。 将仅向您的用户提供给定页面所需的文件，而不是单个JavaScript文件。

Finally, if you want to enjoy rapid application development without browser refreshes, Webpack offers hot module replacement. If you happen to work in React, you can utilize React Hot Loader. Yes, Browserify has an equivalent, but in my experience, Webpack’s implementation by @dan_abromov is superior. Trust me, once you’ve experienced rapid feedback application development like this, you’ll never go back:

最后，如果您希望在不刷新浏览器的情况下享受快速的应用程序开发，则Webpack提供了热模块更换 。 如果您碰巧在React中工作，则可以利用React Hot Loader 。 是的， Browserify具有等效的 ，但在我的经验，的WebPack的实现由@dan_abromov 优越。 相信我，一旦您经历了像这样的快速反馈应用程序开发，您将永远不会回头：

Webpack assumes you want to build a log cabin. So you start with a real cabin, and then it gives you the tools need to tweak it to your needs.

Webpack假设您要构建一个小木屋。 因此，您从一个真正的机舱开始，然后为您提供根据您的需求进行调整的工具。

底线 (The Bottom Line)

If you prefer explicitly configuring small single-purpose tools from the ground up, then Browserify with Gulp/Grunt is going to be more your style. Browserify is easier to understand initially since the conceptual surface area is so much smaller — assuming you already know Gulp or Grunt. When using Gulp with Browserify, the resulting build process can be easier to understand than the equivalent Webpack build. It’s often more explicit about intentions. Browserify’s rich plugin ecosystem means you can get just about anything done with enough wiring. Ah, the wiring. That’s the big downside. Being this explicit takes a lot of time and debugging to get right. I recently created a starter kit for my upcoming Pluralsight course on React and Flux. It pulls in some React specific tech, but removing those dependencies is trivial if you’re just looking for a quick way to get rolling with Browserify and Gulp.

如果您希望从头开始明确配置小型的单用途工具，那么带有Gulp / Grunt的Browserify将更适合您。 最初，Browserify更容易理解，因为概念表面积很小(假设您已经知道Gulp或Grunt)。 当将Gulp与Browserify一起使用时，所产生的构建过程比等效的Webpack构建更容易理解。 通常对意图更明确。 Browserify丰富的插件生态系统意味着您只要进行足够的布线就可以完成几乎所有事情。 啊，接线。 那是很大的缺点。 明确表示需要花费大量时间和调试才能正确。 我最近为即将在React和Flux上进行的Pluralsight课程创建了入门工具包 。 它引入了一些特定于React的技术，但是如果您只是在寻找一种快速的方法来使用Browserify和Gulp进行滚动，则删除那些依赖项是很简单的。

But if you’re comfy with a little “magic” via a single more opinionated tool, then Webpack can reduce the time it takes to stand up a robust build process. I’ve found my Webpack configs are usually about half the size of the equivalent Gulp file. The win isn’t merely less typing — This also translates to less time spent debugging your config.

但是，如果您对通过一个更自以为是的工具感到有些“魔术”感到满意，那么Webpack可以减少建立可靠的构建过程所需的时间。 我发现我的Webpack配置通常大约是等效Gulp文件大小的一半。 胜利不仅是减少打字，而且还意味着可以花更少的时间调试配置。

Massive Grunt files turned many off to the idea of configuration. But Grunt’s failure wasn’t configuration. It was a lack of opinion. Configuration isn’t evil. It’s a powerful time-saver when the assumptions are right.

大量的Grunt文件使许多人无法接受配置的想法。 但是Grunt的失败不是配置。 缺乏意见。 配置不是邪恶的。 当假设正确时，它可以节省大量时间。

Build tooling shouldn’t require a custom build from the ground up. It should provide customization points that allow you to handle the few things that make you truly unique.

构建工具不应要求从头开始进行自定义构建。 它应该提供自定义点，使您可以处理一些使您真正与众不同的事情。

准备深入研究了吗？ (Ready to dig deeper?)

The updated Webpack docs are great, but I suggest reading Pete Hunt’s excellent intro instead. Then, check out “Creating a JavaScript Development Environment” on Pluralsight (free trial) to see a full development environment built from the ground up using Webpack.

更新的Webpack文档很棒，但是我建议阅读Pete Hunt的出色介绍 。 然后，在Pluralsight上查看“ 创建JavaScript开发环境 ”( 免费试用 )，以查看使用Webpack从头开始构建的完整开发环境。

Using React? Check out “Building Applications with React and Redux in ES6”.

使用React吗？ 签出“ 在ES6中使用React和Redux构建应用程序 ”。

Chime in on Hacker News or Reddit

报名参加Hacker News或Reddit

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect at VinSolutions, a Microsoft MVP, and trains software developers internationally on software practices like front-end development and clean coding. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

Cory House是JavaScript，React，干净代码，.NET等课程的多本课程的作者，并且还提供了有关Pluralsight的更多课程 。 他是reactjsconsulting.com的首席顾问， VinSolutions的软件架构师，Microsoft MVP，并且在软件开发方面对国际软件开发人员进行了培训，例如前端开发和简洁编码。 Cory在Twitter上以@housecor表示关于JavaScript和前端开发的推文 。

翻译自: https://www.freecodecamp.org/news/browserify-vs-webpack-b3d7ca08a0a9/