Modulatität ist unsinn

[Geistesgegenwart]

Wenn jetzt jeder webentwickler sein eigenes jQuery zusammenbaut und selbst hostet, muss es auch auf jeder Website neu geladen werden. Momentan bindet man es einfach von einem CDN wie google ein, und bei jeder Site die das genauso macht liegt das Script dann schon im Browsercache.

[c3rl]

Jede etwas größere Anwendung hat eh ihre eigene jQuery-File rumfahren. Deine Aussage trifft nach meiner Erfahrung maximal auf private und kleine Websites zu, nicht aber auf richtige Webanwendungen.

Von daher isses eh irrelevant. Die CDNs werden einfach die Vollversion bereitstellen, und gut ist.

[Sammie]

Geistesgegenwart schrieb:
--------------------------------------------------------------------------------
> Wenn jetzt jeder webentwickler sein eigenes jQuery zusammenbaut und selbst
> hostet, muss es auch auf jeder Website neu geladen werden. Momentan bindet
> man es einfach von einem CDN wie google ein, und bei jeder Site die das
> genauso macht liegt das Script dann schon im Browsercache.

Da darf man nicht nur die Vorteile sehen. "Jedesmal" ist ja auch übertrieben. Auch nur beim ersten Besuch. Und die CDN-Server sind auch ab und zu mal kurzfristig nicht erreichbar, und man müsste für diese Fälle Fallbacks einbauen, die dann doch wieder vom lokalen Server laden.

Das zusätzliche DNS Lookup auf die (meist) Ami-Server dauert zudem auch oft länger und kann den Seitenaufbau sogar ausbremsen. Zudem hat man lokal auch mehr Kontrolle das ganze auch noch zusätzlich über nem gzip-Stream an den Client auszuliefern und damit noch schneller zu laden als es von Google möglich wäre.

Bzgl Datensicherheit ist externes Hosting auch nicht viel besser als ein Like-Button von Facebook. Schließlich landet jeder externe Aufruf eines von Google markierten Users dank Tracking-Cookie auch in deren Logs und haben dadurch wunderschöne Bewegungsprofile der User.

Und für Entwickler, die ihre Webseiten erstmal auf einem lokalen Server offline entwickeln, oder ihren Kunden die Webseite von einem USB-Stick präsentieren wollen, taugen Verlinkungen zu CDNs auch nichts. Gibt also genug Gründe die gegen CDNs sprechen.

[Misdemeanor]

Geistesgegenwart schrieb:
--------------------------------------------------------------------------------

Meinst Du vielleicht Modularität? Oder kenne ich dieses Wort bloß nicht?



1 mal bearbeitet, zuletzt am 10.08.12 10:50 durch Misdemeanor.

[developer]

Wer ist denn dieser "man" der immer als referenz für aus den augen des autors optimales verhalten herhalten muss?

Hat den schonmal jemand getroffen? Wie ist der so drauf?

Muss ja ein toller bursche sein das mädel...

[Geistesgegenwart]

Sammie schrieb:

> Da darf man nicht nur die Vorteile sehen. "Jedesmal" ist ja auch
> übertrieben. Auch nur beim ersten Besuch. Und die CDN-Server sind auch ab
> und zu mal kurzfristig nicht erreichbar, und man müsste für diese Fälle
> Fallbacks einbauen, die dann doch wieder vom lokalen Server laden.

CDN haben aber definitiv eine bessere Verfügbarkeit als dein eigener Server, genau DAS ist es nämlich womit CDNs ihr Geld verdienen.

> Das zusätzliche DNS Lookup auf die (meist) Ami-Server dauert zudem auch oft
> länger und kann den Seitenaufbau sogar ausbremsen. Zudem hat man lokal auch
> mehr Kontrolle das ganze auch noch zusätzlich über nem gzip-Stream an den
> Client auszuliefern und damit noch schneller zu laden als es von Google
> möglich wäre.

Ist für DNS doch egal ob die Server in Amerika oder Mogadischu stehen, die jQuery mirror von google und microsoft stehen in so ziemlich jedem DNS cache, auch in dem Cache deines deutschen Internetanbieters. Der DNS lookup dauert daher zu 99.9999% nicht länger als ein DNS lookup zu einem deutschen Server. Im Gegenteil, bei wenig besuchten Websites dürfte dein DNS record nicht in den Caches vorgehalten sein (vorausgesetzt dein jQuery script liegt nicht unter der gleichen domain wie deine website natürlich).

>
> Bzgl Datensicherheit ist externes Hosting auch nicht viel besser als ein
> Like-Button von Facebook. Schließlich landet jeder externe Aufruf eines von
> Google markierten Users dank Tracking-Cookie auch in deren Logs und haben
> dadurch wunderschöne Bewegungsprofile der User.

Gerade getestet, weder google noch microsoft setzen einen Cookie bei der Abfrage. Und wenn du soweit gehst, Google oder MS schlagartige "Bösartigkeit" vorzuwerfen, z.B dass sie Schadcode in das .js script einschleusen oder übernacht auf einmal cookies verwenden, dann musst du auch davon ausgehen dass dein Webhoster deine Skripte serverseitig manipuliert oder über reverse proxies cookies einschleusst.

> Und für Entwickler, die ihre Webseiten erstmal auf einem lokalen Server
> offline entwickeln, oder ihren Kunden die Webseite von einem USB-Stick
> präsentieren wollen, taugen Verlinkungen zu CDNs auch nichts. Gibt also
> genug Gründe die gegen CDNs sprechen.

Abgesehen davon dass das ein sehr unrealistischer konstruierter fall ist (wer hat heute noch statische Websites?), würde das volle jQuery script (also unmodularisiert) von einem USB Stick so schnell geladen, das kein Messbarer (ja und ich meine Messbar und nicht Spürbar) unterschied bestünde. Zudem müsste der Rechner auf dem Präsentiert wird, über keine Internetanbindung verfügen (die .HTML datei kann ja vom stick kommen).

[Geistesgegenwart]

Misdemeanor schrieb:
--------------------------------------------------------------------------------
> Geistesgegenwart schrieb:
> ---------------------------------------------------------------------------
> -----
>
> Meinst Du vielleicht Modularität? Oder kenne ich dieses Wort bloß nicht?

Selbstveränstlich mein ich Modulrität. Willst du jetzt ernsthaft wegen eines Typos hier rumtrollen? Das R sitzt bei mir jedenfalls genau neben dem T, da hätte man doch drauf kommen können

[saithis]

Geistesgegenwart schrieb:
--------------------------------------------------------------------------------
> Sammie schrieb:
>
> > Da darf man nicht nur die Vorteile sehen. "Jedesmal" ist ja auch
> > übertrieben. Auch nur beim ersten Besuch. Und die CDN-Server sind auch
> ab
> > und zu mal kurzfristig nicht erreichbar, und man müsste für diese Fälle
> > Fallbacks einbauen, die dann doch wieder vom lokalen Server laden.
>
> CDN haben aber definitiv eine bessere Verfügbarkeit als dein eigener
> Server, genau DAS ist es nämlich womit CDNs ihr Geld verdienen.

Und was bringt einem ein Verfügbarer CDN, wenn der eigene Server mit der Webseite offline ist? Nix! (Zumindest wenn alles auf einem Server liegt, was ja oft genug der Fall ist.)

> > Das zusätzliche DNS Lookup auf die (meist) Ami-Server dauert zudem auch
> oft
> > länger und kann den Seitenaufbau sogar ausbremsen. Zudem hat man lokal
> auch
> > mehr Kontrolle das ganze auch noch zusätzlich über nem gzip-Stream an
> den
> > Client auszuliefern und damit noch schneller zu laden als es von Google
> > möglich wäre.
>
> Ist für DNS doch egal ob die Server in Amerika oder Mogadischu stehen, die
> jQuery mirror von google und microsoft stehen in so ziemlich jedem DNS
> cache, auch in dem Cache deines deutschen Internetanbieters. Der DNS lookup
> dauert daher zu 99.9999% nicht länger als ein DNS lookup zu einem deutschen
> Server. Im Gegenteil, bei wenig besuchten Websites dürfte dein DNS record
> nicht in den Caches vorgehalten sein (vorausgesetzt dein jQuery script
> liegt nicht unter der gleichen domain wie deine website natürlich).

Oft liegt jQuery aber unter der gleichen Domain ;)

> > Und für Entwickler, die ihre Webseiten erstmal auf einem lokalen Server
> > offline entwickeln, oder ihren Kunden die Webseite von einem USB-Stick
> > präsentieren wollen, taugen Verlinkungen zu CDNs auch nichts. Gibt also
> > genug Gründe die gegen CDNs sprechen.
>
> Abgesehen davon dass das ein sehr unrealistischer konstruierter fall ist
> (wer hat heute noch statische Websites?), würde das volle jQuery script
> (also unmodularisiert) von einem USB Stick so schnell geladen, das kein
> Messbarer (ja und ich meine Messbar und nicht Spürbar) unterschied
> bestünde. Zudem müsste der Rechner auf dem Präsentiert wird, über keine
> Internetanbindung verfügen (die .HTML datei kann ja vom stick kommen).

So konstruiert ist das garnicht. Wenn bei mir in der Uni wieder mal das WLAN spinnt, gibts teils Stunden lang kein Internet. Das hält mich aber nicht davon ab lokal weiter zu Entwickeln (Apache2, PHP, MySQL, usw. ist lokal installiert). Mit jQuery über einen CDN wär das aber ein Problem...
Mit XAMPP Portable kann man übrigends auch dynamische Webseiten von einem USB Stick präsentieren, auch wenn es komfortabler ist einfach den eigenen Laptop auszupacken :)

[Geistesgegenwart]

saithis schrieb:
--------------------------------------------------------------------------------
> Und was bringt einem ein Verfügbarer CDN, wenn der eigene Server mit der
> Webseite offline ist? Nix! (Zumindest wenn alles auf einem Server liegt,
> was ja oft genug der Fall ist.)

Richtig. Und dann nützt dir die Modularisierungsfunktion von jQuery aber auch nix.

> So konstruiert ist das garnicht. Wenn bei mir in der Uni wieder mal das
> WLAN spinnt, gibts teils Stunden lang kein Internet. Das hält mich aber
> nicht davon ab lokal weiter zu Entwickeln (Apache2, PHP, MySQL, usw. ist
> lokal installiert). Mit jQuery über einen CDN wär das aber ein Problem...

Und auch hier bringt dir die Modularisierungsfunktion wieder nix. Ein 20 kb jQuery läd wie ich schon schrieb von HDD/USB Stick genauso schnell wie ein 200kb jQuery - es gibt kein Messbaren unterschied.

Ergo: Modularisierung in jQuery ist wieder unnötig, worauf ich ja hinaus wollte.

[Sammie]

Geistesgegenwart schrieb:
--------------------------------------------------------------------------------
> Sammie schrieb:
>
> CDN haben aber definitiv eine bessere Verfügbarkeit als dein eigener
> Server, genau DAS ist es nämlich womit CDNs ihr Geld verdienen.

Verfügbarkeit ist doch gar nicht relevant. Wenn jemand meine Seite aufruft, dann ist sie auch verfügbar. Ist der CDN jedoch down während man meine Seite aufruft, dann hab ich ein Problem und benötige ein Fallbackscript. Wenn meine Domain nicht verfügbar wäre, dann ists ja sowieso egal, weil die Seite grundsätzlich nicht geht und der User eh nichts sieht. ^^

>
> Ist für DNS doch egal ob die Server in Amerika oder Mogadischu stehen, die
> jQuery mirror von google und microsoft stehen in so ziemlich jedem DNS
> cache, auch in dem Cache deines deutschen Internetanbieters. Der DNS lookup
> dauert daher zu 99.9999% nicht länger als ein DNS lookup zu einem deutschen
> Server. Im Gegenteil, bei wenig besuchten Websites dürfte dein DNS record
> nicht in den Caches vorgehalten sein (vorausgesetzt dein jQuery script
> liegt nicht unter der gleichen domain wie deine website natürlich).
>

Zusätzliche Lookups auf einer andere Seite dauern immer länger als wenn alles von der gleichen Domain kommt und in der Regel hat man ja alles auf einer Seite, genau das bringt ja den Geschwindigkeitsvorteil beim Laden.

>
> Gerade getestet, weder google noch microsoft setzen einen Cookie bei der
> Abfrage. Und wenn du soweit gehst, Google oder MS schlagartige
> "Bösartigkeit" vorzuwerfen, z.B dass sie Schadcode in das .js script
> einschleusen oder übernacht auf einmal cookies verwenden, dann musst du
> auch davon ausgehen dass dein Webhoster deine Skripte serverseitig
> manipuliert oder über reverse proxies cookies einschleusst.
>
Natürlich setzen sie bei der Abfrage des JS keinen Cookie - aber in der Regel haben die User alle schon längst Cookies durch die tägliche Nutzung ihrer Suchmaschine, oder gar deren Anmeldung bei irgendeines Googledienstes, sei es jetzt Hotmail, GooglePlus oder sonst einem Dienst. Und dieser Cookie kann man auch abfragen, wenn mal wollte. Und von Schadcode hab ich auch gar nichts geschrieben, aber auch bei sowas hab ich lieber selbst Kontrolle das ganze via IDS zu überwachen, als mich auf Dienste Dritter zu verlassen.

> Abgesehen davon dass das ein sehr unrealistischer konstruierter fall ist
> (wer hat heute noch statische Websites?), würde das volle jQuery script
> (also unmodularisiert) von einem USB Stick so schnell geladen, das kein
> Messbarer (ja und ich meine Messbar und nicht Spürbar) unterschied
> bestünde. Zudem müsste der Rechner auf dem Präsentiert wird, über keine
> Internetanbindung verfügen (die .HTML datei kann ja vom stick kommen).

Entwickler nutzen dafür XAMPP mit USB Lite - d.h einem lokalem Apache Server, der direkt vom Stick aus läuft. Sie können so dem Kunden die Webseite auch auf einem fremden Notebook präsentieren, ohne dass Zugang zum Internet bestehen oder man selbst ein Notebook bei sich haben muss. Das ist ein ganz normales Szenario, was vielerorts eingesetzt wird und gar nichts unrealistisches.

> Und auch hier bringt dir die Modularisierungsfunktion wieder nix. Ein 20 kb jQuery
> läd wie ich schon schrieb von HDD/USB Stick genauso schnell wie ein 200kb jQuery
> - es gibt kein Messbaren unterschied.

Ja lokal nicht, aber wenn die Webseite dann letztendlich online ist, gibt es schon einen Unterschied zwischen 20 und 200 kb.. nicht nur von den Ladezeiten her, sondern auch von Seiten des JS-Interpreters im Browser, auch wenn es sich nur im Millisekundenbereich abspielt.



1 mal bearbeitet, zuletzt am 10.08.12 12:39 durch Sammie.

[crash]

Mit einem anständigen Build-System (Phing) hättest du lokal deine lokale jQuery.js und online http://code.google.com/, statt einer so so sinnlosen Diskussion. ;)

[Geistesgegenwart]

Sammie schrieb:
--------------------------------------------------------------------------------
> Geistesgegenwart schrieb:
> ---------------------------------------------------------------------------
> -----
> > Sammie schrieb:
> >
> > CDN haben aber definitiv eine bessere Verfügbarkeit als dein eigener
> > Server, genau DAS ist es nämlich womit CDNs ihr Geld verdienen.
>
> Verfügbarkeit ist doch gar nicht relevant. Wenn jemand meine Seite aufruft,
> dann ist sie auch verfügbar. Ist der CDN jedoch down während man meine
> Seite aufruft, dann hab ich ein Problem und benötige ein Fallbackscript.
> Wenn meine Domain nicht verfügbar wäre, dann ists ja sowieso egal, weil die
> Seite grundsätzlich nicht geht und der User eh nichts sieht. ^^

Wenn du Amazon oder eBay bist, macht es sinn, dein eigenes .js selbst zu hosten. Wenn du aber klein bis mittelständisch bist, und nur einen bis wenige Server selbst betreibst, hast du vielleicht eine Verfügbarkeit von 99.99% (bei guten SLA). Die .js Skripte auf CDNs dürften auf 99.9999% kommen. Das heisst, das ein Ausfall DEINER Server um den Faktor 100 mal wahrscheinlicher ist, als der Ausfall der CDNs. Willst du also hohe verfügbarkeit, solltest du deine SLAs erweitern, und nicht anfangen jQuery selbst zu hosten.


> Natürlich setzen sie bei der Abfrage des JS keinen Cookie - aber in der
> Regel haben die User alle schon längst Cookies durch die tägliche Nutzung
> ihrer Suchmaschine, oder gar deren Anmeldung bei irgendeines
> Googledienstes, sei es jetzt Hotmail, GooglePlus oder sonst einem Dienst.
> Und dieser Cookie kann man auch abfragen, wenn mal wollte.

Du unterstellst hier Google/Microsoft die erwähnte "schlagartige Bösartigkeit", weigerst dich aber Unternehmen wie Strato/1&1/Hetzner so eine Bösartigkeit zu unterstellen, die genauso Cookies und Zugriffe auswerten könnten.

> Schadcode hab ich auch gar nichts geschrieben, aber auch bei sowas hab ich
> lieber selbst Kontrolle das ganze via IDS zu überwachen, als mich auf
> Dienste Dritter zu verlassen.

Dein Hoster ist ein Dritter - der kann sowohl dein .js manipulieren, als auch dein IDS. Du *musst* dich also immer auf Dienste Dritter verlassen. Und ich Schätze die Chance, das jemand *dein* System hackt und die .js manipuliert höher, als dass dies bei Google/Microsoft CDNs passiert.

[vlad_tepesch]

Geistesgegenwart schrieb:
--------------------------------------------------------------------------------
> Selbstveränstlich mein ich Modulrität.
*g* war das jetzt Absicht?

[Jenz]

Ich will aber nix was bei google verlinkt wird, weil ich damit deren Statistiken füttere und wie hier einige auch schon schrieben, ich unabhängig sein will bei Serverausfällen von fremden Webseiten.

Und wenn ich jquery jetzt modular zusammenstellen kann, dann freut mich das außerordentlich, denn zuletzt ist es schon recht groß geworden und es wird ja nicht als einziges geladen, CSS-Dateien, Bilder, HTML, irgendwelche jquery Plugins, etc. da kommt schon was zusammen, auch wenn alle Dateien an sich klein sind. Und ich hasse es wie zB bei buffed.de ne Stunde zu warten bis alles geladen ist. Dat muss ratzfatz gehen ;)

Aber vielleicht gibt es ja auch beides, eine Vollversion wo nach wie vor alles drin ist und die Möglichkeit sich eben nur das zusammenzustellen was man braucht.