Stacks.js: Reduce blockstack.js dist file size

Created on 13 Dec 2018  路  6Comments  路  Source: blockstack/stacks.js

This issue has been brought up several times in meetings, other issues, and most recently from @tautvilas of https://dpage.io who summarized the issue well:

Blockstack.js when minified is huge - I managed to get it down to 1.4MBs, this is not great for developing decentralized apps for users that have poor internet connection..

bad

  • [x] Use a bundler with module tree-shaking (dead code elimination)
  • [x] ~5 copies of bn.js
  • [x] ~2 copies of secp256k1.js
  • [x] BIP39 Wordlists we don't use
  • [x] Several overlapping / redundant crypto libs that have the same features
  • [ ] Output es6 modules (with side-effect-free importing) -- apps using webpack, rollup, or other smart bundlers will have leaner web pages due to better dead-code elimination.
Epic Impacts DOCS stale

Most helpful comment

Update: as of https://github.com/blockstack/blockstack.js/pull/737 the bundle size is down to less than 600KB.
As far as I can tell, all the low-hanging fruit has been tackled. The next steps involve serious breaking changes:

  1. Refactoring all imports/exports into side-effect-free modules -- allowing this lib and downstream dependencies to take advantage of this: https://github.com/webpack/webpack/tree/master/examples/side-effects
  2. Extract certain dependency-heavy features into separate packages. For example, the transaction related code. This is currently on the roadmap for Stacks v2 related upgrades.

All 6 comments

@yknl @hstove Any thoughts or interest in taking this on? I can probably knock this out pretty quickly unless you had other ideas.

I'm in support of reducing the bundle size by eliminating the redundant code. Is switching to Webpack required to do this? If not, what are the benefits of switching?

Obviously these changes will require lots of testing.

馃憤 We should be very careful with these changes.

Is switching to Webpack required to do this? If not, what are the benefits of switching?

From what I understand (correct me if I'm wrong) by default browserify mostly only translates node.js libraries to be browser friendly by 1) transforming module import/export formats, and 2) shimming out a handful of node.js APIs. While webpack does the above in addition to dead code elimination / tree shaking.

I think that difference is the main reason why blockstack.js bundle is 1.5MB after webpack compared to 3MB from browserify.

It looks like there are plugins to get browserify or possibly babel to do tree shaking but they are less supported/maintained than webpack's builtin support.

If we are going to attempt things like version pinning / swapping and various other tricks to reduce the bundle size, then I think webpack's powerful loaders/rules features and plugin ecosystem will be really helpful.

Update: as of https://github.com/blockstack/blockstack.js/pull/737 the bundle size is down to less than 600KB.
As far as I can tell, all the low-hanging fruit has been tackled. The next steps involve serious breaking changes:

  1. Refactoring all imports/exports into side-effect-free modules -- allowing this lib and downstream dependencies to take advantage of this: https://github.com/webpack/webpack/tree/master/examples/side-effects
  2. Extract certain dependency-heavy features into separate packages. For example, the transaction related code. This is currently on the roadmap for Stacks v2 related upgrades.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically closed. Please reopen if needed.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

muneeb-ali picture muneeb-ali  路  8Comments

pradel picture pradel  路  8Comments

larrysalibra picture larrysalibra  路  6Comments

timstackblock picture timstackblock  路  6Comments

larrysalibra picture larrysalibra  路  8Comments