HTML5-Tutorium: JavaScript: Hello World 05: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
(42 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
{{HTML5-Tutorium:JavaScript:HelloWorld:Menü}}
{{HTML5-Tutorium:JavaScript:HelloWorld:Menü}}


'''Musterlösung''': [https://glossar.hs-augsburg.de/beispiel/tutorium/2021/hello_world/wk_hello_world_05/web/index.html <code>index.html</code>]<br/>
'''Musterlösung'''<br/>
(Git-Repository: [https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05.git wk_hello_world_05], [https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05/-/tree/v00 Version 00], [https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05/-/tree/v01 Version 01], [https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05/-/tree/v02 Version 02], [https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05/-/tree/v03 Version 03], [https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05/-/tree/v04 Version 04])
v03a: [https://glossar.hs-augsburg.de/beispiel/tutorium/2023/wk_hello_world/wk_hello_world_05/web_v03a/index.html <code>index.html</code>]<br/>
v03b: [https://glossar.hs-augsburg.de/beispiel/tutorium/2023/wk_hello_world/wk_hello_world_05/web_v03b/index.html <code>index.html</code>]<br/>
v04a: [https://glossar.hs-augsburg.de/beispiel/tutorium/2023/wk_hello_world/wk_hello_world_05/web_v04a/index.html <code>index.html</code>]<br/>
v04b: [https://glossar.hs-augsburg.de/beispiel/tutorium/2023/wk_hello_world/wk_hello_world_05/web_v04b/index.html <code>index.html</code>]<br/>
v05: [https://glossar.hs-augsburg.de/beispiel/tutorium/2023/wk_hello_world/wk_hello_world_05/web_v05/index.html <code>index.html</code>] (Modularisierung von <code>greet.js</code> analog zu [[HTML5-Tutorium: JavaScript: Hello World 04|Hello World 04]] v02)<br/>
v06: [https://glossar.hs-augsburg.de/beispiel/tutorium/2023/wk_hello_world/wk_hello_world_05/web_v06/index.html <code>index.html</code>] (Konfiguration mittels JSON analog zu [[HTML5-Tutorium: JavaScript: Hello World 04|Hello World 04]] v03)<br/>
[{{Git-Server}}/kowa/wk_hello_world_05.git Git-Repository]


==Anwendungsfälle (Use Cases)==
==Anwendungsfälle (Use Cases)==
Gegenüber dem [[HTML5-Tutorium:_JavaScript:_Hello_World_03|dritten Teil des Tutoriums]]
Gegenüber dem [[HTML5-Tutorium:_JavaScript:_Hello_World_03|dritten (und dem vierten) Teil des Tutoriums]]
ändern sich die die Anwendungsfälle nicht. Die Anwendung leistet also genau dasselbe wie zuvor.
ändern sich die die Anwendungsfälle nicht. Die Anwendung leistet also genau dasselbe wie zuvor.


In diesem Teil des Tutoriums geht es darum, die Anwendung mittels [[Vite]]<ref name="vite">[https://vitejs.dev/ Vite-Homepage]</ref> automatisch für den Server-Betrieb zu optimieren, sodass möglichst wenige, möglichst kleine Dateien zum Client übertragen werden.
In diesem Teil des Tutoriums geht es darum, die Anwendung mittels [[Vite|Vite 4]]<ref name="vite">[https://vitejs.dev/ Vite-Homepage]</ref> automatisch für den Server-Betrieb zu optimieren, sodass möglichst wenige, möglichst kleine Dateien zum Client übertragen werden.
 
Im Tutorium wird „Vite 4“ verwendet.


==JavaScript Module Bundlers==
==JavaScript Module Bundlers==
Zeile 37: Zeile 41:
</source>
</source>


Öffnen Sie das Projekt in VSC und öffnen Sie in VSC ein zugehöriges Terminal (für den neuen Projektordner).
Öffnen Sie das Projekt in Visual Studio Code (VSC) und öffnen Sie in VSC ein zugehöriges Terminal (für den neuen Projektordner).
Führen Sie folgende Befehle aus:
Führen Sie folgende Befehle aus:


Zeile 78: Zeile 82:
export default
export default
{ root:      'src',  
{ root:      'src',  
   publicDir: '../public',
   publicDir: '../public', 
  base:      '',
   build:  
   build:  
   { outDir:  '../web',
   { outDir:  '../web',
     minify:  true
     minify:  true,
   }   
   }   
}
}
Zeile 87: Zeile 92:
Diese legt Folgendes fest:
Diese legt Folgendes fest:
* Der Root-Ordner des Projekts befindet sich im Unterordner <code>src</code> des Projektordners. Dort hinein kommen die ganzen HTML-/CSS-/JS-Dateien und Medien, die unter Kontrolle von Vite stehen sollen.
* Der Root-Ordner des Projekts befindet sich im Unterordner <code>src</code> des Projektordners. Dort hinein kommen die ganzen HTML-/CSS-/JS-Dateien und Medien, die unter Kontrolle von Vite stehen sollen.
* Der Ordner <code>public</code>, in dem alle Dateien enthalten sind, die von Vite '''nicht''' verändert werden, befindet sich weiterhin im Unterordner <code>public</code> des Projektordners. Vom Projektordner <code>src</code> aus gesehen, leigt er außerhalb von <code>src</code> eine Ebene höher. Das heißt, er befindet sich in der Ordnerhierarchie auf derselben Ebene wie <code>src</code> selbst.
* Der Ordner <code>public</code>, in dem alle Dateien enthalten sind, die von Vite '''nicht''' verändert werden, befindet sich weiterhin im Unterordner <code>public</code> des Projektordners. Vom Projektordner <code>src</code> aus gesehen, liegt er außerhalb von <code>src</code> eine Ebene höher. Das heißt, er befindet sich in der Ordnerhierarchie auf derselben Ebene wie <code>src</code> selbst.
* Die Option <code>base</code> enthält einen String, der vor jeden Asset-Pfad (<code>.css</code>, <code>.js</code>, <code>.jpg</code> ...) eingefügt wird. Standardmäßig lautet der Wert <code>'/'</code>. Das heißt, die zugehörigen Assetpfade sind absolut. Sie beginnen stets beim Top-Level-Verzeichnis der Web-App. Mit der Option <code>base: &#39;&#39;</code> legt man fest, dass die Pfade relativ sind. Das hat den Vorteil, dass man die Web-App in einen Unterordner einer anderen Web-App legen kann. Beispielsweise liegen die Musterlösungen dieser Aufgabe in Underordnern des Glossars: [https://glossar.hs-augsburg.de/beispiel/tutorium/2023/wk_hello_world/wk_hello_world_05/web/index.html <code>index.html</code>], [https://glossar.hs-augsburg.de/beispiel/tutorium/2023/wk_hello_world/wk_hello_world_05/web_v03a/index.html <code>index.html (v03a)</code>] etc.
* Wenn Sie das Projekt mittels <code>npm run build</code> für den Produktivbetrieb erstellen lassen, wird das Ergebnis in den Ordner <code>web</code> geschrieben. Dieser Ordner liegt ebenfalls auf derselben Ebene wie <code>src</code>.
* Wenn Sie das Projekt mittels <code>npm run build</code> für den Produktivbetrieb erstellen lassen, wird das Ergebnis in den Ordner <code>web</code> geschrieben. Dieser Ordner liegt ebenfalls auf derselben Ebene wie <code>src</code>.
* Durch <code>npm run build</code> wird komprimierter (minimized) Code erzeugt. Das gilt allerdings nicht für HTML-Dateien, sondern nur für CSS-, JS-/TS- und SVG-Dateien.
* Durch <code>npm run build</code> wird komprimierter (minimized) Code erzeugt. Das gilt allerdings nicht für HTML-Dateien, sondern nur für CSS-, JavaScript-/TypeScript- und SVG-Dateien.


Sie sollten in der Datei <code>package.json</code> im Skript <code>build</code> auch noch die Option <code>--emptyOutDir</code> ergänzen,  
Sie sollten in der Datei <code>package.json</code> im Skript <code>build</code> auch noch die Option <code>--emptyOutDir</code> ergänzen,  
damit der Web-Ordner vor jedem Rebuild geleert wird. Ohne diese Option sammen sich im Web-Ordner im Laufe der Zeit Dateileichen an.
damit der Web-Ordner vor jedem Rebuild geleert wird. Ohne diese Option sammeln sich im Web-Ordner im Laufe der Zeit Dateileichen an.


<source lang="javascript">
<source lang="javascript">
Zeile 100: Zeile 106:
=== Restrukturierung des Projekts ===
=== Restrukturierung des Projekts ===


Wenn man nun das Projekt mittels <code>npm run dev</code> startet, wird man nichts sehen. Der Grund ist, dass der Browser keine Datei <code>index.html</code> findet. Der Grund ist, dass der Vite-Server nun den Inhalt des Ordners <code>src</code> ausliefert. Diesen gibt es aber noch gar nicht.  
Wenn man nun das Projekt mittels <code>npm run dev</code> startet, wird man nichts sehen. Der Grund ist, dass der Browser keine Datei <code>index.html</code> findet, da der Vite-Server nun den Inhalt des Ordners <code>src</code> ausliefert. Diesen gibt es aber noch gar nicht.  


Die Ordnerstruktur des Projekts muss an die Konfigurationsdatei angepasst werden.
Die Ordnerstruktur des Projekts muss an die Konfigurationsdatei angepasst werden.
Zeile 127: Zeile 133:
</pre>  
</pre>  


Das Ergebnis ist, dass Sie Fehlermeldungen erhalten, dass bestimmte Dateien nicht gefunden werden.
Das Ergebnis ist, dass Sie Fehlermeldungen erhalten, weil bestimmte Dateien nicht gefunden werden.
Das liegt daran, dass sich die Ordnerstruktur aus Sicht der Dateien im <code>src</code>-Ordner geändert haben.  
Das liegt daran, dass sich die Ordnerstruktur aus Sicht der Dateien im <code>src</code>-Ordner geändert haben.  
Die Pfade innerhalb der Dateien in diesem Ordner müssen daher angepasst werden.
Die Pfade innerhalb der Dateien in diesem Ordner müssen daher angepasst werden.
Zeile 133: Zeile 139:
Die Pfade zu Dateien im <code>public</code>-Ordner bleiben gleich. Aus Sicht der Dateien im <code>src</code>-Ordner
Die Pfade zu Dateien im <code>public</code>-Ordner bleiben gleich. Aus Sicht der Dateien im <code>src</code>-Ordner
befinden sie sich in der Root des Web-Auftritts. Im <code>public</code>-Ordner liegt in diesem Beispiel nur die Datei  
befinden sie sich in der Root des Web-Auftritts. Im <code>public</code>-Ordner liegt in diesem Beispiel nur die Datei  
<code>vite.svg</code>. Deren Pfade änder sic nicht, daher bleibt in der Datei code>src/index.html</code> und <code>src/js/main.js</code> die Zeilen
<code>vite.svg</code>. Deren Pfade ändern sich nicht, daher bleiben in den Dateien <code>src/index.html</code> und <code>src/js/main.js</code> die Zeilen
      
      
<source lang="javascript">
<source lang="javascript">
Zeile 139: Zeile 145:
</source>
</source>


und
bzw.


<source lang="javascript">
<source lang="javascript">
Zeile 158: Zeile 164:


Nehmen Sie geeignete Änderungen vor (sofern sie von VSC nicht automatisch durchgeführt wurden).  
Nehmen Sie geeignete Änderungen vor (sofern sie von VSC nicht automatisch durchgeführt wurden).  
Zum Schluss sollte die Anwendung wieder laufen.
Modifizieren und testen Sie die App mit Hilfe von <code>npm run dev</code> solange, bis sie fehlerfrei läuft.
 
Modifizieren und Testen Sie die App solange mit Hilfe von <code>npm run dev</code> solange, bis sie fehlerfrei läuft.


== Packen der Web-Anwendung (Build, [https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05/-/tree/v02 Version 02]) ==
== Packen der Web-Anwendung (Build, [https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05/-/tree/v02 Version 02]) ==
Zeile 170: Zeile 174:
Seine Stärke spielt Vite aus, wenn wir das Projekt packen. Das bedeutet, dass die Anzahl der Dateien  
Seine Stärke spielt Vite aus, wenn wir das Projekt packen. Das bedeutet, dass die Anzahl der Dateien  
reduziert wird und überflüssige Leerzeichen, Zeilenumbrüche, Kommentare etc. entfernt werden.
reduziert wird und überflüssige Leerzeichen, Zeilenumbrüche, Kommentare etc. entfernt werden.
Dadurch reduziert sich die Anzahl der Bytes, die zu einem Client (Brwoser) übertragen werden müssen, erheblich.
Dadurch reduziert sich die Anzahl der Bytes, die zu einem Client (Browser) übertragen werden müssen, erheblich.
Insbesondere für Smartphones mit eine geringen Datenvolumen profitieren davon.
Insbesondere für Smartphones mit einem geringen Datenvolumen profitieren davon.


Intelligente Frameworks wie [[Vue]], [[Svelte]] oder [[React]] oder React gehen sogar noch einen Schritt weiter  
Intelligente Frameworks wie [[Vue]], [[Svelte]] oder [[React]] oder React gehen sogar noch einen Schritt weiter  
und laden nur die Teile einer Web-Seite (nicht Web-Site!) nach, die sich geändert haben. JavaScript-Biliotheken werden so definiert,  
und laden nur die Teile einer Web-Seite (nicht Web-Site!) nach, die sich geändert haben. JavaScript-Bibliotheken werden so definiert,  
dass sie für eine ganze Web-Site nur einmal geladen werden müssen und für verschiedene Seiten wiederverwendet werden können.
dass sie für eine ganze Web-Site nur einmal geladen werden müssen und für verschiedene Seiten wiederverwendet werden können.
Hier spielen Web-Frameworks ihre Stärken aus. Sie stützen sich dabei auf Bundler wie Vite oder Webpack.
Hier spielen Web-Frameworks ihre Stärken aus. Sie stützen sich dabei auf Bundler wie Vite oder Webpack.
Zeile 196: Zeile 200:


Wenn Sie die Produktivversion mittels <code>npm run build</code> erstellen möchten, muss es eine Datei <code>index.html</code> geben.
Wenn Sie die Produktivversion mittels <code>npm run build</code> erstellen möchten, muss es eine Datei <code>index.html</code> geben.
Defaultmäßig wird nur diese in den Ordner <code>web</code> übernommen. Das heißt, wenn man beispielsweise die [https://gitlab.multimedia.hs-augsburg.de/kowa/WK_HelloWorld04/-/tree/master/web Musterlösung von von WK_HelloWorld04] in den (zuvor geleerten) Ordner <code>src</code> kopiert,
Defaultmäßig wird nur diese in den Ordner <code>build</code> übernommen. Das heißt, wenn man beispielsweise die [https://gitlab.multimedia.hs-augsburg.de/kowa/WK_HelloWorld04/-/tree/master/web Musterlösung von von WK_HelloWorld04] in den (zuvor geleerten) Ordner <code>src</code> kopiert,
funktioniert diese Anwendung zwar im Developermoduls (<code>npm run dev</code>), aber nicht im Produktivmodus. Wenn man (für dieses Beispiel)  
funktioniert diese Anwendung zwar im Developermoduls (<code>npm run dev</code>), aber nicht im Produktivmodus. Wenn man (für dieses Beispiel)  
<code>npm run build</code> ausführt, erhält man die Fehlermeldung
<code>npm run build</code> ausführt, erhält man die Fehlermeldung
Zeile 204: Zeile 208:
</source>
</source>


Die Lösung ist in diesem Fall ganz einfach. Eine der drei Dateien <code>index0.html</code>, <code>index1.html</code> oder <code>index2.html</code> wird in <code>index.html</code> umbenannt. Im Ordner <code>web</code> wird dann durch <code>npm run build</code> auch nur eine HTML-Datei namens <code>index.html</code> erzeugt. Das ist für unsere Zwecke in Ordnung, da wir mit Hilfe von Vue eine Single-Page-Anwendung erstellen werden.  
Das Problem ist, dass es keine Datei <code>index.html</code> gibt.
Die Lösung ist in diesem Fall ganz einfach. Nennen Sie eine der drei Dateien <code>index0.html</code>, <code>index1.html</code> oder <code>index2.html</code> in <code>index.html</code> um. Im Ordner <code>web</code> wird dann durch <code>npm run build</code> auch nur eine HTML-Datei namens <code>index.html</code> erzeugt. Das ist für unsere Zwecke in Ordnung, da wir mit Hilfe von Vue eine Single-Page-Anwendung erstellen werden.  
Die Inhalte einer derartigen Anwendung werden per JavaScript nachgeladen. Man benötigt also tatsächlich nur eine HTML-Datei.
Die Inhalte einer derartigen Anwendung werden per JavaScript nachgeladen. Man benötigt also tatsächlich nur eine HTML-Datei.


Zeile 215: Zeile 220:
* https://rollupjs.org/configuration-options/#input
* https://rollupjs.org/configuration-options/#input


== HTML-Kompression ([https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05/-/tree/v04 Version 04]) ==
== Verbesserungen ([https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05/-/tree/v04 Version 04]) ==
 
===  <code>head.css</code> inline und <code>body.css</code> dynamisch laden ===  


Zur Erinnerung:
Zur Erinnerung:
* In <code>head.css</code> stehen möglichst wenig CSS-Anweisungen. Sie sollten ausreichen, um die aktuelle Seite “above the fold” („über dem Zeitungsknick“) fehlerfrei zu rendern. Das heißt, es sollte alles korrekt gerendert werden, was nach dem Laden im größtmöglichen Browserfenster sichtbar ist.  
* In <code>head.css</code> stehen möglichst wenig CSS-Anweisungen. Sie sollten ausreichen, um die aktuelle Seite “above the fold” („über dem Zeitungsknick“) fehlerfrei zu rendern. Das heißt, es sollte alles korrekt gerendert werden, was nach dem Laden im größtmöglichen Browserfenster sichtbar ist.  
* Der Inhalt der <code>head.css</code> sollte direkt in den Head-Bereich der HTML-Seite eingefügt werden. Das kann automatisch oder händisch erfolgen.
* Der Inhalt der <code>head.css</code> sollte mittels des Style-Tags direkt in den Head-Bereich der HTML-Seite eingefügt werden.
* Die restlichen CSS-Anweisungen werden in die Datei <code>body.css</code> eingetragen.
* Die restlichen CSS-Anweisungen werden in die Datei <code>body.css</code> eingetragen.
* Dies Datei sollte asynchron, {{dh}} parallel zum Body-Element geladen werden.
* Dies Datei sollte asynchron, {{dh}} parallel zum Body-Element geladen werden.


Der Hack, der im [[HTML5-Tutorium: JavaScript: Hello World 04|Teil 4]] zu asynchronen Laden von <code>body.css</code> angewendet wurde, funktioniert leider nicht, da Vite das Element folgendermaßen transformiert.
Verwenden Sie im Style-Tag die Import-Anweisung, um die Datei <code>css/head.css</code> einzubinden. Dadurch wird erreicht, dass der Inhalt dieser Datei beim Bündeln direkt in die HTML-Datei eingebunden wurde (inline) und der Browser diese Datei nicht zusätzlich zu laden braucht.


<source lang="javascript">
<source lang="javascript">
   <link rel="stylesheet" href="data:text/css;base64,LyoNCiAqIEBhdXRob3IgICAgV29s...=="
<style>
        media="none" onload="this.media='all'"
   @import url("css/head.css");
  />
</style>
</source>
</source>


Das heißt, der Inhalt der Datei <code>head.css</code> wird Base64-enkodiert und direkt in das Link-Element eingefügt. Der ganze Inhalt der CSS-Datei ist jetzt Bestandteil der Datei <code>index.html</code> und wird vor den Body-Inhalten geladen. Ziel des Hack war es ja gerade, dies zu vermeiden.
Der Hack, der im [[HTML5-Tutorium: JavaScript: Hello World 04|Teil 4]] zu asynchronen Laden von <code>body.css</code> angewendet wurde, funktioniert leider nicht mehr, da Vite das Element folgendermaßen transformiert.
 
In Vite gibt es jedoch eine andere Möglichkeit, CSS-Dateien dynamisch zu laden. Man kann sie mittels JavaScript laden (vgl. [[https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05/-/blob/v02/src/js/main.js <code>main.js</code> der Vite-App]]). Schreiben Sie die Hello-World-App entsprechend um.


<source lang="javascript">
<source lang="javascript">
import { defineConfig }    from "vite";
<link rel="stylesheet" href="data:text/css;base64,LyoNCiAqIEBhdXRob3IgICAgV29s...=="
import { createHtmlPlugin } from "vite-plugin-html";
      media="none" onload="this.media='all'"  
 
/>
export default defineConfig
({root:      'src',  
  publicDir: '../public',
  build:
  { outDir:  '../web',
    minimize: 'terser',
  },
  plugins:
  [ createHtmlPlugin
    ({minify: true,
    })
  ]
});
</source>
 
==Webpack==
 
Allerdings ist das CSS-Layout immer noch mangelhaft. Die Datei <code>main.css</code>
wird bislang noch nicht eingebunden. Das können Sie ganz einfach ändern.
Fügen Sie in die Datei <code>src/js/main.js</code> folgenden Import-Befehl am Anfang der Datei ein:
 
<source lang="javascript"</code>
import '../css/main.css';
</source>
</source>


Dieser Befehl ist in JavaScript eigentlich nicht erlaubt. Wenn Sie jetzt versuchen, die Datei  
Das heißt, der Inhalt der Datei <code>body.css</code> wird Base64-enkodiert und direkt in das Link-Element eingefügt. Der ganze Inhalt der CSS-Datei ist jetzt Bestandteil der Datei <code>index.html</code> und wird vor den Body-Inhalten geladen. Ziel des Hack war es ja gerade, dies zu vermeiden.  
<code>src/index.html</code> im Browser zu öffnen, werden Sie in der Browser-Konsole
eine Fehlermeldung erhalten.
 
Webpack unterstützt allerdings das Importieren von CSS-Dateien in JavaScript-Dateien.  
Das Tool wurde so konfiguriert, dass die CSS-Datei dynamisch in das HTML-Dokument „injiziert“ wird
(siehe oben).  


Geben Sie im Terminal noch einmal die Anweisung <code>npm run dev</code> ein
In Vite gibt es jedoch eine andere Möglichkeit, CSS-Dateien dynamisch zu laden. Man kann sie mittels JavaScript laden (vgl. [[https://gitlab.multimedia.hs-augsburg.de/kowa/wk_hello_world_05/-/blob/v02/src/js/main.js <code>main.js</code> der Vite-App]]).  
und öffnen Sie die Datei <code>web/index.html</code> im Browser (nicht die Datei <code>src/index.html</code>!). Jetzt sollte sie wieder sauber formatiert sein
(evtl. erst nach einem Reload im Browser)!


Sehen Sie sich mal den Inhalt der Datei <code>main.js</code> an. Darin finden Sie
Wenn man das Vite-Plugin <code>cssInjectedByJsPlugin</code> verwendet, werden die CSS-Dateien von Vite nicht statisch in die HTML-Datei eingefügt, sondern in der JavaScript-Datei dynamisch zur Laufzeit im Browser geladen und erst im Browser in die HTML-Datei eingefügt. Das zugehörige NPM-Package müssen Sie zunächst installieren:
– neben vielen Kommentaren, die zur Strukturierung der Datei verwendet werden die Inhalte der Dateien <code>main.js</code>, <code>greet.js</code> und <code>main.css</code>
sowie spezielle Anweisungen, die von Webpack eingefügt wurden.  


In dieser Form ist die Datei für Entwicklungszwecke einigermaßen brauchbar. Bei einem Fehler
zeigt einem der Browser, in welcher Zeile dieser Datei der Fehler aufgetreten ist.
Normalerweise handelt es sich um eine Zeile, die Sie erfasst haben. Webpack-Befehle sollten keine
Fehler werfen. Nachteilig ist, dass diese Zeile etwas anders aussehen kann, wie in Ihrem Sourcecode,
da sie eventuell transformiert wurde. Aber man findet die Originalzeile normalerweise recht schnell.
Gehen Sie nochmal ins Terminal und geben Sie diesmal
die Anweisung <code>npm run prod</code> (prod = production) ein.
Es werden wieder die drei Dateien erstellt. Und die Web-Anwendung sollte
immer noch funktionieren. Wenn Sie sich die gebündelte JavaScript-Datei <code>web/js/main.js</code> noch einmal ansehen,
werden Sie feststellen, dass sie nun viel kleiner ist. Sie enthält keine überflüssige Leerzeichen, keine Zeilenumbrüche
und auch keine Kommentare mehr (evtl. mit Ausnahme des Kommentars, der Auskunft über den Autor der CSS-Datei <code>main.css</code>). Diese Datei ist für den Produktivbetrieb viel besser geeignet, da sie weniger Bandbreite
verbraucht. Insbesondere Smartphone-Besitzer freuen sich über kleine Dateien, da ihr Datenvolumen
dadurch weniger belastet wird. Für die Fehlersuche bei der Entwicklung der Web-Aanwendung ist diese
Variante allerdings vollkommen ungeeignet.
Nun können Sie noch die Anweisung <code>npm run watch</code> testen.
Dieser startet einen Webpack-Watcher, der bei jeder Änderung an einer Datei, die von Webpack
beim Bündeln berücksichtigt wird, dafür sorgt, dass die Dateien im Web-Ordner neu erstellt werden
und Sie die Ergebnisse Ihrer Änderung durch einen einfachen (Auto-)Reload der Datei <code>index.html</code>
im Browser betrachten können. Ändern Sie doch einmal in der CSS-Datei <code>src/css/head.css</code>
('''nicht in der Datei <code>web/css/head.css</code>''') die Hintergrundfarbe, speichern Sie die Datei und
laden Sie danach die HTML-Datei im Browser mittels des Reload-Buttons neu.
== Verbesserungen der Webpack-Konfiguration ==
=== Hinzufügen verschiedener Minimizer ===
'''Musterlösung''': [https://glossar.hs-augsburg.de/beispiel/tutorium/2021/hello_world/WK_HelloWorld05a/web/index.html <code>index.html</code> (5b)]
(Git-Repository: [https://gitlab.multimedia.hs-augsburg.de/kowa/WK_HelloWorld05b.git 5b])
Wenn man die Dateien betrachtet, wurde nur die Datei <code>main.js</code> im Produktions-Modus minimiert.
Künftig sollen alle Dateien im Produktionsmodus minimiert werden.
Dafür brauchen wir drei neue Node.js-Pakete, zum Minimieren von CSS-, HTML- und JavaScript-Dateien:
<source lang="bash">
<source lang="bash">
npm i -D css-minimizer-webpack-plugin  
npm i -D vite-plugin-css-injected-by-js
npm i -D html-minimizer-webpack-plugin
npm i -D terser-webpack-plugin
</source>
</source>


Nun muss man diese drei Plugins noch in die Webpack-Konfigurationsdatei <code>webpack.config.js</code> einarbeiten.
Anschließend wird das Plugin in <code>vite.config.js</code> konfiguriert.
 
Zunächst muss die neuen Pakete importieren. Dazu ersetzt fügt man am Anfang der Datei drei weitere Require-Anweisungen ein.


<source lang="javascript">
<source lang="javascript">
const
import cssInjectedByJsPlugin from 'vite-plugin-css-injected-by-js'
  path      = require('path'),
  CopyPlugin = require('copy-webpack-plugin');
</source>


wird zu
export default
 
{ root:      'src',  
<source lang="javascript">
   publicDir: '../public',
const
   base:      '',
  path                = require('path'),
   build:
   CopyPlugin          = require('copy-webpack-plugin'),
   { outDir: '../web',
   TerserPlugin        = require('terser-webpack-plugin'),
    minify: true,
   CssMinimizerPlugin  = require('css-minimizer-webpack-plugin'),
   HtmlMinimizerPlugin = require('html-minimizer-webpack-plugin');
</source>
 
Außerdem muss das Konfigurations-Objekt, das exportiert wird, künftig mit einer Funktion berechnet werden,
damit man ermitteln kann, ob der Benutzer Webpack im Development- oder im Produktionsmodus ausführt.
 
<source lang="javascript">
module.exports =
{ entry:
  ...
};
</source>
 
wird zu
 
<source lang="javascript">
module.exports =
function(p_env, p_argv)
{ const isProd = p_argv.mode === 'production';
 
  return {
 
  // the mode of the current webpack run: 'development' or 'production'
  mode: p_argv.mode || 'development',
 
  entry:
  ...
}};
</source>
 
Innerhalb dieser Funktion steht einem nun die Konstante <code>isProd</code> zur Verfügung. Sie hat den Wert
<code>false</code>, wenn Webpack im Development-Modus ausgeführt wird, und <code>true</code>, wenn Webpack im Produktionsmodus läuft.
 
Zu guter Letzt muss man noch ein paar Optimierungs-Regeln im Anschluss an das Objekt <code>module</code> in die Konfigurationsdatei
einfügen.
 
<source lang="javascript">
module.exports =
{ module:
  { ...
   },
   },
};
  plugins:
  [ cssInjectedByJsPlugin(),
  ]
}
</source>
</source>


wird zu
Schreiben Sie die Hello-World-App entsprechend um.


<source lang="javascript">
=== HTML komprimieren ===
{ module:
  { ...
  },
 
  optimization:
  { minimize: isProd,
 
    minimizer:
    [ new TerserPlugin                            // minimize JS
          ({ extractComments: true, }),
      new CssMinimizerPlugin                      // minimize CSS
          (),
      new HtmlMinimizerPlugin                      // minimize HTML
          ({ minimizerOptions:
            { collapseBooleanAttributes:  true,
              collapseWhitespace:          true,
              collapseInlineTagWhitespace: true,
            }
          }),
    ],
  },
};
</source>
 
Das Attribut <code>minimize</code> wird im Development-Modus auf <code>false</code> gesetzt und im Produktions-Modus auf <code>true</code>.
Das heißt, im Development-Modus werden keine Dateien minimiert. Im Produktionsmodus werden dagegen sowohl JS-, als auch CSS-, als auch HTML-Dateien minimiert.
Die einzelnen Minimizer heißen unterschiedlich, stammen von unterschiedlichen Autoren und akzeptieren unterschiedliche Konfigurationsattribute.
Dies ist ganz typisch für Webpack. Und in der nächsten Version funktioniert der ein oder andere Minimizer gar nicht mehr. Allerdings sind in der Zwischenzeit zumindest das Terser-Plugin und das CSS-Minimizer-Plugin offizieller Bestandteil von Webpack.


Wenn Sie jetzt <code>npm run dev</code> ausführen, sollte keine Datei im Web-Ordner komprimiert werden. Führen Sie dagegen <code>npm run prod</code> aus, sollten alle Dateien minimiert werden. Außerdem werden die Lizenzinformationen in eine eigene Datei ausgelagert.
Wenn man sich die Dateien im Web-Ordner ansieht, bemerkt man, dass nur die JavaScript- und CSS-Dateien gebündelt und verkleinert werden. Die HTML wurde dagegen nicht komprimiert. Um dies zu erreichen, benötigt man ein weitere Vite-Plugin. Das zugehörige NPM-Package wird ebenfalls installiert:


=== Inlining von <code>head.css</code> ===
'''Musterlösung''': [https://glossar.hs-augsburg.de/beispiel/tutorium/2021/hello_world/WK_HelloWorld05a/web/index.html <code>index.html</code> (5c)]
(Git-Repository: [https://gitlab.multimedia.hs-augsburg.de/kowa/WK_HelloWorld05c.git 5c])
[https://developers.google.com/speed/pagespeed/insights/ Google PageSpeed Insights] hatte angemahnt, den Inhalt der Datei <code>head.css</code>
direkt in die Datei <code>index.html</code> einzufügen.
* Google PageSpeed Insights [https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fglossar.hs-augsburg.de%2Fbeispiel%2Ftutorium%2F2021%2Fhello_world%2FWK_HelloWorld05b%2Fweb%2Findex.html Version 5b]: Ressourcen beseitigen, die das Rendering blockieren: <code>.../css/head.css</code>
*Google PageSpeed Insights [https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fglossar.hs-augsburg.de%2Fbeispiel%2Ftutorium%2F2021%2Fhello_world%2FWK_HelloWorld05c%2Fweb%2Findex.html Version 5c]: Hier gibt es diese Empfehlung nicht mehr.
Um die Datei <code>head.css</code> in die Datei <code>index.html</code> einzufügen, muss man die HTML-Datei erzeugen. Ein einfaches Kopieren reicht nicht mehr aus. Anstelle des Copy-Plugins verwendet man das HTML-Webpack-Plugin. Dieses kann HTML-Dateien auf Basis von HTML-Templates erstellen und auch komprimieren. Da heißt, man benötigt auch das HTML-Minimizer-Plugin nicht mehr. Die CSS-Datei kann man mittels, des HTML-CSS-Inline-Plugins einfügen.
Dafür braucht man allerdings das Mini-CSS-Extract-Plugin anstelle des Extract-Loaders und des File-Loaders. Insgesamt bedeutet dies einen größeren Umbau der Konfigurationsdatei.  Zunächst sollten veraltete Node.js-Pakete entfernt und die dafür benötigten Pakete installiert werden:
<source lang="bash">
<source lang="bash">
npm uninstall -D file-loader extract-loader
npm i -D vite-plugin-html
npm uninstall -D copy-webpack-plugin html-minimizer-webpack-plugin
 
npm i -D html-webpack-plugin html-replace-webpack-plugin
npm i -D mini-css-extract-plugin html-inline-css-webpack-plugin
</source>
</source>


Das HTML-Replace-Plugin wird benötigt, um an der modifizierten zum Schluss mit Hilfe von [[regulärer Ausdruck|regulären Ausdrücken]] noch zwei kleine Änderungen vorzunehmen. Damit werden Probleme behoben, die sich ergeben, weil es in den benutzten Paketen keine geeigneten Konfigurationsoptionen gibt.
Anschließend muss das Plugin wieder in <code>vite.config.js</code> konfiguriert werden, in dem es zunächst importiert wird:
Hier sieht man deutlich das Problem von Webpack: Es gibt sehr viele Loader, Plugins und Optimierer. Allerdings hat jedes Paket seine individuellen Schwächen und oft arbeiten zwei Pakete auch nicht wie gewünscht zusammen. Hier hilft meist nur Try and Error. Ob man zum Schluss die beste Variante gewählt hat, ist dabei unklar.
 
Die Datei <code>webpack.config.js</code> wird folgendermaßen geändert:


<source lang="javascript">
<source lang="javascript">
const
import { createHtmlPlugin } from "vite-plugin-html"
  path                = require('path'),
  CopyPlugin          = require('copy-webpack-plugin'),
  TerserPlugin        = require('terser-webpack-plugin'),
  CssMinimizerPlugin  = require('css-minimizer-webpack-plugin'),
  HtmlMinimizerPlugin = require('html-minimizer-webpack-plugin');
</source>
</source>


wird zu
Anschließend wird der Initialisierungsbefehl in das Array <code>plugins</code> eingefügt. Diesmal wird allerdings zusätzlich ein
Konfigurationsparameter übergeben, der die Komprimierung der HTML-Datei veranlasst:


<source lang="javascript">
<source lang="javascript">
const
createHtmlPlugin({ minify: true })
  path                      = require('path'),
  TerserPlugin              = require('terser-webpack-plugin'),
  CssMinimizerPlugin        = require('css-minimizer-webpack-plugin'),
  MiniCssExtractPlugin      = require('mini-css-extract-plugin'),
  HtmlWebpackPlugin          = require('html-webpack-plugin'),
  HTMLInlineCSSWebpackPlugin = require('html-inline-css-webpack-plugin').default,
  HtmlReplaceWebpackPlugin  = require('html-replace-webpack-plugin');
</source>
</source>


Das Plugins-Array muss vollständig ersetzt werden werden:
Der HTML-Minimizer komprimiert auch CSS-Anweisungen, die im HTML-Code enthalten sind. In unseren Fall ist das der Inhalt der Datei
<code>head.css</code>, der wegen des <code>@import</code>-Befehls von Vite direkt in die HTML-Datei eingefügt  wird.


<source lang="javascript">
=== Lizenzkommentare entfernen ===
plugins:
[ ...
],
</source>


wird zu
Ein Problem besteht noch. Die Lizenzkommentare werden in die komprimierten CSS- und JavaScript-Dateien eingefügt. Das kann gewünscht sein, kostet aber Platz. Das Problem kann man zumindest für JavaScript-Dateien beheben, indem man den Minimizer <code>terser</code> verwendet. Dieser bietet zahlreiche Konfigurationsmöglichkeiten an (ist allerdings beim Komprimieren wesentlich langsamer als der Standard-Minimizer). Schreiben Sie in der Datei
<code>vite.config.js</code> an Stelle von


<source lang="javascript">
<source lang="javascript">
plugins:
minify: true,
[ new MiniCssExtractPlugin
  ({ filename: "[name].css" }),
  new HtmlWebpackPlugin
  ({ template: absolutePath('src/index.html'),
    chunks:  ['head', 'main'],
    minify:
    { collapseWhitespace:  isProd,
      removeComments:      true,
      ignoreCustomComments: [/@preserve/],
    },
  }),
  new HTMLInlineCSSWebpackPlugin
  (),
  new HtmlReplaceWebpackPlugin
  ([{ pattern:    /<script .*head\.js"><\/script>/,
      replacement: '',
    },
    { pattern:    /defer/g,
      replacement: 'async',
    },
  ]),
],
</source>
</source>


Das HTML-Webpack-Plugin kopiert in die Template-Datei <code>src/index.html</code> zwei Script-Anweisungen,
folgende Konfigurationsanweisungen:
um die von Webpack erzeugten Dateien (“Chunks”, Klumpen) <code>web/js/head.js</code> und
<code>web/js/main.js</code> zu Laden. Diese Anweisungen dürfen also in der Template-Datei nicht enthalten sein.
Wie man sieht, kann man im HTML-Webpack-Plugin die Komprimierung mittels der Option <code>minify</code>
direkt konfigurieren. Auch hier werden die Leerzeichen und -zeilen nur im Produktivmodus, aber nicht im Developmentmodus entfernt.
 
Mit Hilfe des HTML-Replace-Plugins wird der Eintrag <code><script "src=css/head.js"></script></code> wieder aus
<code>index.html</code> gelöscht. Diese JavaScript-Datei enthält nur den CSS-Code, der mittels
des HTML-Inline-CSS-Plugins direkt eingefügt wurde. Warum dieses Plugin das überflüssige Script-Tag nicht
selbst entfernt, habe ich noch nicht herausgefunden.
 
Außerdem wird <code>defer</code> durch </code>async</code>
ersetzt, da ich das asynchrone Laden gegenüber dem verzögerten Laden von JavaScript-Dateien bevorzuge. Warum
ich das im HTML-Webpack-Plugin nicht konfigurieren kann, weiß ich auch nicht.
 
Und die Regel für die <code>head.css</code> im Array <code>rules</code>) muss ersetzt werden.


<source lang="javascript">
<source lang="javascript">
{ test:   /head\.css$/,
minify: 'terser',
  include: [ /src/ ],
terserOptions:  
  use:     [ MiniCssExtractPlugin.loader,
{ output: { comments: false } },
            'css-loader',
          ],
},
</source>
</source>


Für den CSS-Minimizer habe ich bislang keine entsprechenden Optionen gefunden. Schade.
Aber das Problem lässt sich ganz einfach beheben, indem man in CSS-Dateien keine [[JSDoc]]-Kommentare verwendet (was ja durchaus auch sinnvoll ist, da CSS keinen JavaScript-Code enthält). Anstelle von


Wenn Sie jetzt <code>npm run dev</code> ausführen, sollte keine Datei im Web-Ordner komprimiert werden. Führen Sie dagegen <code>npm run prod</code> aus, sollten alle Dateien minimiert werden. Außerdem werden die Lizenzinformationen in eine eigene Datei ausgelagert. In beiden Fällen sollte der Inhalt der
<source lang="css">
CSS-Datei <code>head.css</code> in der HTML-Datei selbst enthalten sein. Einmal unkomprimiert und einmal komprimiert.
/**
 
  * @author    Wolfgang Kowarschick <kowa@hs-augsburg.de>
==== Ein kleine Verbesserung der Import-Anweisungen ====
  * @copyright 2016-2023
 
* @license  MIT
Wenn Sie schon gerade dabei sind, fügen Sie noch folgendes Konfigurationsobjekt in die Export-Funktion von <code>webpack.config.js</code> ein:
*/
 
<source lang="javascript">
resolve:
{ alias: { '/json': absolutePath('src/json/'),
          '/css': absolutePath('src/css/'),
          '/img': absolutePath('src/img/'),
        },
},
</source>
</source>


Damit erreichen Sie, dass Dateien, die sich in den Ordnern <code>src/json/</code>,  <code>src/css/</code>,  <code>src/img/</code> befinden,
können Sie beispielsweise
direkt importiert werden können. Die Notwendigkeit, relative Pfadangaben wie <code>import '../../../css/irgenwas.css';</code> zu verwenden, entfällt.
Sie können künftig einfach <code>import '/css/irgenwas.css';</code> schreiben. Das gilt auch für Bilder oder JSON-Dateien, die Sie  
(mittels des erweiterten Import-Befehls von Webpack) in eine JavaScript-Datei importieren. Sie können selbstverständlich beliebig
viele weitere Alias-Befehle definieren, natürlich auch für JavaScript-Bibliotheken, die in anderen Ordnern enthalten sind.
 
Ersetzen Sie also in der Datei <code>src/main.js</code>, den Befehl <code>import '../css/body.css';</code> durch
<code>import '/css/body.css';</code>
 
=== Verwendung des SCSS-Minimizers ===
 
'''Musterlösung''': [https://glossar.hs-augsburg.de/beispiel/tutorium/2021/hello_world/WK_HelloWorld05d/web/index.html <code>index.html</code> (5d)]
(Git-Repository: [https://gitlab.multimedia.hs-augsburg.de/kowa/WK_HelloWorld05b.git 5d])
 
Wenn man sich die Datei <code>web/js/main.js</code> ansieht, bemerkt man, dass die CS-Befehle, die von
Webpack in diese Datei eingefügt wurden (wegen des Import-Befehls <code>import '/css/body.css';</code>),
im Produktions-Modus nicht komprimiert werden. Da heißt, dass das CSS-Minimizer-Plugin hier nicht greift.
Also sollte es ersetzt werden.
 
Glücklicherweise gibt es einen ausgezeichneten Ersatz: Den SASS-Loader. Anstelle von CSS sollte man SASS/SCSS verwenden,
um auch CSS modularisieren und „[[DRY]] machen“ zu können. Glücklicherweise enthält diese Loader einen eigenen Minimizer.


Modifizieren Sie die Pakete entsprechend:
<source lang="css">
 
/*
<source lang="bash">  
* author    Wolfgang Kowarschick <kowa@hs-augsburg.de>
npm uninstall -D css-minimizer-webpack-plugin
* copyright 2016-2023
npm i -D sass sass-loader
* license  MIT
*/
</source>
</source>


Löschen Sie das CSS-Minimizer-Plugin aus der Datei <code>webpack.config.js</code>, sowohl den Require-Befehl, als auch im Minimizer-Array im
schreiben.
Optimization-Objekt.


Fügen Sie dafür den SASS-Loader in die CSS-Objekte des Rules-Arrays ein.
== Google PageSpeed Insights ==


<source lang="javascript">
Überprüfen Sie IHre eigenen Lösungen oder die Musterlösungen wieder mit [https://developers.google.com/speed/pagespeed/insights/ Google PageSpeed Insights].
module:
{ rules:
  [ { test:   /head\.(css|scss|sass)$/,
      include: [ /src/ ],
      use:    [ MiniCssExtractPlugin.loader,
                'css-loader',
                { loader: 'sass-loader',
                  options:
                  { sassOptions: { outputStyle: isProd ? 'compressed' : 'expanded' } },
                },
              ],
    },


    { test:   /\.(css|scss|sass)/,
* Google PageSpeed Insights [https://pagespeed.web.dev/report?url=https%3A%2F%2Fglossar.hs-augsburg.de%2Fbeispiel%2Ftutorium%2F2023%2Fwk_hello_world%2Fwk_hello_world_05%2Fweb_v03b%2Findex.html Version 03b]: Ressourcen beseitigen, die das Rendering blockieren: <code>…assets/index-91faa27d.css</code>
      include: [ /src/ ],
      exclude: [ /head\.(css|scss|sass)$/ ],
      use:    [ 'style-loader',
                'css-loader',
                { loader: 'sass-loader',
                  options:
                  { sassOptions: { outputStyle: isProd ? 'compressed' : 'expanded' } },
                },
              ],
    },
  ],
},
</source>


Dieser Loader übersetzt SCCS- und SASS-Anweisungen in CSS-Anweisungen. Er bietet zusätzlich eine Option <code>outputStyle</code> an,
* Google PageSpeed Insights [https://pagespeed.web.dev/report?url=https%3A%2F%2Fglossar.hs-augsburg.de%2Fbeispiel%2Ftutorium%2F2023%2Fwk_hello_world%2Fwk_hello_world_05%2Fweb_v04b%2Findex.html Version 04b]: Es werden noch SEO-Probleme gemeldet. Das Dokument enthält keine Meta-Beschreibungen und die dynamisch eingelesenen CSS-Anweisungen können von Google nicht analysiert werden. Außerdem wird weiteres Optimierungspotential genannt (siehe nachfolgenden Abschnitt).
die festlegt, ob die CSS-Anweisungen komprimiert werden sollen oder nicht. Dies nutzen wir aus, um die CSS-Anweisungen im Produktionsmodus zu komprimieren.


=== Weiteres Optimierungspotenzial ===
=== Weiteres Optimierungspotenzial ===


Google PageSpeed Insights [https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fglossar.hs-augsburg.de%2Fbeispiel%2Ftutorium%2F2021%2Fhello_world%2FWK_HelloWorld05d%2Fweb%2Findex.html Version 5d] ist immer noch nicht ganz zufrieden.
Google PageSpeed Insights ist mit [https://pagespeed.web.dev/report?url=https%3A%2F%2Fglossar.hs-augsburg.de%2Fbeispiel%2Ftutorium%2F2023%2Fwk_hello_world%2Fwk_hello_world_05%2Fweb_v04b%2Findex.html Version 04b] ist immer noch nicht ganz zufrieden.


Zum einen sollten die Anzahl der Dateien (zwei) und die Dateigrößen weiter reduziert werden, was aber schwierig ist.  
Zum einen sollten die Anzahl der Dateien (zwei) und die Dateigrößen weiter reduziert werden, was aber schwierig ist.  
Man könnte eine Datei <code>budget.json</code> definieren, die Google mitteilt, welche Dateianzahl und welche Dateigrößen man
Man könnte eine Datei <code>budget.json</code> definieren, die Google mitteilt, welche Dateianzahl und welche Dateigrößen man
für akzeptabel hält. Dan erhält man erst ab diesen Werten eine Warnung.
für akzeptabel hält. Dann erhält man erst ab diesen Werten eine Warnung.


Zum anderen teilt einen Google das größte Element in der HTML-Seite mit. Hier gibt es tatsächlich noch Optimierungspotenzial, gerade bei  
Zum anderen teilt einen Google das größte Element in der HTML-Seite mit. Hier gibt es tatsächlich noch Optimierungspotenzial, gerade bei  
Zeile 623: Zeile 361:
der Inhalt „above the fold“ („über dem Zeitungsknick“) in der HTML-Seite enthalten ist. Das ist der Bereich, den der Benutzer nach dem Laden der Seite
der Inhalt „above the fold“ („über dem Zeitungsknick“) in der HTML-Seite enthalten ist. Das ist der Bereich, den der Benutzer nach dem Laden der Seite
ohne Scrollen sieht. Bei der Hello-World-Anwendung wäre das die Section mit der ID <code>section_form</code>. Alle übrigen Bestandteile
ohne Scrollen sieht. Bei der Hello-World-Anwendung wäre das die Section mit der ID <code>section_form</code>. Alle übrigen Bestandteile
der HTML-Seite könnten dynamisch nachgeladen werden, sobald sie benötigt werden. Genauso funktioniert Google Maps: Es werden nur die Kacheln der Erdoberfläche in der Auflösung geladen, die momentan benötigt werden. Um Verzögerungen, die durch das Nachladen entstehen, gerin zu halten, werden
der HTML-Seite könnten dynamisch nachgeladen werden, sobald sie benötigt werden. Genauso funktioniert Google Maps: Es werden nur die Kacheln der Erdoberfläche in der Auflösung geladen, die momentan benötigt werden. Um Verzögerungen, die durch das Nachladen entstehen, gering zu halten, werden
Randkacheln und Kacheln in benachbarter Auflösung schon mal im Voraus geladen, während der Benutzer die aktuellen Karte betrachtet. Es ist natürlich
Randkacheln und Kacheln in benachbarter Auflösung schon mal im Voraus geladen, während der Benutzer die aktuellen Karte betrachtet. Es ist natürlich
nicht sichergestellt, dass die Kacheln tatsächlich irgendwann angezeigt werden müssen. Aber es ist wahrscheinlich. Und daher wird der potenziell
nicht sichergestellt, dass die Kacheln tatsächlich irgendwann angezeigt werden müssen. Aber es ist wahrscheinlich. Und daher wird der potenziell
unnötige Datenverkehr in Kauf genommen. Hier kommt es auf die Abwägung zwischen User Experience (möglichst kurze Wartezeiten)  
unnötige Datenverkehr in Kauf genommen. Hier kommt es auf die Abwägung zwischen User Experience (möglichst kurze Wartezeiten)  
und Energie- und Kosteneffizienz (möglichst geringes Transfervolumen) an.
und Energie- und Kosteneffizienz (möglichst geringes Transfervolumen) an.
In den späteren Tutorien wird [[Vue]] zum Erstellen von Web-Anwendungen verwendet. Hier werden, da es sich um Single-Page-Anwendungen handelt, Seiteninhalte automatisch dynamisch nachgeladen. Das heißt, man kann die Forderung, Seiten klein zu halten, sehr einfach erfüllen.


Das Transfervolumen kann weiter reduziert werden, indem die Dateien vor dem Ausliefern vom Server mittels [[gzip]] weiter komprimiert werden. Der Client muss sie dann erst wieder entpacken, bevor er sie verarbeiten kann.  
Das Transfervolumen kann weiter reduziert werden, indem die Dateien vor dem Ausliefern vom Server mittels [[gzip]] weiter komprimiert werden. Der Client muss sie dann erst wieder entpacken, bevor er sie verarbeiten kann.  
Dies ist aber eine Server-Optimierung, die nicht mit Webpack oder einen vergleichbaren Tool realisiert werden kann.
Dies ist aber eine Server-Optimierung, die üblicherweise nicht mit Vite oder einen vergleichbaren Tool realisiert wird.


==Fortsetzung des Tutoriums==
==Fortsetzung des Tutoriums==


Sie sollten nun [[HTML5-Tutorium: JavaScript: Hello World 06|Teil 6 des Tutoriums]] bearbeiten.
Sie sollten nun [[HTML5-Tutorium: JavaScript: Hello World 06|Teil 6 des Tutoriums]] bearbeiten.
In diesem Teil des Tutoriums wird ausgenutzt, dass in die Konfigurationsdatei von Webpack ein SCSS-Loader integriert wurde. Damit kann man das Prinzip “[[don't repeat yourself|<strong>D</strong>on't <strong>R</strong>epeat <strong>Y</strong>ourself]]” (DRY) auch für CSS-Dateien umsetzen.
In diesem Teil des Tutoriums wird ausgenutzt, dass von Vite SCSS, LESS etc. unterstützt wird. Damit kann man das Prinzip “[[don't repeat yourself|<strong>D</strong>on't <strong>R</strong>epeat <strong>Y</strong>ourself]]” (DRY) auch für CSS-Dateien umsetzen.


==Quellen==
==Quellen==
<references/>
<references/>
<ol>
<ol>
<li value="6"> {{Quelle|Kowarschick, W.: Multimedia-Programmierung}}</li>
<li value="4"> {{Quelle|Kowarschick, W.: Web-Programmierung}}</li>
</ol>
</ol>
<noinclude>[[Kategorie: HTML5-Tutorium: JavaScript: Hello World]][[Kategorie: HTML5-Beispiel]][[Kategorie:Kapitel:Multimedia-Programmierung:Beispiele]]</noinclude>
<noinclude>[[Kategorie: HTML5-Tutorium: JavaScript: Hello World]][[Kategorie: HTML5-Beispiel]][[Kategorie:Kapitel:Multimedia-Programmierung:Beispiele]]</noinclude>

Version vom 21. April 2023, 17:57 Uhr

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:

Korrektheit: 3
(zu größeren Teilen überprüft)
Umfang: 4
(unwichtige Fakten fehlen)
Quellenangaben: 3
(wichtige Quellen vorhanden)
Quellenarten: 5
(ausgezeichnet)
Konformität: 3
(gut)

Vorlesung WebProg

Inhalt | Teil 1 | Teil 2 | Teil 3 | Teil 4 | Teil 5 | Teil 6

Musterlösung
v03a: index.html
v03b: index.html
v04a: index.html
v04b: index.html
v05: index.html (Modularisierung von greet.js analog zu Hello World 04 v02)
v06: index.html (Konfiguration mittels JSON analog zu Hello World 04 v03)
Git-Repository

Anwendungsfälle (Use Cases)

Gegenüber dem dritten (und dem vierten) Teil des Tutoriums ändern sich die die Anwendungsfälle nicht. Die Anwendung leistet also genau dasselbe wie zuvor.

In diesem Teil des Tutoriums geht es darum, die Anwendung mittels Vite 4[1] automatisch für den Server-Betrieb zu optimieren, sodass möglichst wenige, möglichst kleine Dateien zum Client übertragen werden.

JavaScript Module Bundlers

Um Module einer Web-Anwendung für die Auslieferung zum Client zu komprimieren, zu bündeln und anderweitig zu optimieren, gibt es zahlreiche Werkzeuge. Für Node.js gibt es die sogenannten “JavaScript Module Bundlers”, wie z. B. Vite[1], Webpack[2] oder Browserify[3].

Üblicherweise optimieren die Bundlers nicht nur JavaScript-Dateien, sondern auch HTML-, CSS-, JSON- und andere Dateien.

Erstellen eines neuen Vite-Projekts (Version 00)

Erstellen Sie ein neues Vite-Projekt hello_world_05:

cd /webprog  # Ordner, in dem Ihre Projekte liegen
npm create vite@latest

Geben Sie für Vite folgende Optionen an:

Project name: hello_world_05
Select a framework: Vanilla
Select a variant: JavaScript

Öffnen Sie das Projekt in Visual Studio Code (VSC) und öffnen Sie in VSC ein zugehöriges Terminal (für den neuen Projektordner). Führen Sie folgende Befehle aus:

npm i
npm run dev

Nun wird ein Server gestartet und eine URL angezeigt, die Sie in einem Browser öffnen können. Make it so!

Stellen Sie anschließend das Projekt unter Git-Kontrolle und speichern Sie es wieder in Gitlab.

Zur Erinnerung: .gitignore

Achtung: Bevor Sie einen Commit durchführen, müssen Sie im selben Ordner, in dem sich die Datei package.json befindet, eine Datei namens .gitignore anlegen, in dem eine Zeile mit dem Wort node_modules enthalten ist. (Der Punkt zu Beginn des Dateinamens darf nicht fehlen!)

Glücklicherweise hat dies das Vite-Setup für Sie übernommen.

Diese Datei ist extrem wichtig. Wie Sie bereits im Node.js-Tutorium gesehen haben, enthält der Ordner node_modules sehr schnell sehr viele Dateien (mehrere Zehntausend). Wenn Sie diese im Repository speichern, bläht sich dieses extrem stark auf. Die Git-Push- und -Pull-Befehle werden dadurch sehr langsam.

Die Datei .gitignore dient dazu, dies zu verhindern. In jeder Zeile steht ein Dateiname oder ein Dateipattern (wie zum Beispiel *.log, das alle Dateien mit der Dateiextension log beschreibt), um zu verhindern, dass die zugehörigen Dateien ins Git-Repository eingefügt werden.

Wenn Sie dafür sorgen, die Dateien package.json und package-lock.json ins Repository eingefügt werden, kann ein anderer Benutzer, der Ihr Git-Repository auf seinen Rechner lädt, die fehlenden Node.js-Module jederzeit ganz einfach restaurieren:

npm i

Konfigurieren des Vite-Projekts Version 01

Das neu angelegte Projekt enthält keine Vite-Konfigurationsdatei. Defaultmäßig werden alle Dateien des Web-Projekts im Root-Ordner hello_world_05 abgelegt. Das ist – wie Sie bereits wissen – schlecht, da dort auch andere Dateien liegen, wie z. B. package.json oder node_modules.

Dies können Sie ändern, indem Sie eine Konfigurationsdatei vite.config.js im Projektordner anlegen:

// https://vitejs.dev/config/
export default
{ root:      'src', 
  publicDir: '../public',  
  base:      '',
  build: 
  { outDir:  '../web',
    minify:  true,
  }  
}

Diese legt Folgendes fest:

  • Der Root-Ordner des Projekts befindet sich im Unterordner src des Projektordners. Dort hinein kommen die ganzen HTML-/CSS-/JS-Dateien und Medien, die unter Kontrolle von Vite stehen sollen.
  • Der Ordner public, in dem alle Dateien enthalten sind, die von Vite nicht verändert werden, befindet sich weiterhin im Unterordner public des Projektordners. Vom Projektordner src aus gesehen, liegt er außerhalb von src eine Ebene höher. Das heißt, er befindet sich in der Ordnerhierarchie auf derselben Ebene wie src selbst.
  • Die Option base enthält einen String, der vor jeden Asset-Pfad (.css, .js, .jpg ...) eingefügt wird. Standardmäßig lautet der Wert '/'. Das heißt, die zugehörigen Assetpfade sind absolut. Sie beginnen stets beim Top-Level-Verzeichnis der Web-App. Mit der Option base: '' legt man fest, dass die Pfade relativ sind. Das hat den Vorteil, dass man die Web-App in einen Unterordner einer anderen Web-App legen kann. Beispielsweise liegen die Musterlösungen dieser Aufgabe in Underordnern des Glossars: index.html, index.html (v03a) etc.
  • Wenn Sie das Projekt mittels npm run build für den Produktivbetrieb erstellen lassen, wird das Ergebnis in den Ordner web geschrieben. Dieser Ordner liegt ebenfalls auf derselben Ebene wie src.
  • Durch npm run build wird komprimierter (minimized) Code erzeugt. Das gilt allerdings nicht für HTML-Dateien, sondern nur für CSS-, JavaScript-/TypeScript- und SVG-Dateien.

Sie sollten in der Datei package.json im Skript build auch noch die Option --emptyOutDir ergänzen, damit der Web-Ordner vor jedem Rebuild geleert wird. Ohne diese Option sammeln sich im Web-Ordner im Laufe der Zeit Dateileichen an.

"build": "vite build --emptyOutDir",

Restrukturierung des Projekts

Wenn man nun das Projekt mittels npm run dev startet, wird man nichts sehen. Der Grund ist, dass der Browser keine Datei index.html findet, da der Vite-Server nun den Inhalt des Ordners src ausliefert. Diesen gibt es aber noch gar nicht.

Die Ordnerstruktur des Projekts muss an die Konfigurationsdatei angepasst werden.

Erstellen Sie folgende Ordnerstruktur:

src
| css
| img
| js

Verschieben Sie anschließend die Web-Dateien in diese Ordner:

src
| css
  - style.css
| img
  - javascript.svg
| js
  - counter.js
  - main.js
- index.html

Das Ergebnis ist, dass Sie Fehlermeldungen erhalten, weil bestimmte Dateien nicht gefunden werden. Das liegt daran, dass sich die Ordnerstruktur aus Sicht der Dateien im src-Ordner geändert haben. Die Pfade innerhalb der Dateien in diesem Ordner müssen daher angepasst werden.

Die Pfade zu Dateien im public-Ordner bleiben gleich. Aus Sicht der Dateien im src-Ordner befinden sie sich in der Root des Web-Auftritts. Im public-Ordner liegt in diesem Beispiel nur die Datei vite.svg. Deren Pfade ändern sich nicht, daher bleiben in den Dateien src/index.html und src/js/main.js die Zeilen

<link rel="icon" type="image/svg+xml" href="/vite.svg" />

bzw.

<img src="/vite.svg" class="logo" alt="Vite logo" />

unverändert. Die anderen Pfade müssen dagegen eventuell angepasst werden:

// src/index.html
<script type="module" src="/main.js"></script>

// src/js/main.js
import './style.css'
import javascriptLogo from './javascript.svg'
import { setupCounter } from './counter.js'

Nehmen Sie geeignete Änderungen vor (sofern sie von VSC nicht automatisch durchgeführt wurden). Modifizieren und testen Sie die App mit Hilfe von npm run dev solange, bis sie fehlerfrei läuft.

Packen der Web-Anwendung (Build, Version 02)

Bislang zeigt sich der Vorteil von Vite noch nicht wirklich. Der einzige Vorteil ist, dass CSS-Dateien auch in JavaScript-Dateien importiert werden können. Das ist im HTML-Standard nicht vorgesehen.

Seine Stärke spielt Vite aus, wenn wir das Projekt packen. Das bedeutet, dass die Anzahl der Dateien reduziert wird und überflüssige Leerzeichen, Zeilenumbrüche, Kommentare etc. entfernt werden. Dadurch reduziert sich die Anzahl der Bytes, die zu einem Client (Browser) übertragen werden müssen, erheblich. Insbesondere für Smartphones mit einem geringen Datenvolumen profitieren davon.

Intelligente Frameworks wie Vue, Svelte oder React oder React gehen sogar noch einen Schritt weiter und laden nur die Teile einer Web-Seite (nicht Web-Site!) nach, die sich geändert haben. JavaScript-Bibliotheken werden so definiert, dass sie für eine ganze Web-Site nur einmal geladen werden müssen und für verschiedene Seiten wiederverwendet werden können. Hier spielen Web-Frameworks ihre Stärken aus. Sie stützen sich dabei auf Bundler wie Vite oder Webpack.

Führen Sie folgenden Befehl aus:

npm run build

Durch diesen Befehl wird die Web-App gepackt und im Ordner web abgelegt. Öffnen Sie die Datei web/index.html mit Hilfe des Live-Server-Plugins und sehen Sie sich das Ergebnis an. Schauen Sie sich auch die generierten Dateien im Ordner web an.

Testen Sie die Web-App dann, indem Sie entweder web/index.html mit dem Live Server von VSC starten oder indem Sie npm run preview eingeben.

Hello-World-App (Version 03)

Ersetzen Sie nun die Vite-Default-App durch die Hello-World-App aus dem 4. Teil des Tutoriums.

Wenn Sie die Produktivversion mittels npm run build erstellen möchten, muss es eine Datei index.html geben. Defaultmäßig wird nur diese in den Ordner build übernommen. Das heißt, wenn man beispielsweise die Musterlösung von von WK_HelloWorld04 in den (zuvor geleerten) Ordner src kopiert, funktioniert diese Anwendung zwar im Developermoduls (npm run dev), aber nicht im Produktivmodus. Wenn man (für dieses Beispiel) npm run build ausführt, erhält man die Fehlermeldung

Could not resolve entry module "src/index.html".

Das Problem ist, dass es keine Datei index.html gibt. Die Lösung ist in diesem Fall ganz einfach. Nennen Sie eine der drei Dateien index0.html, index1.html oder index2.html in index.html um. Im Ordner web wird dann durch npm run build auch nur eine HTML-Datei namens index.html erzeugt. Das ist für unsere Zwecke in Ordnung, da wir mit Hilfe von Vue eine Single-Page-Anwendung erstellen werden. Die Inhalte einer derartigen Anwendung werden per JavaScript nachgeladen. Man benötigt also tatsächlich nur eine HTML-Datei.

Anmerkung
Sie können auch eine Anwendung mit diversen HTML-Dateien mit Hilfe von Vite bündeln und komprimieren. Dafür müssen Sie allerdings eine so genannte Rollup-Konfiguration in die Datei vite.config.js einfügen.

Verbesserungen (Version 04)

head.css inline und body.css dynamisch laden

Zur Erinnerung:

  • In head.css stehen möglichst wenig CSS-Anweisungen. Sie sollten ausreichen, um die aktuelle Seite “above the fold” („über dem Zeitungsknick“) fehlerfrei zu rendern. Das heißt, es sollte alles korrekt gerendert werden, was nach dem Laden im größtmöglichen Browserfenster sichtbar ist.
  • Der Inhalt der head.css sollte mittels des Style-Tags direkt in den Head-Bereich der HTML-Seite eingefügt werden.
  • Die restlichen CSS-Anweisungen werden in die Datei body.css eingetragen.
  • Dies Datei sollte asynchron, d. h. parallel zum Body-Element geladen werden.

Verwenden Sie im Style-Tag die Import-Anweisung, um die Datei css/head.css einzubinden. Dadurch wird erreicht, dass der Inhalt dieser Datei beim Bündeln direkt in die HTML-Datei eingebunden wurde (inline) und der Browser diese Datei nicht zusätzlich zu laden braucht.

<style>
  @import url("css/head.css");
</style>

Der Hack, der im Teil 4 zu asynchronen Laden von body.css angewendet wurde, funktioniert leider nicht mehr, da Vite das Element folgendermaßen transformiert.

<link rel="stylesheet" href="data:text/css;base64,LyoNCiAqIEBhdXRob3IgICAgV29s...=="
      media="none" onload="this.media='all'" 
/>

Das heißt, der Inhalt der Datei body.css wird Base64-enkodiert und direkt in das Link-Element eingefügt. Der ganze Inhalt der CSS-Datei ist jetzt Bestandteil der Datei index.html und wird vor den Body-Inhalten geladen. Ziel des Hack war es ja gerade, dies zu vermeiden.

In Vite gibt es jedoch eine andere Möglichkeit, CSS-Dateien dynamisch zu laden. Man kann sie mittels JavaScript laden (vgl. [main.js der Vite-App]).

Wenn man das Vite-Plugin cssInjectedByJsPlugin verwendet, werden die CSS-Dateien von Vite nicht statisch in die HTML-Datei eingefügt, sondern in der JavaScript-Datei dynamisch zur Laufzeit im Browser geladen und erst im Browser in die HTML-Datei eingefügt. Das zugehörige NPM-Package müssen Sie zunächst installieren:

npm i -D vite-plugin-css-injected-by-js

Anschließend wird das Plugin in vite.config.js konfiguriert.

import cssInjectedByJsPlugin from 'vite-plugin-css-injected-by-js'

export default
{ root:      'src', 
  publicDir: '../public',
  base:      '',
  build: 
  { outDir:  '../web',
    minify:  true,
  },
  plugins: 
  [ cssInjectedByJsPlugin(),
  ]
}

Schreiben Sie die Hello-World-App entsprechend um.

HTML komprimieren

Wenn man sich die Dateien im Web-Ordner ansieht, bemerkt man, dass nur die JavaScript- und CSS-Dateien gebündelt und verkleinert werden. Die HTML wurde dagegen nicht komprimiert. Um dies zu erreichen, benötigt man ein weitere Vite-Plugin. Das zugehörige NPM-Package wird ebenfalls installiert:

npm i -D vite-plugin-html

Anschließend muss das Plugin wieder in vite.config.js konfiguriert werden, in dem es zunächst importiert wird:

import { createHtmlPlugin } from "vite-plugin-html"

Anschließend wird der Initialisierungsbefehl in das Array plugins eingefügt. Diesmal wird allerdings zusätzlich ein Konfigurationsparameter übergeben, der die Komprimierung der HTML-Datei veranlasst:

createHtmlPlugin({ minify: true })

Der HTML-Minimizer komprimiert auch CSS-Anweisungen, die im HTML-Code enthalten sind. In unseren Fall ist das der Inhalt der Datei head.css, der wegen des @import-Befehls von Vite direkt in die HTML-Datei eingefügt wird.

Lizenzkommentare entfernen

Ein Problem besteht noch. Die Lizenzkommentare werden in die komprimierten CSS- und JavaScript-Dateien eingefügt. Das kann gewünscht sein, kostet aber Platz. Das Problem kann man zumindest für JavaScript-Dateien beheben, indem man den Minimizer terser verwendet. Dieser bietet zahlreiche Konfigurationsmöglichkeiten an (ist allerdings beim Komprimieren wesentlich langsamer als der Standard-Minimizer). Schreiben Sie in der Datei vite.config.js an Stelle von

minify: true,

folgende Konfigurationsanweisungen:

minify:  'terser',
terserOptions: 
{ output: { comments: false } },

Für den CSS-Minimizer habe ich bislang keine entsprechenden Optionen gefunden. Schade. Aber das Problem lässt sich ganz einfach beheben, indem man in CSS-Dateien keine JSDoc-Kommentare verwendet (was ja durchaus auch sinnvoll ist, da CSS keinen JavaScript-Code enthält). Anstelle von

/**
 * @author    Wolfgang Kowarschick <kowa@hs-augsburg.de>
 * @copyright 2016-2023
 * @license   MIT
 */

können Sie beispielsweise

/*
 * author    Wolfgang Kowarschick <kowa@hs-augsburg.de>
 * copyright 2016-2023
 * license   MIT
 */

schreiben.

Google PageSpeed Insights

Überprüfen Sie IHre eigenen Lösungen oder die Musterlösungen wieder mit Google PageSpeed Insights.

  • Google PageSpeed Insights Version 03b: Ressourcen beseitigen, die das Rendering blockieren: …assets/index-91faa27d.css
  • Google PageSpeed Insights Version 04b: Es werden noch SEO-Probleme gemeldet. Das Dokument enthält keine Meta-Beschreibungen und die dynamisch eingelesenen CSS-Anweisungen können von Google nicht analysiert werden. Außerdem wird weiteres Optimierungspotential genannt (siehe nachfolgenden Abschnitt).

Weiteres Optimierungspotenzial

Google PageSpeed Insights ist mit Version 04b ist immer noch nicht ganz zufrieden.

Zum einen sollten die Anzahl der Dateien (zwei) und die Dateigrößen weiter reduziert werden, was aber schwierig ist. Man könnte eine Datei budget.json definieren, die Google mitteilt, welche Dateianzahl und welche Dateigrößen man für akzeptabel hält. Dann erhält man erst ab diesen Werten eine Warnung.

Zum anderen teilt einen Google das größte Element in der HTML-Seite mit. Hier gibt es tatsächlich noch Optimierungspotenzial, gerade bei Single-Page-Anwendungen. Eine Single-Page wird in der Regel auf einmal geladen, aber nur portionsweise angezeigt. Wichtig ist eigentlich nur, dass der Inhalt „above the fold“ („über dem Zeitungsknick“) in der HTML-Seite enthalten ist. Das ist der Bereich, den der Benutzer nach dem Laden der Seite ohne Scrollen sieht. Bei der Hello-World-Anwendung wäre das die Section mit der ID section_form. Alle übrigen Bestandteile der HTML-Seite könnten dynamisch nachgeladen werden, sobald sie benötigt werden. Genauso funktioniert Google Maps: Es werden nur die Kacheln der Erdoberfläche in der Auflösung geladen, die momentan benötigt werden. Um Verzögerungen, die durch das Nachladen entstehen, gering zu halten, werden Randkacheln und Kacheln in benachbarter Auflösung schon mal im Voraus geladen, während der Benutzer die aktuellen Karte betrachtet. Es ist natürlich nicht sichergestellt, dass die Kacheln tatsächlich irgendwann angezeigt werden müssen. Aber es ist wahrscheinlich. Und daher wird der potenziell unnötige Datenverkehr in Kauf genommen. Hier kommt es auf die Abwägung zwischen User Experience (möglichst kurze Wartezeiten) und Energie- und Kosteneffizienz (möglichst geringes Transfervolumen) an.

In den späteren Tutorien wird Vue zum Erstellen von Web-Anwendungen verwendet. Hier werden, da es sich um Single-Page-Anwendungen handelt, Seiteninhalte automatisch dynamisch nachgeladen. Das heißt, man kann die Forderung, Seiten klein zu halten, sehr einfach erfüllen.

Das Transfervolumen kann weiter reduziert werden, indem die Dateien vor dem Ausliefern vom Server mittels gzip weiter komprimiert werden. Der Client muss sie dann erst wieder entpacken, bevor er sie verarbeiten kann. Dies ist aber eine Server-Optimierung, die üblicherweise nicht mit Vite oder einen vergleichbaren Tool realisiert wird.

Fortsetzung des Tutoriums

Sie sollten nun Teil 6 des Tutoriums bearbeiten. In diesem Teil des Tutoriums wird ausgenutzt, dass von Vite SCSS, LESS etc. unterstützt wird. Damit kann man das Prinzip “Don't Repeat Yourself” (DRY) auch für CSS-Dateien umsetzen.

Quellen

  1. Kowarschick (WebProg): Wolfgang Kowarschick; Vorlesung „Web-Programmierung“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2024; Quellengüte: 3 (Vorlesung)