Generated bundle size

Rails react_on_rails
1

I’m new to react_on_rails, and also babel (and react!) so I may have some misperceptions about how this all fits together, but it seems like the code bundles generated by react_on_rails are much larger than i would have expected. I have very little app js code, and no libraries other than the ones included with react_on_rails (plus Redux, no bootstrap).

The dev bundles come to 3.5 megs for app-bundle.self and 1.5 megs for vendor-bundle.self.

The production bundle comes to ~1.5 megs for app-bundle and 555 kb for vendor-bundle.

Is this to be expected? These values seem very large.

Screen Shot 2016-02-15 at 7.01.52 PM.png1946×428 83.8 KB

2

There’s some things we know we need to do get the bundle sizes down.

  1. https://github.com/shakacode/react_on_rails/issues/206
  2. http://www.2ality.com/2015/12/webpack-tree-shaking.html

If you can try these out and report back, that would be super helpful!

3

Another related issue:

4

Thanks for the response and links, Justin.

I tried both the tree-shaking plugins and lodash plugin and did not see any reductions in generated code size (though I may have done something incorrectly, due to lack of experience with babel and webpack).

Here’s the code from my altered webpack.client.rails.config.js:

config.module.loaders.push(
  {
    test: /\.jsx?$/,
    loader: 'babel-loader',
    exclude: /node_modules/,
    query: {
        plugins: [
          'lodash'
          'transform-es2015-template-literals',
            'transform-es2015-literals',
            'transform-es2015-function-name',
            'transform-es2015-arrow-functions',
            'transform-es2015-block-scoped-functions',
            'transform-es2015-classes',
            'transform-es2015-object-super',
            'transform-es2015-shorthand-properties',
            'transform-es2015-computed-properties',
            'transform-es2015-for-of',
            'transform-es2015-sticky-regex',
            'transform-es2015-unicode-regex',
            'check-es2015-constants',
            'transform-es2015-spread',
            'transform-es2015-parameters',
            'transform-es2015-destructuring',
            'transform-es2015-block-scoping',
            'transform-es2015-typeof-symbol',
            ['transform-regenerator', { async: false, asyncGenerators: false }]
        ]
    }
  },
  {
    test: require.resolve('react'),
    loader: 'imports?shim=es5-shim/es5-shim&sham=es5-shim/es5-sham',
  },
  {
    test: require.resolve('jquery-ujs'),
    loader: 'imports?jQuery=jquery',
  }
);

Removing the sample HelloWorld app resulted in some significant size reductions, though the bundles are still very large (see attached).

Screen Shot 2016-02-16 at 11.58.15 PM.png2016×516 109 KB

1.9 MB for app, and 1.5 MB for vendor. With a minified production build, these numbers shrink further to a combined total of about 707 KB and 567 KB, respectively. Are these numbers normal? They still seem extremely high. For example, the company I work for uses ExtJs (a very large js framework) and we have 1000s of LOC of our own app code, and it totals out at less than this combined total of ~1.2 MB.

Thanks for your assistance here. There are some things I really like about react_on_rails vs react-rails, so it would be a shame to have switch back (or go some other route entirely), but these js bundle sizes are a deal-breaker for me.

5

@lukeasrodgers, both react-rails and react_on_rails depend on React. You’re probably accidentally including extra things in your deployment with webpack. Or maybe you’re not noticing how much react takes in your current react-rails.

A more productive experiment would be to create a PR here https://github.com/shakacode/react-webpack-rails-tutorial that implements the tree shaking and lodash shrinking. Then we should compare before and after.

If you do that, my team will ensure that we’re doing this code size minimizing properly. These things always take a little patience.

6

Thanks, I agree it is likely I’m accidentally including (or perhaps duplicating) some code somewhere. I’ll look opening a PR on that repo, cheers.