Thoughts on reducing browser bundle size
See original GitHub issueIn my current app simple-peer
is about 10% of an application size and about 20% of JS code size.
Specifically, while index.js
is 29.5KiB and one might expect that minified version would be even smaller, simplepeer.min.js
is whopping 86.5KiB right now.
Before I create and start maintaining a fork of this project, I’d like to know if if this is something that can be fixed upstream.
2 packages that cause this huge size:
readable-stream
buffer
readable-stream
is valuable in Node.js, but not so much in browser environment. Is it possible that future versions of simple-peer
will stop using it entirely and replace with something lightweight instead? I imagine it wouldn’t be too hard to implement a wrapper or even offer an optional one with this library.
buffer
is a simpler one, once readable-stream
is eliminated we’ll just need to switch from Buffer
to Uint8Array
, which is quite easy to do.
Current bundle size doesn’t seem tolerable to me given that it is just a wrapper around native features, so I hope for your understanding here. If these changes seem reasonable, I’d be happy to implement them myself, otherwise I’ll be forced to create something like simple-peer-light
and just maintain that fork forever.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:4
- Comments:21 (3 by maintainers)
Top GitHub Comments
Hi, not directly related but starting from @nazar-pc’s work I made a fork of
simple-peer
which has no external dependencies at all: mitschabaude/simple-peer-lightIt’s on npm as well:
npm install simple-peer-light
. Only works in the browser and does not support the node stream API.The motivation was to be able to use
simple-peer
in a Snowpack app, which relies on rollup which doesn’t manage to bundlereadable-stream
(see https://github.com/nodejs/readable-stream/issues/348). As a nice side-effect I got an 80% size reduction for this lib.I post this just in case it helps someone like myself. Obviously, in this repo you want to support the stream API and @feross knows the way to go.
Thank you all for this excellent library ❤️
Thanks, makes a lot of sense now. In this case I agree it might be a good idea to wait.