
Browserify vs. Webpack – Configuration isn't evil - housecor
https://medium.com/@housecor/browserify-vs-webpack-b3d7ca08a0a9
======
killercup
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](https://www.npmjs.com/package/interpret)
[2]: [https://www.npmjs.com/package/webpack-
merge](https://www.npmjs.com/package/webpack-merge)

~~~
mullsork
I consider makefiles a skill as well, as I never learned to write them.
Perhaps I never learnt bash. Takes me back to my C/C++ days fighting the build
system whenever I didn't use an IDE! I didn't get very far... :-)

------
bkurtz13
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](http://jspm.io) [2]
[https://www.youtube.com/watch?v=iukBMY4apvI](https://www.youtube.com/watch?v=iukBMY4apvI)

~~~
Offler
npm is getting its house in order when it comes to browser package management.
I wouldn't bet too heavily on something else.

~~~
lewisl9029
JSPM has fairly seamless support for loading libraries from npm, Github, local
Git repos in any format (global, CJS, AMD, ES6) as ES6 modules.

So you don't need to _bet_ on any particular ecosystem.

------
AdrianRossouw
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#...](https://github.com/jnordberg/coffeeify/blob/master/index.js#L5-L11)

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

[http://adrianrossouw.github.io/webpack-mostly-just-
works/](http://adrianrossouw.github.io/webpack-mostly-just-works/)

------
thomasfoster96
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.

~~~
mullsork
I too am leaning towards converting our ugly gulp directory into npm scripts.
I'm though less sure about how to handle replacing relative image paths in CSS
& JS with ones on cloudfront. Have you dealt with things like these? Would
love to see how!

~~~
thomasfoster96
I haven't deal with things like that - though it must be a common problem so
I'd assume there's a tool somewhere to do it.

------
kenOfYugen
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.

------
aroc
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.

------
serve_yay
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.

~~~
seba_dos1
Even more - such job can be perfectly handled by a Makefile.

------
williamcotton
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.

~~~
dtothefp
Hat's off to whoever is a big enough hipster to write a Makefile that creates
a dependency graph, chunks out common modules while creating multiple bundles,
shims non AMD/Common JS dependencies, injects external dependencies, and
watches/livereloads only updated chunks...etc. Also, try to do half of that in
Browserify and you will probably be better off doing the Makefile approach.

------
danmaz74
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](https://github.com/danott/webpack_rails)

~~~
timdorr
Your best bet is no integration at all. Just set up webpack to read from
./app/assets and output to ./public. Run it separately, preferable with a
foreman Procfile for development (I've used Procfile.dev before).

~~~
lucisferre
You'll still likely want digested assets that integrate with Rails asset
helpers. This has been done with Gulp[1] if that helps at all.

[1]: [http://viget.com/extend/gulp-rails-asset-
pipeline](http://viget.com/extend/gulp-rails-asset-pipeline)

------
bvanslyke
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?

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

~~~
jamescostian
Just like the word commodify, I stress the first syllable and assume that most
people do the same

~~~
kentor
The second syllable is stressed for commodify.

------
tbolt
wow, sweet. another entirely new javascript thing

~~~
bryanlarsen
One new thing that replaces two (or more) old things, so that's progress.
webpack replaces both browserify & gulp/grunt.

~~~
smrq
Well, until you have any tasks other than bundling assets, and need a task
runner again.

~~~
bryanlarsen
NPM works fine as a simple task runner, and you're probably already using that
as well.

