3 ms·

I think the author oversimplified the choice of Browserify and RequireJS. They have some overlap, but are not 100% replacements. Both have the concept of modul

I think the author oversimplified the choice of Browserify and RequireJS. They have some overlap, but are not 100% replacements. Both have the concept of modules, and they overlap in this area. Browserify allows you to use Node style modules in the browser. RequireJS allows you to asynchronously load parts of your app, while Browserify bundles all JS into a single file.

cheapsteak 13y ago
To further clarify, RequireJS also allows you to bundle all JS into a single file via the r.js build step. If you're planning on going that route with RequireJS, you should also look into AlmondJS: https://github.com/jrburke/almond https://github.com/jrburke/almond
- STRML 13y ago
  If you do end up using RequireJS, using r.js is practically a requirement. Declaring asynchronous dependencies in a production build is murder for performance. Grunt's grunt-contrib-requirejs[1] does a good job of traversing your dependency graph with r.js and building out a single bundle, but it is not especially quick; it takes about a full 3-5s on my current build. But it's a hell of a lot better than the alternative. Of course, if I were to start over, I'd run browserify and either build the files in a build step with Grunt or Gulp, or just use browserify-middleware[2] and skip the build step entirely (with something like node-sass for styles). [1] https://github.com/gruntjs/grunt-contrib-requirejs https://github.com/gruntjs/grunt-contrib-requirejs [2] https://github.com/ForbesLindesay/browserify-middleware https://github.com/ForbesLindesay/browserify-middleware
  - leobelle 13y ago
    Well you are right for most front-end application, but what is nice to have is modules, and you don't want almond for that. And by modules I mean you have major pieces of application code that you don't want to load until the user triggers an intent to need that stuff. If you have a single page application and most of your users are just consuming content, why load all the config and editing tool JavaScript? Make modules for pieces of your app, and then if needed load the JavaScript for those things. User clicked edit? Ok now load the JavaScript for that stuff. Browser caching is nice, but if you're doing a continuous integration/deployment type, you're probably invalidating your cache often. If you use a single build you may be invalidating all of your JavaScript for each tiny deploy even though maybe 1% of your JavaScript changed. Another reason to want modules. I don't know if Browserify can do that.
moystard 13y ago
I don't know have experience with Browserify, but if it does not support modular architecture, then it's more a regression in comparison with Require.js Using the r.js optimiser, we are able to create several modules for our SPA that include logic and templates, and load them at runtime only when required. By default, we load the most used bits of our application, and load the rest when the user accesses the more rarely used views.

cheapsteak 13y ago

To further clarify, RequireJS also allows you to bundle all JS into a single file via the r.js build step. If you're planning on going that route with RequireJS, you should also look into AlmondJS: https://github.com/jrburke/almond https://github.com/jrburke/almond

STRML 13y ago
If you do end up using RequireJS, using r.js is practically a requirement. Declaring asynchronous dependencies in a production build is murder for performance. Grunt's grunt-contrib-requirejs[1] does a good job of traversing your dependency graph with r.js and building out a single bundle, but it is not especially quick; it takes about a full 3-5s on my current build. But it's a hell of a lot better than the alternative. Of course, if I were to start over, I'd run browserify and either build the files in a build step with Grunt or Gulp, or just use browserify-middleware[2] and skip the build step entirely (with something like node-sass for styles). [1] https://github.com/gruntjs/grunt-contrib-requirejs https://github.com/gruntjs/grunt-contrib-requirejs [2] https://github.com/ForbesLindesay/browserify-middleware https://github.com/ForbesLindesay/browserify-middleware
- leobelle 13y ago
  Well you are right for most front-end application, but what is nice to have is modules, and you don't want almond for that. And by modules I mean you have major pieces of application code that you don't want to load until the user triggers an intent to need that stuff. If you have a single page application and most of your users are just consuming content, why load all the config and editing tool JavaScript? Make modules for pieces of your app, and then if needed load the JavaScript for those things. User clicked edit? Ok now load the JavaScript for that stuff. Browser caching is nice, but if you're doing a continuous integration/deployment type, you're probably invalidating your cache often. If you use a single build you may be invalidating all of your JavaScript for each tiny deploy even though maybe 1% of your JavaScript changed. Another reason to want modules. I don't know if Browserify can do that.

moystard 13y ago

I don't know have experience with Browserify, but if it does not support modular architecture, then it's more a regression in comparison with Require.js Using the r.js optimiser, we are able to create several modules for our SPA that include logic and templates, and load them at runtime only when required. By default, we load the most used bits of our application, and load the rest when the user accesses the more rarely used views.