Comments on: Don't Host Static Assets

By: Russ

Russ — Fri, 05 Jun 2009 00:42:34 +0000

The only problem with reverting to local files if remote files are unavailable is that your code could get stuck waiting for the remote files to be found, which would drag down your site speed if you checked for remote file existence upon every request.
However, if you checked for remote file existence at the start of an application or session, then individual page load time wouldn’t be affected. I think that would be the best way to do it.

By: Chris

Chris — Thu, 04 Jun 2009 21:48:45 +0000

I think that, given the amount of high profile sites using the Google code version of jQuery, they would make sure that the availability was extremely high.

I would be a cool experiment to work out a way to programatically ensure that your JS files were loaded. The first thing that comes to mind would be a tiny JS file loaded locally that could determine if the jQuery (if that’s what you’re using) namespace existed, and if not, load a local, or alternatively hosted JS file. I think that would work. You could also use some fancy DNS tricks to use your own server as failover for the remote file. I’d build something like that if I was relying on a site for income.

By: Rob Dudley

Rob Dudley — Thu, 04 Jun 2009 20:50:17 +0000

Great idea and I wholeheartedly agree with the concept of progressive enhancement.

That said the DNS for Google reader was fritzed for 5 minutes before reading this and I’m not convinced that some of our clients would understand sporadic outages. Now if there were some way to programmaticly determine availability and include or fail back to local – that would be frickin’ sweet!

By: Chris

Chris — Thu, 04 Jun 2009 18:27:40 +0000

Both good points Russ

As for reliance on third party severs, for many people these third party servers are more reliable than their own servers. Also, I design most of my sites to use JS only to add functionality, keeping the site completely functional for users without JS at all (this also applies to CSS). Progressive enhancement is how JavaScript should be used if you want to reach the biggest audience.

In the case of loading jQuery from the Google code link, the jQuery.com even uses that. I think relying on Google to have their servers up is a pretty good gamble.

And with respect to Amazon Web Services, many many huge websites rely on AWS to host not only static assets, but dynamic assets, and assets that need to be secured. It’s an incredible service.

Crazy things can happen, and I agree that you need to be able to back out of any reliance on a third party, but that can be done easily by changing a couple of settings in your application.

By: Russ

Russ — Thu, 04 Jun 2009 18:00:23 +0000

In theory, this idea sounds good. In practice, I’m less convinced.
Potential issues:

1. Reliance on remote third party servers for core functionality seems like an unnecessary risk. There is no guarantee that those files will always be available.
And what becomes of your site when the remote JS files are unavailable? Users would be able to see your site but not use it, which would hurt your reputation much more than if your server went down and the site was entirely unavailable for a while.

2. Non-standard practices can cause confusion for future developers. If I hadn’t read this article, I would be confused if I came across some code referencing remote JS files, and then I would probably “fix” it, which would be a total waste of time.