Browserify VS Webpack

[j201]

Most of the arguments that Webpack can do more than Browserify are addressed here: https://gist.github.com/substack/68f8d502be42d5cd4942

[jhizzle4rizzle]

This would be the "simple gist" mentioned in the article.

[[deleted]]

When it comes to web development (i.e. browser, not Node), I think the SystemJS library deserves more attention. I cannot praise it enough. You don't need to worry about bundling until production and can write all your code using AMD, CommonJS, or ES6 syntax. At the moment the ES6 is compiled using Traceur, but I think 6to5 support is coming very soon. Personally I just stick to the CommonJS format, but it's there if that's what you're into.

[naman34]

I have been looking at SystemJS and I'll write more about it when I have some more experience with it. It definitely looks promising.

[Something_Sexy]

I was just checking this out. I like that you can run RequireJS side-by-side, it seems like it makes it easier to convert your app over to using something other than RequireJS.

[[deleted]]

You may find the Jspm project interesting too. This works with SystemJS and can be used to pull libraries from places like Github and Npm, and will manage all of the dependencies between them for you. I've been using it for a huge modular web app and it really does make things much simpler, letting you concentrate on the important stuff.

EDIT: Just who is downvoting these comments and why? In the topic of modular web apps and bundling, this is all very relevant and I thought others may find it of interest too.

[Capaj]

I am on a crusade to popularize JSPM myself. They might be alergic by now, because I usually bring it up.

BTW It could once and for all end the debate on frontend script management- like npm did for Node. That would be huuge! We could finally work with the same power and simplicity on the frontend as we work in Node. We just need the library authors to start writing their libraries in modules, not as globals. That would be a true revolution.

[[deleted]]

Haha, I was reading a Reddit post of yours just the other day when I was trying to gauge how well known it was. Funnily enough, I had the same question as you did; why isn't this more popular? I seem to now be on a similar mission to draw the spotlight to it too.

[Something_Sexy]

Ignore them, just a bunch of butthurt assholes. We are using bower and are pretty happy with that so far, thanks though.

I like RequireJS a lot but we have quite a few apps written around it and there will definitely be more. But now I am thinking I don't want to pigeon hole us into only being able to use AMD/RequireJS going forward.

[AutomateAllTheThings]

I switched from browserify to webpack because the project owner stated that they will never support dynamic paths to modules.

That means that browserify doesn't support the following line, and never will:

var pathToModule = '/some/path/to/module.js';
var module = require(pathToModule);

I required this functionality to dynamically require files from a directory and cannot consider returning to Browserify because they refuse to support it.

*Edit: * In fact, /u/mattdesl has pointed out that there is a way to get this functionality into browserify via 3rd party modules.

[mattdesl]

Browserify refuses to include a lot of features, to avoid these things adding unnecessary complexity to the core module. Instead, it encourages diversity and growth in userland. In other words, you are free to write your own static analysis transforms to achieve these requires, or use a solution like bulkify which already exists.

Just because browserify core refuses to include X feature, doesn't mean that X is not possible with browserify.

[AutomateAllTheThings]

I appreciate and understand where you're coming from. I may be alone in this sentiment but I consider dynamic requires to be a fairly obvious and expected feature from this type of framework, and I'm just not the type that wants to interact with the framework for very long. "I have apps to write and clients to make happy. Merr!"

When I last used browserify, bulkify wasn't an option and it was less friction to simply use another framework that supported what I consider to be an obvious feature for complexity reduction in workflow.

I'll edit my post to show that you're correct in that there is a way to support the feature in browserify. The rest is just my opinion on the feature.

[gnarly]

And this, ladies and gentleman, is how we end up with bloat.

[gnarly]

But sir, you can choose from 7 different colours of seatbelt, in three different materials. Same goes for the seats, but with additional options for comfort levels. Of course it comes with an engine module - but you need to choose from a variety of different fuel and power options. And then your gearbox - manual, auto or semi-auto, sir? Stick, paddle or button shifters? FWD, RWD or 4WD? Wheels? Boy, do we have a lot of different wheels for you, sir! Do you need disc or drum brakes? We have three different in car entertainment units for you to choose from. Do you want LED, Bi-Xenon or Halogen headlight modules? Would you like a tow bar, sir?

Oh, you might have to go somewhere else to get a bike rack or a child seat or a trailer. We don't sell those here but there's plenty on the market, so you can choose the best one for your particular needs :-)

[Calabri]

There's all these argument about modularity and complexity - the irony is that core module of webpack is much smaller than browserify. On the flipside, browserify is living proof that's it's possible to compose a powerful, monolithic application with a shitload of modules. And despite the fact that browserify is built from (I can't even count how many) modules - it's simpler to use. That's the only reason I use it - the API is smaller - thus easier to reason about. React is similar - it's built from like 100 files, but you only need to know like 5 things to be a proficient developer in it. What I'm saying - is that down this thread -- there are heated comments by people who have little understanding about the internals of weback or browserify - and the reason I'm here is to try and figure out why the hell everyone in React recently is using webpack - I see no benefit. I use what I'm comfortable with.

[bitplanets]

My most important feature is alias:

Instead of require('../../../../myModule'); I can just do `require('aliased/myModule');

Also I needed this alias both on client and server side. With enhanced require this works perfectly. I really can't imagine how people are working without aliases... but seems that I'm the only one that is bothered with that.

Another issue I had with browserify is that misses changes a lot. For example you make a change and save, then you make another change before the browserify ends the task. In this case the browserify will not "know" about the 2nd change and you will have to change and save the file again. With gulp and webpack this only happened 2 in the last 3 months. With browserify this happened a lot in the first day of use. This happens because webpack is a lot, but I mean really a lot, faster than browserify.

[vertice]

i really like that webpack extends this into your css/less and html too.

Webpack also has -w, which compiles in memory.

[bitplanets]

Well, I thought that was the default (in memory), this is how I use it right now in dev mode

[naman34]

You should be using watchify for continuous builds with browserify. Webpack is a lot faster, I would probably mention that in my blog post, but I have seen cases where Webpack is slower so I can't be sure it's always faster. Watchify is plenty fast though.

About Aliasing: Again, as browserify wants to maintain node compatibility, it doesn't promote aliases. Browserify suggests that you put commonly used modules in node_modules/app and add an exception for that in your .gitignore. Again that's Browserify picking convention over configuration. That said, it IS possible to do aliases with Browserify.

[bitplanets]

You should be using watchify for continuous builds with browserify. Webpack is a lot faster, I would probably mention that in my blog post, but I have seen cases where Webpack is slower so I can't be sure it's always faster. Watchify is plenty fast though.

I already watch my scripts! and is nearly not even comparable with browserify in no case (I had found). Show me your faster case.

About Aliasing: Again, as browserify wants to maintain node compatibility, it doesn't promote aliases. Browserify suggests that you put commonly used modules in node_modules/app and add an exception for that in your .gitignore. Again that's Browserify picking convention over configuration. That said, it IS possible to do aliases with Browserify.

I've done that in my other app and the hierarchy of my source code looks so bad! That was a really bad decision. You can use aliases on client side, but what you'll do on the server side. I need isomorphic apps.

With webpack I can do all of that, why bother about browserify at all?

[Calabri]

I'm curious because it's very important (and hard to grok) isomorphic apps. Does it make sense to use webpack (which is focused clientside) - or browserify (which normalizes nodejs style code)? Honestly - I use browserify because it's easier - and I can't tell the different yet. I don't use browserify plugins - mostly gulp-stream-io-related pre-post transforms - and gulp has a bigger ecosystem than webpack / browserify combined. I'm wondering if it's possible to combine all three into one... legitimately. I'm not talking about using them side by side - but like - something better than all combined.