jQuery CDN having SSL issues

Post by zackbloom » Thu, Apr 19, 2018, 9:19 PM UTC

keane wrote: post #20

Original, jQuery CDN: https://code.jquery.com/jquery-X.Y.Z.min.js Google: https://ajax.googleapis.com/ajax/libs/jquery/X.Y.Z/jquery.min.js Microsoft: https://ajax.microsoft.com/ajax/jquery/jquery-X.Y.Z.min.js Microsoft ASP.NET: https://ajax.aspnetcdn.com/ajax/jquery/jquery-X.Y.Z.min.js jsDelivr: https://cdn.jsdelivr.net/npm/jquery@X.Y.Z/dist/jquery.min.js cdnjs: https://cdnjs.cloudflare.com/ajax/libs/jquery/X.Y.Z/jqu…

Post by robin_reala » Thu, Apr 19, 2018, 9:21 PM UTC

penagwin wrote: post #22

jakobdabo wrote: post #15

I always self-host my JS/CSS libraries: the connection is already open (thanks to keep-alive) so what's the problem of serving a couple of more KiBs of compressed data instead of making an additional DNS request and a new connection to a CDN? I understand that the CDN version of the library may have already been cached by the browser while visiting other websites, but does it really save that much time/traffic compar…

I'm not taking a side, just trying to add some numbers. Let's ignore the privacy/uptime concerns for the sake of this comment. If every site you visit has 350kb of stuff that would benefit from a CDN JS but also some CSS and fonts (google fonts, bootstrap, etc.) If you visit 50 pages a day in a 30 day month, that's a little over 500mb of data. .35mb x 50sites x 30days = 525mb That would be a ton of easily avoidable d…

Post by 2trill2spill » Thu, Apr 19, 2018, 9:34 PM UTC

luhn wrote: post #27

2trill2spill wrote: post #23

Earlier quoted context omitted.

> Nowadays, with all the Node.js stuff that goes around modern front-end, I don't see the point of embedding a JavaScript library from a CDN, unless that library is dependent on a remote service, e.g. Google Analytics, Google Maps, etc… That being said, if you are still maintaining a legacy website that depends on jQuery, you should consider to embed the library like this instead: What does Node.js have to do with de…

I assume he's talking about NPM. Now that everybody's hot new SPA has a few hundred thousand NPM dependencies, you roll it all up using Webpack and can just as easily `npm install jquery` as ` `.

Post by keane » Thu, Apr 19, 2018, 9:54 PM UTC

zackbloom wrote: post #32

keane wrote: post #20

Original, jQuery CDN: https://code.jquery.com/jquery-X.Y.Z.min.js Google: https://ajax.googleapis.com/ajax/libs/jquery/X.Y.Z/jquery.min.js Microsoft: https://ajax.microsoft.com/ajax/jquery/jquery-X.Y.Z.min.js Microsoft ASP.NET: https://ajax.aspnetcdn.com/ajax/jquery/jquery-X.Y.Z.min.js jsDelivr: https://cdn.jsdelivr.net/npm/jquery@X.Y.Z/dist/jquery.min.js cdnjs: https://cdnjs.cloudflare.com/ajax/libs/jquery/X.Y.Z/jqu…

Does anyone have a performance benchmark comparing them?

Post by madeofpalk » Thu, Apr 19, 2018, 10:04 PM UTC

Someone1234 wrote: post #39

robin_reala wrote: post #30

Earlier quoted context omitted.

I mean, the fallback mechanism is progressive enhancement. It’s a reliability mechanism more than anything - if JS (or part of the JS) fails to load the site should fall back to a version that potentially reduces the interactivity but allows essential functions to continue.

Progressive enhancement is largely a myth. A lot of libraries, JQuery, Lodash, Angular, Vue, React, Bootstrap's JS, module loaders, etc aren't simply offering "improved interactivity" they're offering core functionality. In essence the site runs on these libraries, if you remove them there's nothing left to regress too. I've worked in several companies and never seen progressive enhancement used. It might have made s…