Google AJAX Libraries API: 5 APIs in einer Google-API
Google tut all den AJAX-Entwicklern die sich ständig mit Versionen, Bugs und der Geschwindigkeit ihrer APIs herumärgern müssen wieder einmal etwas gutes: Mit der neuen Google AJAX Libraries API kann man mit einer API auf viele verschiedene externe AJAX-APIs zugreifen ohne sich um weitere Details zu kümmern. Google hostet das ganze für den Entwickler.
Den Anfang machen 5 APIs die AJAX-Entwicklern sicherlich ein Begriff sind:
» jQuery
» prototype
» script.aculo.us
» MooTools
» dojo
Mit der einfachen Funktion google.load() können die einzelnen APIs geladen und verwendet werden. Euer Projekt greift dabei direkt auf die bei Google gehosteten APIs zu und die API bekommt damit quasi unbeschränkte Rechenpower. Außerdem cacht Google einige Anfragen um die Geschwindigkeit noch einmal zu erhöhen.
Für Google ist das mal wieder eine geniale aber einfache Möglichkeit die Entwickler zur Benützung der eigenen Tools zu bewegen ohne selbst viel drumrum gebastelt zu haben. Und wer gleich sein ganzes Projekt bei Google hosten möchte ist mit der vor einigen Wochen gestarteten Google App Engine bestens bedient 😉
» Google AJAX Libraries API
» Liste der Google-APIs
GoogleWatchBlog bei Google News abonnieren | GoogleWatchBlog-Newsletter
Teile diesen Artikel:
hmm Sorry wenn ich da jetzt was falsch verstehe, aber es geht doch einfach nur darum, die JavaScript Bibliotheken einzubinden und immer die neuste „Stable“ Version zu haben!
JavaScript wird Clientseitig ausgeführt und hat somit sicher nichts mit Rechenpower von Google zu tun!
Korrigiert mich wenn ich falsch liege!
Hm, theoretisch ja. Aber die eigentlichen Anfragen gehen ja wieder an den Google-Server zurück der sie dann wieder auf dem eigenen Server ausführt. Oder?
Nicht, dass ich wüsste! Denn was sollte Google zurückliefern?
Es geht nur um das Laden der JavaScript-Files und der einzige Vorteil ist meiner Meinung nach nicht die Aktualität sondern höchstens der eingesparte Traffic.
Sehe ich auch so, Bronco.
Stellt sich noch die Frage in wie fern Google die Skripte auswerten kann um zu sehen (das ist ja für Google der ganze Sinn des ganzen) was damit gemacht wird…
Jens meint bestimmt nur dass die Ajax Abrufe über einen zusätzlichen Google-Server gehen (müssen), da es sonst beim externen Einbinden der Bibliotheken nicht möglich wäre Ajax Anfragen an einen anderen Host (also den auch den Eigenen) zu senden.
Da machen die Browser zur Zeit noch einen Strich durch die Rechnung.
Ob das jetzt Geschwindigkeitsvorteile bringt und in wie weit der Traffic sinkt, kann man natürlich in Frage stellen.
Ich denke eher, das es hauptsächlich für die Entwickler von Anwendungen auf Google-Servern gedacht ist, das es bisher nicht immer unproblematisch war JavaScript Bibliotheken einzubinden.
Jens/Sebastion: Nein. AJAX Requests gehen nicht ueber Google Server, hier liegt ein Missverstaendnis des Browser-Sicherheitskonzeptes vor: Die „same origin“ Begrenzung gilt nur zwischen verschiedenen Documents (Windows/Frames), aber nicht zwischen verschiedene Scripten im selben Document. Der „origin“ Host ist dabei immer die Quelle der Hauptdatei, sie veraendert sich nicht durch Importieren eines Javascripts von woanders.
Google stellt hier keinerlei Rechenleistung oder „Durchleiten von Anfragen“ bereit, nur pures Hosting der JS-Bibliotheken (inkl. Updates und Sicherstellen das diese im Browser ordentlich gecacht werden koennen etc.).
Hauptvorteil fuer Web-Entwickler:
Kein Hosting und keine Updates der Bibliotheken auf dem eigenen Server notwendig, das spart Zeit und Traffic und erlaubt es auch unerfahrenen Webseitenbetreibern ein bischen Javascript in ihre Seiten einzubauen. (Siehe Friend-Connect…)
Wer sich sowieso per SSH auf seinem Webserver anmeldet und dann im VI die Seiten updated wird das zugegebenerweise nicht so spannend finden…
Oh, und Vorteil fuer Nutzer: Statt das jede Webseite ihre eigene Kopie der exakt selben JS-Bibliothek ausliefert hat man gute Chancen das eine Kopie schon im Browser-Cache liegt und somit die Seite schneller geladen wird – selbst wenn man sie noch nie zuvor gesehen hat.
@kapet:
es ist doch spanneend genau aus dem von dir genannten Grund, dass man schon die JS-Dateien im Cache haben kann, ohne jemals zuvos auf der Seite gewesen zu sein, weil man sie schon vorher durch eine andere Seite geladen hat. Ich kann mir vorstellen, dass einige Surfer schon sehr viele Kopien von einer und der gleichen Datei im Browsercache haben, was damit nicht mehr der Fall wäre.