externes Script onload einfügen, erst nach alert verfügbar

[37001]

Hallo,

ich versuche ein externes Script erst im onload-Ereignis zu laden, der Zugriff auf Funktionen darin klappt allerdings nur, wenn ich zuvor ein alert aufrufe.

<script type="text/javascript" id="InitScript"></script>
<script>
window.addEventListener("load", Initfuncs, false);
window.addEventListener("load", fInit, false);

function Initfuncs () {
  var fjs = document.getElementById("InitScript");
  js = document.createElement("script");
  js.src = "functions.js";
  fjs.parentNode.insertBefore(js, fjs);

//  funcInit(document); //ist auch hier nicht verfügbar ohne alert
}

function fInit () {
  alert("fInit"); //ohne ist funcinit nicht definiert
  funcInit(document); // aus functions.js
}
</script>

gibt es eine andere Funktion, die statt alert den Zweck erfüllt?

[Christian Marquardt]

Es gbit schöne Bibliotheken, bei denen das ganz elegant gelöst ist und die auch die weitere Berabeitung vereinfachen -> JQuery

Des Weiteren würde ich die Funktion im onload des Body Elementes ausführen lassen

[fanderlf]

Warum willst du denn das Skript erst im onload laden? Ausserdem gibt es mittlerweile auch Modularisierungsframeworks die sich um asynchrones nachladen von Skripts kümmern (z.B. RequireJS).

Insgesamt vermute ich dass wenn das Script Tag eingefügt wird dieses nachträglich asynchron geladen wird. Wenn ich mich recht erinnere updated der Browser nicht immer direkt das DOM, sondern das geschieht asynchron aus performance Gründen. Wenn Du Kontrolle über den Ablauf haben willst, dann würde ich das ganze über einen Http Request holen und auf dem Script content eval() ausführen. Ausserdem würde ich für das ganze JQuery oder eine ähnliche Library verwenden. Für den Einstieg ist mit Sicherheit JQuery zu empfehlen, weil es dort mit Abstand am meisten Doku im Netz gibt. Bei etwas mehr Erfahrung kann man auch auf kleinere Frameworks umsteigen, weil JQuery an sich schon ein ziemliches Monster ist.

[37001]

Danke für eure Antworten,

wollte die Scripte erst hinterher aufrufen, weil das Google Pagespeed beanstandet hat. Wenn ich deswegen jquery einbaue wär ich für meinen Fall wahrscheinlich übers Ziel hinaus, da das Script doch eher klein ist.
hatte aber sowieso vor, mich mal noch etwas in jquery einzuarbeiten.

[fanderlf]

Wenn Du nur ein kleines Script hast dann finde ich das vollkommen unnötig. Man muss immer Kosten/Nutzen Verhältnis abwägen. Du darfst auch nicht vergessen, dass diese Scripts nur bei ersten Laden der Seite vom Server geholt werden. Danach werden sie sowieso aus dem Cache geladen. Hier sehe ich kein großes Verbesserungspotential. Ich würde mir dann eher Gedanken um ein vernünftiges Caching machen. So sollte sich z.B. bei jeder Änderung in einem File auch der Filename des geladenen Files ändert, damit alle Benutzer auch sofort das neue Script bekommen. Wenn man das nicht bedenkt kann man richtig üble Seiteneffekte erzeugen.

[Christian Marquardt]

Es ist Aufgabe des Browsers festzustellen, ob die Datei auf dem Server noch die ist, die er im Cache hat. Das machen die Browser nciht nur am Filenamen fest.. Das umbenennen halte ich für wenig zielführend, da man da u.U. in mehreren Dateien/Projekten tun muss.

[fanderlf]

Es ist Aufgabe des Browsers festzustellen, ob die Datei auf dem Server noch die ist, die er im Cache hat. Das machen die Browser nciht nur am Filenamen fest.. Das umbenennen halte ich für wenig zielführend, da man da u.U. in mehreren Dateien/Projekten tun muss.

Man kann sich z.B. eine Kleinigkeit schreiben die immer den Hash an das Script anhängt. In den meisten Packaging Lösungen funktioniert das sowieso so. Wenn ich ein File im Browser 10 mal anfordere und es sich nicht ändert, dann wird der Browser hoffentlich annehmen dass er es cachen kann. Und sobald er es im Cache hat wird er wohl auch nicht mehr am Server nachfragen ob denn eine neuere Version da ist.

[Christian Marquardt]

der Browser muss bei jeder Datei pruefen,ob nicht etwas neueres vorhanden ist

[fanderlf]

der Browser muss bei jeder Datei pruefen,ob nicht etwas neueres vorhanden ist

Also das tut er definitiv nicht wir hatten schon einen Bug in der Richtung. Das hängt ganz von den Caching Einstellungen ab.Wenn jeder Request IMMER beim richtigen Server landen würde, dann würde der Traffic im Internet wohl zerplatzen. Es gibt z.B. auch Proxies dazwischen die cachen. Wenn jeder Request immer zum Quellserver geht, dann kann ich mir sowas wie Proxies auch sparen.

Das merkt man ja selbst beim lokalen Entwickeln. Benutze ich nicht immer strg + F5 bekomme ich teilweise ältere Versionen von Javascripts selbst wenn eine neuere Version auf dem Server verfügbar ist.

Bei generierten Webseiten wie z.B. beim .Net Framework werden diese Header standardmäßig durch das Framework so gesetzt dass jeder Request wieder beim Server landet. Für statische Files sollte man das ab einem gewissen Traffic Level allerdings nicht mehr so machen. Wir haben eine komplett getrennte Anwendung die statische Inhalte ausliefert.

[Christian Marquardt]

Richtig, das hängt von den Einstellungen des Browser ab. Die Proxies müssen auch nach einer Strategie ihre Inhalte erneuern. Hmmm, habe wenig Probleme mit gecachten Inhalten....

[fanderlf]

Die Strategie steuert aber der Server und nicht der Browser (Stichwort: Cachine Headers). Der Browser kann auch Caching Headers mitgeben und eine frische Kopie der Datei anfordern. Standardmäßig würde ich mich aber nicht drauf verlassen dass das bei jedem Request passiert.
Probleme an der Stelle sieht der Entwickler sowieso meistens nicht. Das sehen eher die Kunden draussen die nicht ständig CTRL + F5 drücken Es ist auch schwierig diese Fehler mitzubekommen, weil in solchen Fällen eigentlich die Kunden anrufen müssten. Wir haben ein Logging für Javascript Fehler, was bei einem Fehler einen Meldung an uns schickt.

[Christian Marquardt]

Das sehe ich anders. Der Server kann "Wünsche" äußern, was und wie gecacht wird, aber es bestimmt der Client. Wenn ich kein Caching will, kann der Server das x-Mal in den Headern schreiben; es wird nicht gecacht.

[fanderlf]

Aber warum sollte denn standardmäßig der Browser das nicht akzeptieren? Dafür gibt es keinen Grund und es verschlechtert die Performance der Seite. Am Besten weiss wohl der Autor der Seite was gecached werden soll und was nicht.

Dazu kommen auch noch die Proxy Server zwischen Browser und Webserver, die auch eine eigene Caching Logik implementiert haben.

[Christian Marquardt]

"Aber warum sollte denn standardmäßig der Browser das nicht akzeptieren? " -> Die Frage stellt sich so nicht. Es ist halt möglich. Jeder kann das einstellen wie ermöchte - aus welchen Gründen auch immer. Insofern kann nicht unterstellt werden, dass immer gecacht wird oder eben nicht gecacht wird. Das muss berücksichtigt werden. Hier bleibt dann m.E. auch wenig Spielraum für Cachestrategien.

[fanderlf]

Du kannst aber davon ausgehen dass sich der normalo Benutzer nicht mit Cachestrategien im Browser beschäftigt. Deswegen sind wahrscheinlich die Standardeinstellungen im Browser aktiv und er drückt nicht ständig CTRL + F5. In den Standardeinstellungen wird auf jeden Fall der Header vom Server akzeptiert. Sind keine Header vorhanden benutzt der Browser seine eigenen Caching Strategien. Für eine Webseite mit hohem Traffic lohnt es sich also richtig sich Gedanken über Caching zu machen, da einem auch das Netzwerk vor dem eigenen Netzwerk (Proxies usw.) viel Traffic und Arbeit abnehmen sofern das Caching funktioniert. Und dafür muss auch der Browser die Caching Header des Servers akzeptieren.
Wenn jemand das explizit nicht tut ist das kein Problem, aber das sind eben Einzelfälle oder schaltest Du auf Deinem nicht Entwickler Rechner in allen Browsern das Caching ab?