Browserify与Webpack

如果您需要一间小屋，为什么要开始
仅有一堆原木？ (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构建自动化工具。 这些工具可以很好地工作，但是正确配置它们