-
Notifications
You must be signed in to change notification settings - Fork 62
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
Comments
Adds compatibility with jQuery 3.x.
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. |
Wow, it looks like 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. |
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
The text was updated successfully, but these errors were encountered: