Welche Quelle sollte man für jQuery nutzen?
04.09.2007 - 17:50 Frameworks, JavaScript 12 Kommentar(e)
Auf immer mehr der von mir erstellten Webseiten kommt in der letzten Zeit das jQuery-Framework zum Einsatz. Die Anwendung ist aus meiner Sicht genial einfach und dennoch super flexibel. Innerhalb weniger Stunden kann damit auch ein Javascript-Laie erste kleinere Ajax-Funktionen in seine Seiten implementieren.
Seit geraumer Zeit bietet jQuery nun auch den Bezug des Frameworks über den Amazon S3-Service an.
Mit Amazon S3 ist es möglich die gleiche Servertechnik wie das Amazon-Portal zu nutzen, was theoretisch eine fabelhafte Performance und eine nahezu hundertprozentige Ausfallsicherheit bedeutet.
Im Klartext heißt das für Webseitenbetreiber die das jQuery-Framework nutzen folgendes: Statt sich die Javascript-Datei des Frameworks auf den eigenen FTP-Account zu kopieren und von dort zu verlinken, können nun alle Entwickler eine globale Quelle für das Framework benutzen. In der Praxis sieht das dann z.B. so aus:
<script type="text/javascript" src="http://code.jquery.com/jquery-latest.pack.js"></script>
Dieses Beispiel würde also immer das derzeit aktuelle Release des Frameworks in die Seite einbinden, ein manuelles Update (derzeit ca. einmal pro Monat) würde damit nicht mehr nötig sein.
Welche Vorteile ergeben sich nun für Nutzer und Entwickler aus diesem “externen Hosting”?
- auf Wunsch ist immer das aktuellste Release nutzbar
- sollte sich diese Nutzung zum Standard entwickeln, hätten viele Besucher die Datei wahrscheinlich schon im Cache, was die Ladezeit verkürzen könnte
- Einfacher wechsel zwischen den Framework-Versionen
- hohe Ausfallsicherheit
- schnelle Antwortzeit des Servers
- mehr Speicherplatz ;)
Natürlich kann das ganze aber auch einige Schattenseiten haben!
- es entsteht eine Abhängigkeit zu einem externen Dienstleister
- nutzt man immer das aktuelle Release, so kann es zu Inkompatibilitäten zwischen dem Framework und dem eigenen Script kommen was im produktiven Einsatz fatal enden kann.
- hat ein Besucher die Datei noch nicht im Cache würde es durch den zusätzlichen DNS-Check zu einer etwas höheren Ladezeit führen
- Intranetprojekte bzw. Seiten auf denen nicht alle Besucher über einen Internetzugang verfügen können das Framework nicht herunterladen/nutzen
Soweit so gut, nun interessiert mich natürlich wie immer eure Meinung zu diesem Thema :)
Ich für meinen Teil werde in öffentlichen Projekten wohl trotz der Nachteile das eine oder andere mal auf das externe Hosting zurückgreifen. Ich mag einfach den Gedanken des zentralen Hostings. Für mich macht es keinen Sinn ein und die selbe Datei bei 20 verschiedenen Seiten immer wieder aufs neue zu beziehen, das ergibt eine unnötige Redundanz. Zudem ist der Amazon S3-Dienst wirklich einer der ausfallsichersten Hostingprovider dieses Planeten.
Wenn genug Webseitenbetreiber sich ebenfalls für diesen Schritt entscheiden würden, so könnte das die Ladezeit auf manchen Seiten doch noch um einiges herabsetzen. Große Portale könnten zudem aus den geringerem Trafficaufkommen profitieren.
Solltet ihr euch ebenfalls für diesen Schritt entscheiden, würde ich euch jedoch stark dazu raten nicht immer automatisch die aktuellste Version zu verlinken, sondern stattdessen die Versionsnummer immer manuell anzugeben, was in der Praxis dann so aussehen könnte:
<script type="text/javascript" src="http://code.jquery.com/jquery-1.1.4.pack.js"></script>
Somit kann man bei einem Update in aller ruhe die Kompatibilität absichern und eventuell nötige Änderungen vor einem Wechsel einspielen.
Kommentare zum Thema Welche Quelle sollte man für jQuery nutzen?:
Sinn und Zweck von verteilten Servern ist es nunmal schnelle Reaktionszeiten für den Nutzer zu ermöglichen. So hat ein Datenpaket von einem deutschem Server zu einem deutschem Nutzer gewöhnlich kürzere Wege, als von einem Amerikanischen o.Ä.
Ich halte es ebenfalls für Quatsch immer aktuelle Releases zu beziehen, da Software nie zukunftsorientiert entwickelt werden kann. Alles in allem ist das zentrale Hosting von Dateien in diesem Fall für mich eher ein Nachteil, als eine Weiterentwicklung, nicht umsonst hat sich einzelnes Serverhousting so durchgesetzt.
Ich finde die Idee im Grunde gar nicht schlecht, vor Allem vom Aspekt des Cachings her: Man lädt ein Script statt zwanzig mal am Tag nur ein Mal pro Woche. Genial einfach, einfach genial.
Andererseits muss ich auch sagen, dass in Zeiten von DSL und Co. so etwas im Prinzip ziemlich überflüssig ist. Mit einer Leitung oberhalb von ISDN tangiert mich der Unterschied zwischen 10 und 20 Requests einfach nicht, solange es in der Regel beim erstmaligen Betreten so ist und während der Navigation auf der eigenen Seite ja eh dann kein Unterschied mehr vorhanden ist.
Die Ausfallsicherheit ist an diesem Punkt auch kein Thema: Ausfälle eines externen Servers – so selten sie auch sein mögen – sind nicht zum selben Zeitpunkt wie Ausfälle des eigenen Servers. Wenn jedoch ein Ausfall meines eigenen Servers da ist, ist da keine Seite, die das Script nicht laden kann – die Seite selbst geht ja nicht.
Von daher bleibt summa summarum vor Allem die Bequemlichkeit, die Datei nicht jedes Mal neu bundlen zu müssen. Ist eine super nette Idee und ist in dieser Form wohl auch sinnvoller als sie zentral bspw. auf dem Server des Webstudios zu hosten oder so (was, wenn die Geschäftsbeziehung gecancelt wird?), aber ob das wohl reicht… ?
Ich glaube wir sind alle doch sehr DSL verwöhnt. Sicherlich, auf der kleinen Portfolio Seite die sich am Tag 20 Leute ansehen ist die Ladezeit im Prinzip fast egal. Ich rede hier eben eher von öffentlichen Portalen/Communitys mit relativ starkem Traffic.
Angenommen eBay würde auf jquery setzen, oder z.B. Youtube, eben irgendein Internetriese, dann hätten in einiger Zeit ein Großteil meiner Besucher die Datei im Cache.
Klar, bei jQuery an sich spielen für uns die 21KB keine große Rolle, bei ISDN-Usern immerhin 3-4 Sekunden mehr/weniger Ladezeit.
Übrigens ist auch in Planung alle Plugins über diesen Weg freizugeben, bzw. sich über eine Schnittstelle die Plugins dynamisch zu beziehen. Das ganze ist derzeit noch nicht weit verbreitet, aber ich finde die Idee cool. Ich meine warum hat wirklich fast jede Seite heute eine eigene jquery.pack.js? Warum muss ich sie immer und immer wieder neu beziehen?
Ok, aber mal ganz ab von der produktiven Nutzung: Zumindest während der Entwicklung kann es ein fixer Helfer sein, gerade wenn man zwecks Pluginkompatibilität mal zwischen unterschiedlichen Versionen springen muss.
Bei einer solch kleinen Datei halte ich das zentrale Hosting auch für Quatsch. Bei großen Dingen macht es wohl eher Sinn.
Ein Argument kann ich aber nicht nachvollziehen: Wenn man eine bestimmte Version von jQuery verlinkt und diese dann aktualisieren möchte, dann ist es in meinen Augen die selbe Arbeit die Zeile im Quelltext zu ändern, wie einfach die neue Version auf den FTP zu laden. Die Zeitersparnis ist also eher gering. Vorraussetzung ist dabei natürlich, dass sich der Dateiname nicht ändert. ;-)
Ich für meinen Teil hoste die Dateien lieber auf meinem Server. Aber da ist sicher eine Frage des Geschmacks.
Ich merke schon, ihr seit von meiner Idee nicht zu begeistern :)
Aber ich merke so langsam das ihr wohl recht haben könntet.
Für welches Projekt es aber wirklich Sinn machen könnte ist extJS, immerhin ist hier das gesamte Paket locker mal 450KB fett… eignet sich aus meiner sicht daher auch besser im Backend-Bereich. Könnte man hier einen “globalen” Cache nutzen wär das natürlich fein, aber dafür ist das Framework leider bei weitem noch nicht verbreitet genug und bietet zudem bisher auch kein extenes Hosting an!
Was man auch nicht vergessen sollte: jQuery ist eine Textdatei, die komprimiert übertragen (was ja die Norm sein dürfte) nochmal deutlich kleiner wird, als sie schon ist.
Naja, das komplette extJS wiegt gepackt glaube noch um die 200KB, aber im Normalfall benötigt man nicht alle Komponenten. Wie schon gesagt sehe ich die Verwendung von extJS eher im Backend… im Frontend wiegt es ein wenig zu viel und kommt wahrscheinlich etwas zu durchgestyled daher.
Im Backend ist mir die Ladezeit bei eigenen Anwendungen nicht ganz so wichtig, da man meist die Benutzergruppen und deren Voraussetzungen bereits kennt und z.B. bei DSL-Only Benutzern die Ladezeit ein wenig ausklammern kann.
Ja, schon… wobei es aber imho gerade im Backend nervig ist, auf den Server warten zu müssen. So manche Arbeitszeit kommt eben dann doch nur durch langsame Server zustande ;-) Wobei das aber wohl in diesem speziellen Fall nicht das Thema sein dürfte, Stichwort Caching.
Kommentar-Feed für diesen Artikel
Erste Beta des Magento-Shopsystems veröffentlicht Gmail und der agressive Spamschlucker
Ich halte es für Quatsch, so ein kompaktes Skript wie jQuery von einer externen Adresse zu laden. Das würde die Seite im Schnitt eher langsamer als schneller machen wegen dem zusätzlichen Request. Wenn ein Besucher zum ersten Mal auf deine Seite kommt, bekommt er jQuery auch in den Cache und es muss später nicht mehr nachgeladen werden.
Ein Update beschränkt sich zudem auf das Austauschen einer winzigen Datei, was ich lieber mache, wenn ich es will – etwa wenn ich lese, dass die Performance stark verbessert wurde. Wenn was nach dem Update nicht mehr funktioniert, geht’s eben erstmal zurück zur alten Version.