react-json-view is pretty big

[djsmith42]

In my project, react-json-view is the 3rd largest dependency, as measured by webpack stats. It's 172KB, minified. It's second only to react-bootstrap (459KB) and react-dom (238KB).

I was surprised by this, so I looked into it a bit, and it appears that Radium is 66KB, but I can't find any other explanation for why react-json-view takes 172KB of JS code.

I thought I would log this as a bug just in case there was some accidental oversight, and you didn't realize the project was so big.

Thanks for what you do. My team loves the react-json-view look! It's fantastic.

[mac-s-g]

it's true, the bundle is pretty big. I think it has to do with my webpack config.
I'll continue to investigate and post updates here.

[mac-s-g]

okay, after some analysis, I was able to reduce the build size from ~216kB to ~150kB.

i published to npm version 1.11.9.

I'm gonna close this issue for now because it's not clear to me what (if anything) else needs to be done.

thanks for bringing this up. let me know if you see further room for optimization!

[djsmith42]

With 1.11.9, the size dropped from 172KB to 147KB in my app (15% reduction).

[mac-s-g]

That's kinda strange. I removed Radium altogether.

I'll open this back up and look around at other projects to see what I might be doing differently.

I'm glad you like the component!

thanks for feedback

[mac-s-g]

minor update: got it down to 142kb with build updates in #110 . That will be published shortly. I'm still pretty stumped about why the build is so large.

[djsmith42]

Have you tried using one of the webpack bundle visualization plugins? Might shed some light.

[mac-s-g]

Yes, you can run ./docker/debug.sh from the root to produce a json bundle analysis compatible with most analysis gui's. The file will be saved to /debug/tree.json. I've used that to remove/replace large dependencies where possible. I can't get much further by removing packages.

I'm thinking that a build configuration setting is increasing the bundle output size from webpack. I've added minification and made sure that the environment is set to production. I'm not really sure what else might help.

Alternatively, it could just be that this is a big module. 140kB seems a little high though.

[nicolodavis]

Have you considered exporting an ES module in addition to the minified version in the npm?

Quite separately, I recently switched to Rollup from Webpack in https://github.com/nicolodavis/boardgame.io/blob/master/rollup.npm.js and saw some savings in library size (it may help your project as well).

[mac-s-g]

thanks for the tip @nicolodavis ! I'll look into this as soon as I get a chance. :+1:

[L3tum]

From what I can gather the biggest part of the bundle seems to be Facebook's Flux, right? Maybe dropping that in favor of State/Props would be good

[mac-s-g]

@L3tum you're right on. I need to get that removed. Hopefully I'll get some time in the near future to optimize.

[franklixuefei]

@L3tum @mac-s-g I did a profiling using webpack profile, and the result shows that the whole lib takes up 382kb in stat size, and the largest contributors are lodash.curry, lodash.flow, prop-types, babel-runtime, base16. I guess you can't do anything with babel-runtime, neither much with lodash related packages, because they are internal dependencies. Probably consider knocking out prop-types for production build? Not sure how hard is that.

BTW, flux takes up only 7kb, not a big concern.

[amneacsu]

lodash.curry is being brought in by react-base16-styling.

[mohd-akram]

Could you include src in the npm bundle and set main in package.json to src/js/index.js? This way dependencies aren't duplicated.