Browserify vs. Webpack – Configuration isn't evil
1–10 of 32 posts
Re: Browserify vs. Webpack – Configuration isn't evil
#2As 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
#3I 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.
Re: Browserify vs. Webpack – Configuration isn't evil
#4wow, sweet. another entirely new javascript thing
Re: Browserify vs. Webpack – Configuration isn't evil
#5wow, 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.
Re: Browserify vs. Webpack – Configuration isn't evil
#6I'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
Re: Browserify vs. Webpack – Configuration isn't evil
#7It'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?
Re: Browserify vs. Webpack – Configuration isn't evil
#8I 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
#9A 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
Re: Browserify vs. Webpack – Configuration isn't evil
#10A 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).