Echo JS 0.11.0

Why do you need an alternative to browserify ? out of curiosity

Why would one need am alternative browser for IE6 in the 2002. Who needs another MVC framework after backbone was released. Even why browserify was invented after requireJS solved all our problems for client side loading. I don't think that `Why another …` is a good question.

Ok you got me on the wording there, it was more of a question to gain insight to what other people are missing from browserify that say webpack provides. To me, and I have had this conversation with multiple people and substack himself mentions it below, browserify itself or via third party support does everything i need and can do a lot of what webpack does, so again I was looking out of curiosity what I am missing.

My reason to switch to webpack were two things. First the hot plug for react, where you can live reload reactJs components in your app without loosing the app state. The second was the ability to compile an app in to multiple parts for lazy loading. After a discussion here on echojs, I realize that the later is possible in  browserify as well. 

Which points me to my main problem with browserify, the docs. There is the webpage, the github page + wiki and the browserify handbook. Everyone as long markdown files. So if I want to find out the code splitting feature exists, I have to read all of this to find it in the last part of the handbook. So maybe the homepage should provide more information what browserify offers, beside bundling modules to use in the browser.

My impression: it does more than vanilla browserify.

It also has the ability to specify async loading, and can pretty easily chunk up shared js files (such as vendor libs) into one file, while generating another specific js file for each entry-page/page.

Sometimes not doing things is a better approach. In browserify these kinds of features are implemented as third-party plugins (https://github.com/substack/browserify-handbook#partitioning), because that leaves far more room to capture the diversity of approaches. You could use factor-bundle to build the split bundles and place <script> tags or use xhr to load the bundles dynamically or you could use partition-bundle which handles more of that automatically but is harder to customize.

The abstractions are easy to swap out as your requirements change, but you've got to spend more time figuring out which plugin is more fitting.

Yeah - it does feel like browserify follows the unix approach (do one thing, but do it well) and leaves the rest to plugins.

But that's not always a good thing - you now have to find plugins for all your more 'advanced' use-cases. And anyone picking up your work might have to grog your chosen plugins as well. But it is simple.

Personally I still haven't fully decided which to use yet - still in the testing phase.