Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Browserify vs. Webpack – Configuration isn't evil

medium.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Browserify vs. Webpack – Configuration isn't evil

#11

Post by 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.

Re: Browserify vs. Webpack – Configuration isn't evil

#12

Post by lucisferre »

timdorr wrote: post #10
danmaz74 wrote: post #9

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

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

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

Re: Browserify vs. Webpack – Configuration isn't evil

#13

Post by 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.

Re: Browserify vs. Webpack – Configuration isn't evil

#16

Post by 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.

Re: Browserify vs. Webpack – Configuration isn't evil

#17

Post by smrq »

bryanlarsen wrote: post #5
tbolt wrote: post #4

wow, sweet. another entirely new javascript thing

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

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

Re: Browserify vs. Webpack – Configuration isn't evil

#19

Post by bryanlarsen »

smrq wrote: post #17
bryanlarsen wrote: post #5

Earlier quoted context omitted.

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

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

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

Re: Browserify vs. Webpack – Configuration isn't evil

#20

Post by 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#...

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

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

Post reply on HN