Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit overhead of adding stream-http to your project #45

Open
pietercolpaert opened this issue Jul 20, 2016 · 2 comments
Open

Limit overhead of adding stream-http to your project #45

pietercolpaert opened this issue Jul 20, 2016 · 2 comments

Comments

@pietercolpaert
Copy link

We're debating whether to use jQuery's ajax call or to use this http plug-in. One good argument from my colleague that would prefer jQuery is that depending on this package comes with an extra 15kb needed to be transferred (gzipped), which would mean an 18% increase in size of the minified gzip of our project.

Could we optimize size here by maybe depending on less big projects in stream-http? Are there quick wins concerning size to be found?

Reference debate: LinkedDataFragments/Client.js@4dc3e19#commitcomment-18326257

pietercolpaert referenced this issue in LinkedDataFragments/Client.js Jul 20, 2016
Adds compatibility with jQuery 3.x.
@jhiesey
Copy link
Owner

jhiesey commented Jul 22, 2016

On the plus side, stream-http only has a few major dependencies: readable-stream and buffer. These in turn depend on a few other things; notably, readable-stream inherits from events.

On the minus side, this module was really written to be used when these are already being pulled in for node compatibility, and I haven't really given much thought to how to remove them.

Depending on what browsers you want to support, it might or might not be reasonable to do this. For example, if every target browser supports Uint8Array, you could replace buffer with a pretty minimal wrapper around that. (incidentally, a major goal of this library is providing an 8-bit-clean, binary compatible interface, which is why strings aren't used). stream-http also doesn't use much of the stream functionality, so a pretty simple implementation could probably make this library work.

In other words, you may be able to write very minimal versions of the dependencies to get stream-http working, but this library wasn't built with that in mind and this depends on browser support, so YMMV.

@ariutta
Copy link

ariutta commented Jul 30, 2016

Wow, it looks like readable-stream and buffer bundled and minified come in at 80K, and the entire stream-http library comes in at just 89K!

If anyone's interested, I got the web-streams-polyfill library down to 47K, and it takes care of buffers and streaming. The web-streams-polyfill is a bundled implementation of the web streams standard. It basically just turns the reference implementation into an npm package. To reduce size further, the first place to look would be dropping code from readable-stream.js.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants