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).
Browserify vs. Webpack – Configuration isn't evil
21–30 of 32 posts
Re: Browserify vs. Webpack – Configuration isn't evil
#22I 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.
Re: Browserify vs. Webpack – Configuration isn't evil
#23Am I the only one to find the word "Browserify" intensely annoying? Which syllable is stressed?
Re: Browserify vs. Webpack – Configuration isn't evil
#24I'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…
Re: Browserify vs. Webpack – Configuration isn't evil
#25All 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…
Re: Browserify vs. Webpack – Configuration isn't evil
#26Re: Browserify vs. Webpack – Configuration isn't evil
#27As 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
Re: Browserify vs. Webpack – Configuration isn't evil
#28As 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
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
#29As 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.
So you don't need to bet on any particular ecosystem.
Re: Browserify vs. Webpack – Configuration isn't evil
#30Any 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.