Live data from Hacker News

Browserify vs. Webpack – Configuration isn't evil

medium.com

21–30 of 32 posts

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

#21
post #10
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).

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

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

#22

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.

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

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

#24

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 a…

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

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

#25

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. Ugl…

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!

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

#26
post #14

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

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

The second syllable is stressed for commodify.

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

#27
post #2

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

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

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

#28
post #2

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

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.

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

#29
post #27
post #2

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

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

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.

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

#30

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.

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.
Post reply on HN