175 kb size?

[screendriver]

I added kinto.js to my project (see also #649) as a npm dependency and saw that it increased my final bundle file size about 175 kb in size 😳

Is there anything I can do to reduce it's size? It seems a little bit too large in my eyes compared to other libraries / frameworks.

[Natim]

I guess it depends of how much polyfill you want to have in it.

[leplatrem]

Thanks for the feedback!

I agree that packaging could be improved, especially to get rid of babel from dependencies.

The codebase is not big at all and it only relies on btoa, kinto-http and uuid. I think isomorphic-fetch could be removed too from kinto-http deps too.

And now that modern browsers support natively async/await, the only transformation could be CommonJS modules for browsersify.

I can't spend much time to work on this those days, but we'd be happy to help if you start something in a PR

[screendriver]

I guess it depends of how much polyfill you want to have in it.

That's the point. I think that a library should not contain any polyfills. The consuming environment should make sure that everything is available at runtime. A library should have as few as possible dependencies.

For example In my project I don't include the huge babel-polyfill. I only include the polyfills that I really use (for example core-js/es6/promise and whatwg-fetch).

And now that modern browsers support natively async/await, the only transformation could be CommonJS modules for browsersify.

Thats true. Same here: if the library writes code in the shiny new async and await fashion the consuming project should ensure that everything gets transpiled for older browser (or not if I don't want to)

I try to make a work in progress pull request these days for all that. I hope I've got enough time 😉

[Natim]

I agree with you let's improve that 👍

[leplatrem]

I just released kinto-http.js v3.0 which gets rid of the isomorphic-fetch polyfill

[screendriver]

Oh that was quick 👍

Currently I am thinking about if it would make sense to just publish the "raw" ES2015 code as it's written to npm and not the transpiled one.

Advantages

1. the consuming project has full control over how it gets transpiled (Babel, TypeScript, Webpack, Brunch, Rollup.js, SystemJS and so on)
2. Tree Shaking would then be possible
3. kinto.js shrinks to just a few bytes
4. Debugging with source maps would be much more easier because the module bundler of the consuming project can generate it

Disadvantages

Only one: the consuming project must use a transpiler to use kinto.js

Hmmm... 🤔

[n1k0]

I think we could publish the "src" directory to npm along the "lib" one, so people could build (or import) from sources if they want. Le 9 févr. 2017 12:45 PM, "screendriver" <notifications@github.com> a écrit :

…

Oh that was quick 👍 Currently I am thinking about if it would make sense to just publish the "raw" ES2015 code as it's written to npm and not the transpiled one. Advantages 1. the consuming project has full control over how it gets transpiled (Babel, TypeScript, Webpack, Brunch, Rollup.js, SystemJS and so on) 2. Tree Shaking would then be possible 3. kinto.js shrinks to just a few bytes 4. Debugging with source maps would be much more easier because the module bundler of the consuming project can generate it Disadvantages Only one: the consuming project *must* use a transpiler to use kinto.js Hmmm... 🤔 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#650 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACiSzunNO9cYX0GXm9RNNBQrfYIbRruks5ravxKgaJpZM4L75SI> .

[screendriver]

But when we publish the src directory there are still all requires to Babel related stuff.

At the moment I am searching for best practices / design patterns for library authors that have the same problem like kinto.js.

[dstaley]

With v13, our bundle size has now dropped to ~15 KB gzipped! 🎉