Hinter der AJAX Libraries API verbirgt sich nicht weniger als eine Möglichkeit, populäre JS-Frameworks via Google zu beziehen, statt sie auf dem eigenen Server zu lagern. Google erledigt das Caching-Setup, nimmt den entstehenden Traffic auf sich und spielt Bugfixes und Updates ein.
Wenn man also beispielsweise in irgendeiner Website jQuery 1.2.6 verwenden möchte, kloppt man einfach diese eine Zeile in sein HTML und ist fertig:
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>Wem das zu billig ist, der kann auch die Googles google.load()-Funktion hernehmen:
<script src="http://www.google.com/jsapi"></script>
<script>google.load("jquery", "1.2.6");</script>Unterstützt werden im Moment jQuery, prototype, script.aculo.us, MooTools und dojo. Genauere Infos gibt es bei Googles AJAX Search API Blog.
Kommentare (10)
mike ¶
28. Mai 2008, 00:06 Uhr
Schön, dass Du's sagst, kann ich das rechtzeitig in Adblock aufnehmen, bevor meine IP 2000 Mal pro Woche bei Google in den Logs landet.
Benny ¶
28. Mai 2008, 06:42 Uhr
ich finds auch eher bedenklich. warum sollte ich die javascript dateien auf einem fremden host lagern? so habe ich keinen einfluss auf das, was tatsächlich passiert. zudem könnte ich mir vorstellen, dass das auch ein wenig langsamer ist. es ist schließlich ja auch kein aufwand, den kram auf dem eigenen server zu laden.
Gabraham-Himself ¶
28. Mai 2008, 07:12 Uhr
Zumal Google auslesen kann, wer wie oft woher welche Skripte bezieht. Muss nicht sein. Yahoo! bietet da was ähnliches mit dem YUI Kram.
Gerrit ¶
28. Mai 2008, 07:18 Uhr
Die wollen halt ihre Suchergebnisse weiter verbessern, indem Sie einen internen Counterdienst hochziehen, der genau sagen kann, wieviel Zugriffe die getrackten Seiten haben. Ohne mich!
Gero ¶
28. Mai 2008, 07:30 Uhr
Ich halte das für groben Unfug. Wenn mir dann irgendwer auf welche Weise auch immer ein gepatchtes Framework unterschiebt (sei es ein Man-in-the-Middle-Angriff, oder sei es auch nur Google selbst, Kategorie "improved - don't be evil" ), sind die Auswirkungen auf meine Webapplikationen völlig unvorhersehbar. Und sei es auch nur, dass der Server des API-Labs mal nicht erreichbar ist und die ganze Webanwendung komplett in den Seilen hängt. ... Das wäre dann so ähnlich wie der Hinweis beliebiger Websites in der Browser-Statuszeile, dass google-analystics.com mal wieder etwas länger braucht als erhofft - nur schlimmer.
Bottom line is: Die potenziell negativen Auswirkungen wiegen für mich deutlich schwerer als der Vorteil eines zentralen Updates ohne eigenes Zutun.
Erich Erlenstaub ¶
28. Mai 2008, 10:00 Uhr
Zitat Gero:
Nunja, das zentrale Update ist so auch gar nicht gegeben, da du ja explizit die Version angibst.
Auf den ersten Blick ist das schon eine tolle Sache den Traffic auszulagern, aber eigentlich hat nur Google den Vorteil des Trackings. Wer so viele Zugriffe verzeichnet, dass die 50kB des Frameworks stark ins Gewicht fallen, der hat in der Regel auch das entsprechende Hosting, dass das Mehr einfach nicht mehr juckt.
Aber kreativ beim Heranschaffen der Daten sind sie, das muss man ihnen definitiv lassen :)
Peter ¶
28. Mai 2008, 11:10 Uhr
Zitat Gerrit:
Maybe. Aber wenn man ohnehin Feedburder, Analytics und Adsense benutzt macht das den Kohl auch nicht mehr fett.
Rafael Nathan ¶
28. Mai 2008, 16:32 Uhr
Zitat Peter:
Dann sollte man sich das vielleicht sparen und so Dinge wie Feedburner selbst implementieren, an Stelle von Analytics zu Open-Source-Analyse-Software greifen und Adsense durch individuelle Werbekunden oder durch ein anderes, google-freies Werbenetzwerk ersetzen.
Zwar sehe ich das Problem, das Gerrit beschreibt, auch als schwerwiegend an - aber hey: wenn Gerrit auf seiner eigenen Webseite AdSense hat, macht auch bei ihm die AJAX-API den Braten nicht fett ;-)
Manuel ¶
28. Mai 2008, 19:29 Uhr
Zusätzlich zum zentralen Update und weniger Traffic besteht ja auch noch der Vorteil, dass die JS-Libraries nur einmal im Browsercache landen, weil vom selben Source bezogen.
(Oder tun die das sowieso, wenn der Hash gleich ist oder so?!)
Somit würde (wenn wirklich einige Websites diese googlehosted Libraries verwenden) auch ein (kleiner) Geschwindigkeitsvorteil entstehen (weil man die JS-Files nur 1x laden muss) oder liege ich da falsch?
Ich werde es jedoch (vorerst?) auch nicht verwenden. Auch wenn ich die Idee grundsätzlich nicht so schlecht finde.
Markus Möller ¶
28. April 2010, 05:16 Uhr
Zitat Manuel:
100% richtig. Das ist der Vorteil.
Weiterer Performance-Vorteil: JavaScript-Dateien von unterschiedlichen Domains können vom Browser GLEICHZEITIG geladen werden. Und noch ein Vorteilchen: Ist JS deaktiviert, wird auch keine JS-Datei nachgeladen. Den Traffic spart man sich dann und es geht dementsprechend schneller. Ob die Seite dann überhaupt noch sinnvoll funktioniert, ist eine andere Sache..