Der neue Script-Tag in HTML 5

Eine nette kleine Änderung in HTML 5, die ich bisher übersehen habe: Auch das Script-Tag wurde überarbeitet und bietet gleich drei interessante Neuheiten.

Optionales Type-Attribut

Vorbei ist die Zeit von <script type="text/javascript">: Der Typ, welcher in rund 100% aller Fälle immer auf Javascript gesetzt werden musste, ist endlich optional. Das schöne daran: Alte Browser hatten ohnehin nie Probleme, wenn das Attribut fehlte.

Viele Code-Schreiber entschieden sich daher schon früh, das Attribut wegzulassen. Für mich fühlte es sich das falsch an. Standards zu brechen „weil es geht“ und etwas praktisch ist. Auch bei der Apacheerweiterung Modpagespeed gab es des öfteren Diskussionen über das Thema. Nun ist dieses Thema also keines mehr: Es funktioniert überall und ist valide.

Asynchrones Ausführen von JS: <script async>

Mit dem Async-Attribut kann man den JS-Code einer Datei asynchron ausführen. Dies bedeutet, dass vor allem aufwendige Berechnungen nicht mehr dazu führen, dass der Browser einfriert. Bisher habe ich mir in solchen Situationen mit einem Timeout geholfen, so dass einzelne Code-Teile immer wieder mit einer Auszeit gestartet wurden.

function recursive(a) {
  window.setTimeout(function(){
    a += 1;
    return recursive(a);
  }, 0);
}

Das Beispiel zeigt die Idee und keinen sinnvollen Anwendungsfall…

Das „normale“ Skript kann dann mit dem asynchron ausgeführten Code mittels Nachrichtenaustausch kommunizieren. Allerdings scheint das alles noch sehr frisch zu sein, ich konnte auf die Schnelle keine gute Anleitung dafür finden.

Auf die Verbreitung darf man hier noch lange nicht setzen. Insofern ist dieses Attribut wohl leider noch nicht interessant. Ähnlich wie beim dritten Kandidaten…

Nicht blockierendes Laden dank <script defer>

Ein bekanntes Problem ist es, dass das Laden einer Javascript-Datei das Rendern der Website blockiert. Dies fällt vor allem beim klassischem Script-im-Head-Prinzip auf. Mit dem neuen Attribut defer gibt es endlich Abhilfe: Ist dieses mit angegeben, weiß der Browser, dass er auch während das Skript geladen wird schon einmal weitermachen kann.

Solange die breite Masse der Browser dies nicht unterstützen, gibt es hier einen simplen und effektiven Workaround: Man packt die Scripts einfach ans Ende, direkt vor den schließenden Body:

  <!-- content... -->
  <script src="script.js"></script>
</body>

Funktioniert überall und tut nicht weh. So gesehen drängt die Verbreitung des Defer-Attributs nicht wirklich…

Links

8 Kommentare

  1. Hi,
    du verweißt auf w3schools. Ich möchte dir natürlich nichts verbieten und es steht dir selbstverständlich völlig frei, wo du hin verlinkst, allerdings ist w3schools eine nicht gerade seriöse Quelle und hat auf gar keinen Fall etwas mit dem W3C zutun!!

    Falls dir das noch nicht bekannt war, wäre ein Blick hierauf sicherlich nicht verkehrt:
    http://w3fools.com/

    Besten Gruß
    Andreas

  2. Dann danke ich dir, dass du es mir nicht verbietest 😉 Die Quelle ist erreichbar, zeigt was sie soll und ist mindestens weitgehend korrekt. Dass W3-Schools nichts mit der W3C zu tun hat, ist richtig. Ihnen Seriosität abzusprechen finde ich aber falsch.

  3. Wird ein Javascript zweimal geladen, wenn ich das im Quellcode zweimal aufführ???

    wenn z.b. folgender Code zweimal im Code steht:

  4. Ich hätte da nur eine Frage, ist es möglich ein Shell Script per HTML5 auszuführen? Ich meine das ich mir eine Art GUI per Html 5 baue und z.b per Button ein Shell-Script ausführe. Das ganze ist nur als eine Art offline GUI gedacht.

  5. Hallo Günther, HTML beschreibt nach wie vor nur die Oberfläche. Für den Systemzugriff brauchst du eine zusätzliche Schicht aus z.B. Node oder PHP.

Kommentare sind geschlossen.