Browserify vs. Webpack – Configuration isn't evil

https://medium.com/@housecor/browserify-vs-webpack-b3d7ca08a0a9

by housecor • 11 years ago

46 29 11 years ago

bkurtz13• 11 years ago

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

Offler• 11 years ago

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

lewisl9029• 11 years ago

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.

Confiks• 11 years ago

Thanks for mentioning JSPM/System.js. It's really cool; it runs ES6 compilation with Babel (or Traceur) in the browser, and is able to download arbitrary versions of dependencies off a CDN.

I'm still fiddling a bit with hotloading React and caching source files, but it looks promising.

aroc• 11 years ago

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.

tbolt• 11 years ago

wow, sweet. another entirely new javascript thing

bryanlarsen2• 11 years ago

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

smrq• 11 years ago

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

killercup• 11 years ago

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

mullsork2• 11 years ago

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... :-)

bvanslyke• 11 years ago

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?

serve_yay• 11 years ago

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• 11 years ago

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

danmaz742• 11 years ago

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

timdorr• 11 years ago

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• 11 years ago

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

danmaz742• 11 years ago

Thanks for the suggestion. I'd prefer some more automation, but that's also a possible solution.

thomasfoster962• 11 years ago

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.

mullsork2• 11 years ago

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!

thomasfoster962• 11 years ago

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.

williamcotton• 11 years ago

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• 11 years ago

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.

SandB0x• 11 years ago

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

jamescostian• 11 years ago

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

kentor• 11 years ago

The second syllable is stressed for commodify.

err4nt• 11 years ago

I parse it as Brow-Zurrif-eye

kenOfYugen• 11 years ago

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.

AdrianRossouw• 11 years ago

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/

Browserify vs. Webpack – Configuration isn't evil

Related Stories