tags:

views:

1784

answers:

10

I heard that some people where having problems accessing their sites which get their jQuery from Google since their corporate firewall didn't like sites getting code from other sites, i.e. cross-site scripting?

Has anyone run into problem such as this?

+2  A: 

I dont know but i like to take control myself :), I always upload the js to the web server

Barbaros Alp
+3  A: 

Having only recently started using jQuery, and only using a local copy, I cannot comment on the cross-site problem.

Since your question title asks if there are any disadvantages to hosting this at Google, the most obvious answer that springs to mind is they may upgrade their version at any time, potentially breaking your code or causing unexpected side effects. UPDATE: Guillaume commented that you always link to a specific version of jQuery when you host. I didn't know this - thanks.

And finally, if you are in a country where the international Internet links occasionally drop, or you develop an intranet and the Internet link drops, you may find local users having errors because they cannot get to Google.

Bork Blatt
When using google hosted jQuery, you always refer to a specific version, so no problem if they add a new jQuery version.
Guillaume
Good to know Guillaume, thanks.
Bork Blatt
+10  A: 

One problem is that Google's server can and do go down at the worst possible times. In my answer to the question "What was your most uncomfortable programming experience?", I answered:

I was demonstrating my team's new web application to a group of potential users. I took a few minutes to talk about all the cool stuff the Google Visualization API can do, since we were using it heavily in our application. To demonstrate, I decided to graph a few sets of data we have collected previously. It was intended to convey the message: "Look how easy it is! Regular people can make good looking graphs using our product."

As luck would have it, the Google servers that hosted the Javascript files necessary to use the Visualization API decided to stop working midway during my presentation. I sat in the chair, staring at the screen, mumbling to myself "but... but they're Google... their servers can't go down". The team tried to laugh it off, but everyone realized at that moment how dangerous it can be to rely on any third party (even one as big as Google) when it really counts.

I know it seems unlikely, but unless you really have no other choice, I would recommend against hosting critical files on third-party servers, even if they are Google's servers. Having customers complain about an outage is bad. Having customers complain about an outage that isn't your fault and that you can't solve is even worse.

William Brendel
To be fair, it's not that hard to fall back to a locally hosted version of jQuery in the event that Google's jQuery hosting goes down.
Kevin Pang
True, but my answer was designed to point out the fact that Google can fail at the lease convenient times. While falling back to a local jQuery copy might be easy, doing so during a business presentation is still embarassing and inconvenient.
William Brendel
William, falling back on a local copy during a business presentation would not be embarrassing or inconvenient in the least. In fact, it should be nearly transparent as long as you've coded it right.
T Pops
@T Pops: When you're demonstrating a product to a room full of potential customers, having something break in the middle of the presentation is always embarrassing, regardless of how easy it is to fix. The fact that your customers doubt the reliability of your product is *very* important. That's all I was saying.
William Brendel
It wouldn't appear to break at all. It would continue working as normal **as long as you coded it right**. You shouldn't have to do anything manually and it should automatically switch over to the locally-hosted version.
T Pops
Aren't Google's servers distributed? Are you saying they ALL went down at once? And wouldn't you have the same problem if you demonstrated *anything* that relied on an internet connection to work? Though with jQuery your browser should cache the file locally after the first request, so it would probably still work even if Google went down. I think you have to weigh up the chances of ALL Google's servers going down and you NOT having a cached local copy against the many benefits. Even the official jQuery website hosts jQuery on Google!
Dan Diplo
I am not privy to Google's network layout, but in this case, the server(s) hosting the Visualization API's Javascript files became inaccessible to the public. I don't know what the problem was exactly, but that's sort of my point. Unless you are the one in control, you are at the mercy of a third party, whether it's Google, Microsoft, or some other large or small company. Is a Google-owned service likely to go down? No. Is it possible? Absolutely. That's all I'm saying. Sometimes relying on a third party is unavoidable, but avoiding such a dependency is often advisable.
William Brendel
+3  A: 

One huge advantage is offline use. I write a fair amount of code on the train without mobile data - so having the js in my web project is very useful. It also allows me to have complete control and confidence over change management.

Marc Gravell
Site in development and site in production - two different site's. In dev, for example, I often use non-minified version of js.While in production - even html is compressed.
Davinel
A: 

There are many disadvantages to having Google host your jQuery. Like other users have pointed out:

  • Google could upgrade their copy
  • Google could go down
  • End-users may not be able to reach Google

A better way to answer this may be to ask: What are the ADVANTAGES to having Google host your jQuery? Only in specific cases would I use cross-site hosting for dependencies. Namely:

  • Google probably has servers closer than yours to your end-user
  • Users are more likely to have Google's version cached locally than yours (unless they visit regularly)
T Pops
1) No, they can not: ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js. This is always be **1.4.2**2) ALL google's CDN? At once?3) They can reach your site, but they can not reach google? Why?
Davinel
+6  A: 

I presume by hosting at Google you mean the AJAX Libraries API? The advantages that I can see are:

  1. You'll save bandwidth on your site since the JS is coming from Google's CDN
  2. You may see better responsiveness and speed, since the content is coming from Google's distributed CDN, instead of your servers.
  3. If users have previously visited another site that uses Google to host its JS libraries, the user's browser may already have them cached.
  4. Google apply the latest bug fixes and security patches for the version of the library that you're running. Contrary to what others have claimed, they do not automatically upgrade you to the latest version. E.g. if you specify you want Mootools 1.11, you won't be given 1.2 or any later version unless you specifically change your script include call to request it. But they will apply fixes specific to that version.

And the disadvantages:

  1. Like you mention, some more zealous security tools and products may take issue with including scripts from a different host. I don't know how widespread a problem this is, but it's worth investigation.
  2. It potentially adds another DNS lookup to the page load.
  3. Google have committed to host each version of the libraries "indefinitely", and you'd hope they mean it. But fortunes and policies change, and if the hosting service is discontinued, you might find yourself having to revisit a number of sites to fix their JS.
  4. You're reliant on a third-party to host some of your content. Obviously you'd expect Google's uptimes to be pretty good, but if they do have problems, you might have to explain to your customer why their site isn't working just because Google is having network problems.
  5. Google host the full version of each library, but some like Mootools let you create custom versions containing just the components you need. So the Google version might be more full-fat than you need.
  6. You had no ability to customise or change the library. Making downstream changes to a library is a hairy proposition, but if you're in a jam it might be the easiest option. Having the library hosted externally adds an extra complication, as you'll have to switch to an internal copy.
  7. Bug fixes do get applied for your chosen version, so if you're somehow dependent on the buggy behaviour this may cause problems. Presumably the library authors will be very careful about potential breaking changes, but it's Murphy's law that problems will arise somewhere.
Jon Rimmer
+2  A: 

Your site's heaviest users are typically repeat visitors, and they'll have your locally-hosted .js files cached anyway, so they'll only take that bandwidth hit the first time they visit the site.

  1. Are my site's vistors typically repeat visitors? (As opposed to first-time visitors)
  2. Are my site's visitors likely to have fast net connections?
  3. Am I comfortably within my site's allotted bandwidth capacity?

Each "yes" answer is a reason to avoid relying on externally-hosted Javascript at Google.

For example: if you're running a site like StackOverflow, where your visitors are generally tech-savvy people with fast connections and caches that are fully populated from the fifty other times they checked StackOverflow this morning, the gains from hosting your Javascript elsewhere are going to be pretty minimal.

But if you're running a site for senior citizens in Kuala Lumpor off of a 256kbps DSL line in your basement, your visitors will see some nice gains if you offload those JS files to Google!

John Booty
A: 

Please see the below link to see what is lacking with Google,

Basically, for web developers and agencies using Google the issues are :

No UK license for postcodes, no Geocoding so poor accuracy (appauling accuracy for southern Ireland, No sla, no support, libraries may change which mean you need to do development and your solution is down (not working,) no guarantee of service.

Twice this month google map servers have been down for over 3 hours each time.

The customisation is poor and is typically slower to develop then the professional solutions from Bing and ViaMichelin (part of the Michelin Map business).

No Advanced Geocoding is available, no export functionalities are readily available and the directions do not take int account natural boundries so searches for cardiff will show Bristol, Essex will show Kent etc.

Privacy is always an issue too.

The print button does not work and has many bugs so a map will often print across 2 pages (half a map a page).

No professional would use the Google solution, I have developed many in the past and find the hosted Iframe and open source API from ViaMichelin to be the most cost effective.

http://www.google.com/enterprise/earthmaps/maps_features.html

Development agency
What does this have to do with jquery? You're ranting about an unrelated issue.
abeyer
A: 

Other security /user experience / performance issues using Google maps

1) Google Map’s terms and conditions state they can insert advertisements with no prior notice. 2) Google also states they can change their terms and conditions of use with no prior notice required. 3) Google only grant access use of their maps on free sites accessible to consumers and is not intended for Intranet or commercial use. 4) Cannot be used for address checking, reserve and collect and often fails work server side 5) Out of date and often incorrect Developer Network – Forum and Blog

Development agency
He wans't asking about maps.
Matthew
A: 

All these comments about bandwidth and no one even touches caching. When hosting a website, if you're NOT properly telling the end users to cache files and how long to cache them, you're asking for excessive bandwidth use and the trouble that causes.

My answer is simple. Host it yourself, check it into your source repository and properly serve it up with very long expiry headers. That way everyone downloads the stuff ONE TIME. Besides, I really can't stomach the idea of not actually OWNING every file my server sends over the wire or tells a client to download.

cmillens