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

Let default file for browsers be minified for bundlers and services relying on npm #3870

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@mathiasrw

mathiasrw commented Dec 3, 2017

When serving to browsers the default file should (as default) be minified. It, therefore, makes sense to use the browser field (see specs) in package.json to indicate that jquery.min.js should be the default choice when targeting browsers for bundlers or services relying on jQuery from npm.

Example: At the moment including something like <script src="//unpkg.com/jquery"></script> on your website will fetch the original JS. With this PR the minified file will be served. For version 3.2.1 that represents going from 268.039 bytes to 86.659 bytes. Sure, I can just change the script to <script src="//unpkg.com/jquery@3/dist/jquery.min.js"></script>. I will argue that too many people are too lazy (or does not know better) to care about the extra 181.380 bytes this will add to the load for each person fetching the file.

Checklist


This change is Reviewable

Let default browser file be the minified
When serving to browsers the default file should be the minified one.
@roblarsen

This comment has been minimized.

Show comment
Hide comment
@roblarsen

roblarsen Dec 3, 2017

I will argue that too many people are too lazy (or does not know better) to care about the extra 181.380 bytes this will add to the load for each person fetching the file.

The current Nobel Prize in economics backs you up on this argument.

roblarsen commented Dec 3, 2017

I will argue that too many people are too lazy (or does not know better) to care about the extra 181.380 bytes this will add to the load for each person fetching the file.

The current Nobel Prize in economics backs you up on this argument.

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Dec 4, 2017

Member

There's a tradeoff between default-debuggable and default-performant here. Which is most typically needed by someone using unpkg? I'd think it's the former.

Member

dmethvin commented Dec 4, 2017

There's a tradeoff between default-debuggable and default-performant here. Which is most typically needed by someone using unpkg? I'd think it's the former.

@mathiasrw

This comment has been minimized.

Show comment
Hide comment
@mathiasrw

mathiasrw Dec 5, 2017

Indeed, I agree about this being a tradeoff.

When I look for references and posts about how / why unpkg is used it looks like a term "default-performant CDN" best describe how the benefits of unpkg is conveyed.

Like in https://metafizzy.co/blog/switching-out-cdnjs-for-unpkg/

CDNJS was created in a previous era, before semver, before npm. It could never completely graduate from it.

The beauty of unpkg is that it requires no additional work for a library author to maintain. If your project is on npm, it's already on unpkg.

And in https://york.io/2016/11/30/unpkg-npm-cdn-assets.html

Now we can stop the deadly sin of committing our assets to git for Bower, CDNJS, and jsDelivr. Instead let’s use unpkg, a CDN for npm.

It’s simple and beautiful. unpkg is now my preferred CDN.

I will leave this open for a few more days to see if others have inputs on this matter. If no further arguments are presented I will close the PR.

mathiasrw commented Dec 5, 2017

Indeed, I agree about this being a tradeoff.

When I look for references and posts about how / why unpkg is used it looks like a term "default-performant CDN" best describe how the benefits of unpkg is conveyed.

Like in https://metafizzy.co/blog/switching-out-cdnjs-for-unpkg/

CDNJS was created in a previous era, before semver, before npm. It could never completely graduate from it.

The beauty of unpkg is that it requires no additional work for a library author to maintain. If your project is on npm, it's already on unpkg.

And in https://york.io/2016/11/30/unpkg-npm-cdn-assets.html

Now we can stop the deadly sin of committing our assets to git for Bower, CDNJS, and jsDelivr. Instead let’s use unpkg, a CDN for npm.

It’s simple and beautiful. unpkg is now my preferred CDN.

I will leave this open for a few more days to see if others have inputs on this matter. If no further arguments are presented I will close the PR.

@timmywil

This comment has been minimized.

Show comment
Hide comment
@timmywil

timmywil Dec 5, 2017

Member

unpkg looks like a great tool for getting something up and running quickly. But however fast it may be, I think there are better options for serving files in production if for no other reason than they cannot provide uptime guarantees. unpkg admits this on their about page:

However, if you rely on it to serve files that are crucial to your business, you should probably pay for a host with well-supported infrastructure and uptime guarantees.

In light of this, I lean towards default-debuggable, as that seems to be closer to the intended usage of unpkg.

It's also a great resource for people creating demos and instructional material.

Member

timmywil commented Dec 5, 2017

unpkg looks like a great tool for getting something up and running quickly. But however fast it may be, I think there are better options for serving files in production if for no other reason than they cannot provide uptime guarantees. unpkg admits this on their about page:

However, if you rely on it to serve files that are crucial to your business, you should probably pay for a host with well-supported infrastructure and uptime guarantees.

In light of this, I lean towards default-debuggable, as that seems to be closer to the intended usage of unpkg.

It's also a great resource for people creating demos and instructional material.

@mathiasrw mathiasrw closed this Dec 6, 2017

@mathiasrw

This comment has been minimized.

Show comment
Hide comment
@mathiasrw

mathiasrw Dec 6, 2017

In that light it makes sense. Thank you for taking the time for good dialogue.

mathiasrw commented Dec 6, 2017

In that light it makes sense. Thank you for taking the time for good dialogue.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 17, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.