Browserify vs. Webpack – Configuration isn't evil (opens in new tab)

As if the churn wasn't already bad enough, I've recently started using JSPM[1] and it's pretty awesome. I'm writing ES6+ code with hot reloading react components.

If you're trying to decide between build systems I would recommend checking it out, and watching this video[2] for a nice overview.

[1] http://jspm.io [2] https://www.youtube.com/watch?v=iukBMY4apvI

A bit off topic: any advice about integrating Webpack with Rails? Looks like the most popular gem to do that has only 19 stars on github... https://github.com/danott/webpack_rails

Am I the only one to find the word "Browserify" intensely annoying? Which syllable is stressed?

All this time I've just been using a boring old shell script that runs browserify with the Babel plugin, and then uglify. Hook it up to npm scripts and I've got all I need, in about half a dozen lines spread across two files.

Browserify is useful because concatenating a bunch of JavaScript files is hardly the right way to be doing things. Babel I have to use because all browsers struggle with ES2015 to an extent. Uglify to minify it all.

But all these other tools? Never had a use for them. Never used grunt or gulp in a new project, and in those that I've looked at which do, they don't really make anything easier.

wow, sweet. another entirely new javascript thing

I'm constantly amazed by people who consider the ability to use Grunt, Gulp, Webpack, Browserify, etc. a "skill". I'm sorry, but to me, that's like being proud of having learnt to use that new washing machine.

More on topic:

> With Webpack you can declare a simple config file to define your build process.

Your Webpack config file is actually a Node module that happens to export a valid configuration object. It even allows your config to depend on a preprocessor (like Babel or CoffeeScript, see [1]).

By the way, if you want to have a "dev" and "production" config which are both based on a "common" config, have a look at [2] (it's nothing fancy, just deep object merge that concats arrays, basically).

[1]: https://www.npmjs.com/package/interpret [2]: https://www.npmjs.com/package/webpack-merge

I don't really agree with the divide as stated here - using Browserify does not imply a need for Grunt/Gulp/new build tool of the week. I would say that npm scripts + Browserify is enough for a surprising number of cases.

If what you really need is "type a couple short words on the command line and have a thing happen", npm can handle that without bringing in something heavyweight like Grunt or Gulp.

Any tool added to a project that attempts to replace Make will eventually be replaced by Make.

BTW, it is really unfair to lump Browserify in with Grunt and Gulp.

I haven't been paying much attention to Webpack but now that I know that along with a magnifying glass, a bottle opener, and three kinds of tweezers it includes a build automation tool, I can be pretty safe in ignoring it from here on out.

To me the big difference is really to do with where the code operates.

With Require.js you make changes to your code to be able to drive it, to avoid having a build step.

Browserify you had to have a build step, but it operates on your code 'from the outside', to avoid having to modify it.

Webpack does both of those.

it has a build step, but it works by extending the require() format to be able to specify the transforms inside the code itself.

The webpack configuration format is mostly just a way to replace require calls at runtime with a regular expression.

I find that this is a lot more straight forward, powerful and explicit than the [1] filename extension checks that happen in most browserify transforms. https://github.com/jnordberg/coffeeify/blob/master/index.js#...

I made a presentation about webpack, if you want to see :

http://adrianrossouw.github.io/webpack-mostly-just-works/

Using 'magic' tooling like webpack, or whatever the next overhyped tool will be, doesn't come without a cost. Webpack is heavily opinionated. Last time I used webpack, it wouldn't allow me to use ES6 CoffeeScript or JS code without using babel to downgrade to ES5 spec. I tried to give it a prebuilt project as input to do its magic, and it gave me a message saying that I should use webpack in order to build the script and not feed it directly a prebuilt script for optimal results. It worked fine but that's too opinionated for my taste.

But the point is, you need a build process when building a complex application aimed for production. You should be able to code at least a couple of npm scripts to do what you want, in case you are too bored to code a complete build process yourself.

But truth be told, if you CANNOT code a build process yourself, maybe you shouldn't be writing complex front-end applications in the first place.

You don't need to learn new terminology and configuration styles every time a new hot tool comes around. That's not your purpose, and surely it's not educational or mind expanding.

I wrote this as part of a larger response on the Medium article itself, but I figured I'd post here as well:

I gotta say though, when people talk the “assembly required” with Gulp, I really don’t think it’s anywhere near as bad as it’s made out to be. I may use ~10–20 very small and easy to use Gulp plugins in anywhere from 8 to 10 simple tasks. Setting up a new Gulpfile takes me all of 15 minutes (far less if I use a template from a previous project) and I get complete control over my build. Additionally, wiring Browserify and Gulp together is extremely easy and straightforward. The config style of Webpack feels a whole lot like Grunt and wow have I seen some nasty Gruntfiles before.

It's like watching a primitive civilization independently re-invent the modern world's technology. This poses ethical questions. Should we have intervened and told them about Maven, when we see them still struggling with their version of Ant?