Performance

[cymen]

So we have performance issues sometimes. I want things to work faster locally and I am seeing some potential areas to make things faster:

• when source maps are enabled, everything gets source maps including node_modules -- I could live without source maps for node_modules by default with option to turn them on
• browserify supports a noparse option -- configuring it manually is annoying but automating it seems risky too -- potentially, we could do a noparse if we had a cache that told us if a file was CommonJS or not (if it needed to be browserified)
• browserify has a --fast option -- it would be good to know if

For caching, we need something in memory (or in filesystem, I'd prefer memory). That cache would need the last modified time for a file along with other things. This would only be present for development -- in production with Rails, the assets are precompiled so browserify-rails should never need to be running in production (which frees us up on how we implement this quite a bit, let me know if my assumptions are wrong here).

This isn't comprehensive but I want to get the conversation going and see if anyone else is thinking about this (I know @gabrielecirulli is -- thanks to him, browserify-incremental is in with #35).

[cymen]

Could do noparse on everything in vendor/bundle.

[cymen]

Actually, for vendor/bundle, makes more sense to just have option to ignore it -- so browserify-rails just opts out on it (configured behavior I guess).

[gabrielecirulli]

For what I could tell, --fast doesn't seem to produce measurable improvements on big codebases. That's probably because --fast just skips some basic checks which aren't actually the bottleneck, and it makes insertions in the bundle under the assumption requires some extra system dependencies. Those probably happen anyway when your codebase gets big enough.

[gabrielecirulli]

So basically you would just have an ignore_vendor_assets option for browserify-rails? That might actually make sense too, I can't think of many other places where a more granular ignore option would come handy.

[andreasheim]

We are trying to use browserify-rails to convert our existing app from using google closure to manage our dependencies. The app is a fairly decent size, so we can't do it all at once.

We have a a couple problems - mostly performance related:

• it takes a very long time to compile application.js - 6-7 minutes vs. 5-6 seconds without browserify. I'd like to --noparse application.js since it doesn't have any direct require calls.
• compress currently fails when doing a precompile. It runs fine when I run UglfierJS directly. I have a hunch that browserify-rails tries to run yet again on the compressed file.
• browserify-rails messes up some of our handlebars templates that we pull in via handlebars_assets. Any html form element that includes a required attribute triggers the inclusion the browserify-wrapper. For one, it looks like it should look for require( calls, not just any require fragment. However I'd also like to be able to exclude our templates folder altogether.

[cymen]

@andreasheim It would be interesting to know more about the precompile issue. I haven't seen that yet. I did have problems on projects upgraded from Rails 3 to 4 in that one know has to be have more explicit configuration for the JS compressor (config.assets.js_compressor = :uglifier).

The other two issues are definitely understandable. The detection of when to use browserify is not very robust or exact. It is going to need tweaks for ES6 (import, etc). It would be great to both make it more robust and address your first issue (having an ignore list so one can explicitly configure files to not browserify).

[cymen]

One note about performance: I was working on a big project in which part of the JavaScript code base was using CommonJS (via browserify-rails) and another big part was not. We thought browserify-rails was causing major performance issues but it turned out the non-CommonJS JavaScript had grown in size to hundreds of files and the Rails way of not bundling those files was causing massive slowdowns in development (like 12 seconds for page loads -- after excluding those, down to second or two).

Just a warning to anyone who might be working on a similar project.

[andreasheim]

@cymen Thanks for the response. I should have clarified - this is a Rails 3 project.

Regarding performance - since we're just trying to introduce browserify-rails, we're coming from the other end. It works fine until we drop it in. Yes, it slows down the processing of non-Common-JS files. Like your case, that's hundreds of files. We want to convert them over a relatively short period of time, but want to avoid having to do it all at once. It's incredibly difficult to pull that off.

[cymen]

@andreasheim Ah! That is good to know. Would configuring browserify-rails to only run on a given set of files or file globs suit your workflow? I think if that was possible, it would avoid the performance hit.

I would like to keep browserify-rails working well for your exact usage -- I think it makes sense for two major usages:

• a path to get the code to CommonJS
• an easy way to start using CommonJS

In either case, the need might arise for having multiple bundles and then it starts to get more complicated and browserify-rails may or may not be the right choice. But I would like to keep the two major usages above working well.

[ciaoben]

I was trying the gem, and I was wondering if I am missing, or doing something wrong, but it seems non-usable to me:

I've only 2 deps for now: martyjs and react.

application.js:

...
//= require turbolinks
var Marty = require("marty");
console.log(Marty);

I refresh the browser, and it makes 30 secs to bundle up everything, and its good for the first time.

Then I refresh after simply having added a ´console.log("hi");´ and it takes again the same time that it takes the first time.

If I have understood correctly, with browserify incremental this time should have evaluated only the new line. But performace doesn't say so.

Am I wrong?

[gabrielecirulli]

Have you tried using the "config.browserify_rails.use_browserifyinc = true" option in your application.rb?

On 05 Jun 2015, at 20:20, Cymen Vig notifications@github.com wrote:

@andreasheim Ah! That is good to know. Would configuring browserify-rails to only run on a given set of files or file globs suit your workflow? I think if that was possible, it would avoid the performance hit.

I would like to keep browserify-rails working well for your exact usage -- I think it makes sense for two major usages:

a path to get the code to CommonJS
an easy way to start using CommonJS
In either case, the need might arise for having multiple bundles and then it starts to get more complicated and browserify-rails may or may not be the right choice. But I would like to keep the two major usages above working well.

—
Reply to this email directly or view it on GitHub.

[ciaoben]

@gabrielecirulli I didn't know it existence. Where can I find it?

Anyway, I have tried it, thing doesn't change!

I have tried to use browserify-increment as a JS with npm, ant it is blazing fast. After the first bunlde, the average is ~1 sec.
With this gem, the same changes are all ~ 30 secs

[cymen]

@ciaoben Have you tried splitting your sprockets requires out into a separate bundle to see if that is it? In other words, have an a.js with the sprocket requires (//=) and another (say b.js) with CommonJS and include both pages in your page?

[ciaoben]

@cymen it is the same. I can't notice any difference

[gabrielecirulli]

Sorry, I forgot an important step, please run "npm install browserify-incremental". I think browserify-rails just defaults to vanilla browserify if you don't have it installed.

On 21 Jun 2015, at 13:15, Nicolò Benigni notifications@github.com wrote:

@cymen it is the same. I can't notice any difference

—
Reply to this email directly or view it on GitHub.