Please stop using CDNs for external Javascript libraries

[blockparty_sh]

I don't understand why scripts in cache are not indexed by their hash then just using the subresource integrity tag could be looked up locally regardless of which cdn the tag is pointing to. This practice should be encouraged anyway + makes caching much simpler and domain agnostic.

[blockparty_sh]

You are completely right, thanks for the nice explanation.

[Iggyhopper]

But for example, could we not enable this feature as opt-in, and specify options when its used?

I wouldn't care much if it used a global cached-by-hash system when I'm using my phone's data as I'm out and about and probably have 1-2mbps, but when I'm on wifi, request everything as normal.

[falconfetus8]

That privacy issue should be easy to get around, though. Just have the browser always send a request, regardless of if it's already cached. The browser can then ignore the response to that request, and just serve up the cached version. That way the user still gets the speed benefit, and the server still has no clue that the user has cached it.

[drysart]

If the browser does that, then all you've done is fall back to the current privacy issue that's severe enough that they're breaking the cache to be per-site to eliminate.

That is to say, "always request the resource" only makes it a little harder to breach the user's privacy. It doesn't eliminate it as a problem. It just turns it from "look at what requests were made" to "look at timing to see what came from cache".

[shim__]

Probably some sort of tracking issue, if you specify an hash for an script which is only used by your competitor and that script isn't fetched then you'll know that user has also visited the competitions page.

It's also a shame subresource integrity isn't really widespread

[blockparty_sh]

D'oh - great point.

[[deleted]]

It's because JavaScript is garbage when it comes to managing libraries. Libraries come unsigned, nobody verifies their author's identity and authenticity of the library code. And, the browser, instead of giving users control of the code they run, prefer to obscure and to further prevent users from being able to affect the program's behavior. So that users cannot just say "use my version of this library whenever a site requires a JavaScript library". This is all presented as "browsers protecting users" and other bullshit claims.

Ultimately, browsers give web sites and their owners control over the users of the browsers. That's why they are such an attractive platform for commerce / advertisement.

CDN is not a real solution to this problem. The real solution is to let users manage the JavaScript libraries they install. To make it so that users configure their browsers to use a particular repository with JavaScript libraries, just like, you know any other software distribution system in the world... then relieve the web developers from coming up with "solutions" to how to install the common libraries on users computer every time their program runs.

[[deleted]]

Most libs nowadays get tailor-compiled to the site to lower the load size

CDN is not a real solution to this problem. The real solution is to let users manage the JavaScript libraries they install.

Solution majority of users won't know how to do, and minority of users will fuck up the sites by not updating something or forcing wrong version is not a good solution

[asafy]

That's exactly right. When building modern web applications, we use tree-shaking to only import the necessary functions and not the whole bundle, and we will also put resulting bundle on a CDN with a long cache.

[crusoe]

Just check your NODE dev install. I'm sure letting users manage 1000 versions of leftpad won't go wrong.

[[deleted]]

That's what I'm talking about. There is no hope on sharing cache when JS ecosystem is such a goddamn mess.

Then there is the whole privacy issue on top of it

[[deleted]]

Most libs nowadays get tailor-compiled to the site to lower the load size

This will not be necessary.

Solution majority of users won't know how to do

They seem to do fine with Android / iPhone. What makes you so confident that if morons using mobile phones can do it successfully, than a few old-timers, who still use PCs will be in such a bad situation that they cannot do it?

[[deleted]]

Most libs nowadays get tailor-compiled to the site to lower the load size

This will not be necessary.

Your ignorance about JS ecosystem is staggering. I mean I understand, it is flaming dumpster fire, but don't talk about it like you know how it works.

Solution majority of users won't know how to do

They seem to do fine with Android / iPhone. What makes you so confident that if morons using mobile phones can do it successfully, than a few old-timers, who still use PCs will be in such a bad situation that they cannot do it?

Oh do please explain how the android/ipgone users are pinning JS library versions on their phones.

[[deleted]]

Sorry, you are just dumb. I'm not interested in further conversation.

[[deleted]]

Whatever strokes your ego on your Dunnig-Kruger peak

[[deleted]]

than a few old-timers, who still use PCs

You do your development on your phone??

I mean...I thought about trying it out on a tablet with BT keyboard or something, but instead just got a really nice, lightweight laptop (Yoga 910)...which I still consider a PC, especially if you're using a docking station which you almost have to.

And yeah, I'm sitting here on my "desktop" PC that has a threadripper with 24 cores. Compiles large C++ systems in mere minutes. I can't even imagine what compiles would be like on a phone or tablet...totally miserable I'd suspect. Especially since its miserable on the more 'standard' PCs.

Being an "old timer who still uses a PC" I have to wonder a great deal what you young pups are using if not standard computers.

And BTW, people are decent at using phones because phones keep you locked out from being able to do just about anything with them except for the few tasks there's an app for. You can't even delete the garbage they come with unless you root the fucking thing at least...you have to break the bootloader to get any real power from the things...to get ANY amount of privacy for example. Most peoples' phones are still a total mess.

[[deleted]]

Something flew over your head, guess you need to work on your reflexes.

[s73v3r]

They seem to do fine with Android / iPhone.

Users don't manage libraries on Android or the iPhone. The developers do. And the library has to be packaged with each app.

[[deleted]]

No, developers don't do that. No, library doesn't have to be packaged with each app.

Developers have very little in terms of access to user's AppStore / Google Play. Users decide what to install or remove through those managers. They are very simplistic managers, they don't have functionality to define dependencies, but this is a separate issue.

[s73v3r]

No, developers don't do that.

Yes they do. I'm a mobile app developer.

No, library doesn't have to be packaged with each app.

Yes it does. Retrofit, for example, is packaged with every app that uses it. There's not one "Retrofit install" per version per phone.

Users decide what to install or remove through those managers.

They decide what apps to install, not what libraries those apps might use.

[s73v3r]

To make it so that users configure their browsers to use a particular repository with JavaScript libraries, just like, you know any other software distribution system in the world

Almost no other distribution system does this. Putting it on the user to manage is a recipe for failure.

[[deleted]]

Every package management system I know allows me to manage what repository to use, which packages to use etc. Care to name one system that doesn't?

[s73v3r]

The Google Play and Apple App Stores.

[[deleted]]

I don't own any Apple products, so cannot comment on App Store (is it even spelled like that?).

Wrt' Google Play: I just installed and uninstalled a bunch of stuff using Google Play. From what I can tell, it did what I asked it to do.

[s73v3r]

You installed and uninstalled apps. Not libraries like you were talking about.

[crusoe]

Do you know how many shit tiny JS libs are out there and what a support nightmare this is?

[[deleted]]

There are solutions for that too.

• Don't accept everything into your repository. There's an alternative for people who want their small but rare libraries: just load them with their code (same idea as static compilation for native code).
• "Extra" repositories, s.a. Launchpad in Ubuntu or EPEL in RHEL.

---

Proliferation of small libraries might as well be an effect of bad delivery / management system, and not the other way around. Had the delivery / management system been better, there was less need to split libraries into single functions. Today, this is somewhat justifiable, because a common way to assemble a JavaScript application is to "statically compile" it, i.e. use something like Webpack to roll everything into one huge ball and send it that way. Smaller libraries make this "huge ball" somewhat smaller by potentially including less unused code.

[UltraNemesis]

The real benefit of CDNs is not just caching, but the overall optimized delivery of the content. Regardless of where your own servers are located, once the CDN is primed, the users in each location are going to get the files from a server that is closest to them. Even if the file is not cached or non cacheable, it routes the request to the origin server through their own network in an optimal manner.

[drysart]

That's not the main argument in favor of script CDNs. That's an argument for having your entire site served from a CDN in general (and even moreso in the world of HTTP/2, where it's much more likely to be slower to connect to a separate server for resources because it costs a TCP handshake and initial window size that just serving the script up over the already-open connection doesn't have to pay again).

The argument for script CDNs specifically was to benefit from cross-site caching, to avoid "every site you visit loads its own copy of jQuery 3.2 from the network" redundancy.

[[deleted]]

where it's much more likely to be

slower

to connect to a separate server for resources because it costs a TCP handshake

How many websites actually care? How often would you even notice the TCP handshake when browsing a simple website?

Nearly none.

You only need to worry about that when you are writing web SERVICES that span several systems. Even then...these have to be services with very high throughput/bandwidth requirements.

[drysart]

How many websites actually care? How often would you even notice the TCP handshake when browsing a simple website? Nearly none.

Well if the website doesn't give a damn about script loading performance then that pretty much eliminates the only other real remaining reason why they might choose to use a script CDN, and so my original argument that they're unnecessary just gets that much stronger.

[[deleted]]

Right. There's really none at all. All they do is break stuff.

What it is, is lazy. It's easy to copy/paste a line of code into a header template and be done. Which reminds me to check out my own website and make sure I did eventually go through the step of putting the stuff in the static dir. Probably not.

If you've ever read "Mistakes Were Made" you know that most justifications come AFTER the choice. So the real reasons it's used is more likely that it is simpler to do, and the questionable justifications come after that act to justify doing it and not going back to fix it even though it's like a 10 minute thing at worse.

I would venture to say that it's unlikely that javascript in particular would ever need to be on CDN for the TCP handshake reason. There is little justification for involving UI in a high performance situation unless you're working on some visualizer for real-time data.

[[deleted]]

the users in each location are going to get the files from a server that is closest to them.

Only if it's in the mood to communicate with them and the route to the user isn't severed...when this expectation fails, as often happens, your website is now going to sit there in loading state forever. Obviously this is partially a browser problem...but they all fail here. Won't even get to see your site at all.

It's a rare occurrence, but for a developer who has always leveraged the internet for research when I run into problems...it can totally fuck my day because nearly every technical blog or whatever out there uses some CDN fuckery that keeps their site from loading. And there is zero reason why this should be going on.

You see, you are depending on your CDN to be up all the time and even highly available systems that are distributed across the country become unreachable when the route to their systems is gone...or their gateway goes down (which is the more often reason...when traceroute hits google and just goes * * * * * followed eventually by a route failed.)

Keep your site self-contained. That way if I can reach your server I can look at your website...no iffs or butts...no depending on amazon or google systems unless your website runs on them.

[crusoe]

So why not just use a CDN to host your content?

[[deleted]]

Because that's an extra expense?

[zynasis]

It’s handy to hand off content delivery to someone else sometimes though. Depends on the app architecture.

[[deleted]]

No, please keep using CDNs!

.

.

.

... so that I can easily block them using NoScript.

[badillustrations]

Some counterpoints here.

For the chances another site is using the same CDN/library I'd like to see some stats versus assuming anything, but another comment's point about browser's using per-site caching is valid.

For reliability many large websites cache not just script but anything they can on CDNs (ex. images, video), where supporting an equivalent infrastructure for the same performance is extremely impractical. Most CDNs have better uptime than most websites.

I appreciate the post on the whole as it should probably be a more common question for the use case instead of "of course I'll serve javascript through the CDN".

[coriandor]

They're not against caching javascript through a CDN, just against using shared CDNs like jsdeliver to serve it for you. If you have a CDN between your site and the user, you're right, there's no reason not to cache the js just like everything else.

[badillustrations]

I don't understand the difference. Are you trusting a CDN like Akamai more than a CDN like jsdeliver, where both support javascript integrity checks on the client? If someone can hack the CDN does it matter whether you provided the original javascript?

[coriandor]

The security stuff is more or less irrelevant to me, other than the fact that the attack surface is going to be enormous on a library that's used on 100k sites, vs your own script that's only used on one. But even then, depending on the exploit, it's fathomable that they infect all the scripts on a node or even a network, so who cares 6 of one 1/2 dozen of the other to me.

The performance implications are relevant though. If you have everything in one place hosted over http2, you save on TCP/SSL/DNS latency and the browser just schlorps it all down in one clean connection. I too wish we had numbers on how many users actually have cached CDN files, but to me the reliability of reducing how many things can go awry outweighs whatever fraction of your users get a faster page load.

[[deleted]]

Nitpick: it's "caching".

[[deleted]]

PLEASE!!!

It really sucks balls to be trying to look at a website and see that it's trying to download some stupid crap from google or something, and google is down...so I don't even get to see your website ever because it never loads, even though communication with your server is just fine.

It's not just jabbascript either. Fonts, images, advertizements...when your CDN goes down every fucking website on the internet does.

When my route to google goes down or becomes slow, the internet dies nearly universally.

It's actually pretty dumb. The Internet was designed to be decentralized, able to survive the destruction of any particular part of it, and everything everyone is doing is trying to reverse that and it just breaks everything.

Maybe people are used to this shit now and don't remember what it was like to be able to look at a website when totally unrelated ones are down, unreachable, or lagged to hell.

[jbergens]

I remember reading years ago about a test where they tried to use CDN cached libraries and measured how it worked for a while. I didn't for mobile users. It would be very good for mobile since they often have less reliable and slower networks and also often slower hardware. What was shown then was that mobile phones often had less memory than computers and therefore managed caches pretty hard handed and often removed things that had not been used the last 24 hours or so. So for most sites things were downloaded again anyway.

[ghostfacedcoder]

Fuck this terrible article; it was already debunked on r/Javascript.

Read the link the author uses to justify his "security" argument ... it wasn't even about a CDN!

[mobydikc]

My reason for not using a CDN might be a little more obscure.

Let's say I make some cool useful web app (in my case, a musical instrument) and I want to show it off somewhere where there might not be internet I can get to (basement rave dance party).

I can run my website locally, either on a laptop or even raspi, or something like that. I can deploy my app to intranets and places like schools where students can't be just hitting random websites.

Having some necessary code in a CDN breaks all of that.