Previous slide Next slide Toggle fullscreen Toggle overview view Open presenter view
Aktuelle Themen der Web-Entwicklung
Software- und Web-Engineering I
Informatik – 3. Semester
Software- und Web-Engineering I · TH Lübeck
Struktur, Gestaltung, Verhalten, Typisierung, Abhängigkeitsinjektion, REST und ein Back-End-Framework. Damit habt ihr einen kompletten Stack von Hand gebaut .
Heute geht es um das, was in der Industrie darauf aufsetzt, und um die Frage, die euch seit dem ersten Front-End-Code im Projekt begleitet: warum eigentlich kein React?
Logos: upload.wikimedia.org
Software- und Web-Engineering I · TH Lübeck
1 Frontend-Frameworks
2 SSR, SSG & Hydration
3 KI-gestützte Entwicklung
4 Web-Security-Basics
5 Wie geht es weiter?
Vier Kurzthemen. Nichts davon ist klausurrelevant.
Software- und Web-Engineering I · TH Lübeck
Was in eurem Front-End mühsam war:
Nach jeder Datenänderung von Hand die richtigen DOM-Knoten suchen und aktualisieren
Der Zustand lag verteilt: teils in Variablen, teils im DOM, teils in data--Attributen
Eine vergessene Stelle, und die Anzeige passte nicht mehr zu den Daten
Dieselbe Kartenkomponente an drei Stellen leicht unterschiedlich gebaut
Das war keine Ungeschicklichkeit, sondern ein bekanntes Problem. Genau dafür gibt es Frontend-Frameworks.
Software- und Web-Engineering I · TH Lübeck
Die Kernidee: State → View als Funktion
Imperativ (was ihr gemacht habt)
Ihr beschreibt die Schritte : Element suchen, Text setzen, Klasse umschalten, Kind anhängen.
Ihr seid dafür verantwortlich, dass der DOM den Daten folgt.
Deklarativ (Framework)
Ihr beschreibt das Ergebnis : so sieht die Oberfläche für diesen Zustand aus.
Das Framework berechnet die nötigen DOM-Änderungen selbst.
Die Formel lautet view = f(state). Ändert sich der Zustand, wird die Ansicht neu abgeleitet, nicht von Hand nachgezogen.
Software- und Web-Engineering I · TH Lübeck
Vanilla JS (bekannt aus web-05)
function render (items ) {
const ul = document .querySelector ("#list" );
ul.innerHTML = "" ;
for (const it of items) {
const li = document .createElement ("li" );
li.textContent = it.title ;
ul.appendChild (li);
}
}
React (nur lesen, nicht lernen)
function List ({ items } ) {
return (
<ul >
{items.map(it =>
<li key ={it.id} > {it.title}</li >
)}
</ul >
Links steht, wie die Liste entsteht. Rechts steht, wie sie aussieht . Den Rest erledigt das Framework.
Software- und Web-Engineering I · TH Lübeck
Was ein Framework sonst noch mitbringt
Komponenten
Wiederverwendbare Bausteine mit eigener Logik und eigenem Aussehen.
Zustandsverwaltung
Ein definierter Ort für den Zustand statt verteilter Variablen.
Routing
Mehrere Ansichten ohne vollständigen Seitenwechsel.
Ökosystem
Build-Werkzeuge, Testbibliotheken, Komponentensammlungen.
Nichts davon ist magisch. Alles davon könntet ihr selbst bauen, und in eurem Projekt habt ihr Teile davon selbst gebaut.
Software- und Web-Engineering I · TH Lübeck
React
Größte Verbreitung, Bibliothek statt Framework, sehr viele Zusatzentscheidungen.
Vue
Sanfter Einstieg, Template-Syntax nah an HTML.
Angular
Vollständiges Framework, TypeScript und Dependency Injection von Haus aus.
Svelte
Verlagert die Arbeit in den Compiler, wenig Laufzeit-Overhead.
Angular ist der direkte Anschluss an web-09: dieselbe DI-Idee, die ihr bei Spring gesehen habt, im Front-End.
Keine Versionsdetails: diese Folie altert schnell und wird jedes Jahr aktualisiert
Software- und Web-Engineering I · TH Lübeck
Warum der Kurs Frameworks verboten hat
Die Regel war didaktisch, nicht ideologisch:
Wer querySelector nie benutzt hat, versteht nicht, was React ihm abnimmt
Wer nie eine Fetch-Antwort von Hand ins DOM gebracht hat, debuggt später blind
Frameworks wechseln, das darunterliegende Plattformwissen bleibt
Reihenfolge
Erst das Fundament, dann die Abstraktion. Eine Abstraktion, deren Problem man nie hatte, ist nur zusätzliche Komplexität.
Ab jetzt dürft ihr. In SWE II und in euren eigenen Projekten ist ein Framework die normale Wahl.
Software- und Web-Engineering I · TH Lübeck
Der frameworklose Mittelweg
Web Components (web-06)
Standard im Browser, keine Abhängigkeit
Custom Elements, Shadow DOM, Slots
Framework-übergreifend einsetzbar
Aber
Kein deklaratives Rendering out of the box
Zustandsverwaltung müsst ihr selbst lösen
Weniger Werkzeuge und Beispiele
Für ein Design-System oder eine Handvoll wiederverwendbarer Bausteine sind Web Components oft die ruhigere Wahl. Für eine ganze Anwendung greift man meist zum Framework.
Custom Elements und Shadow DOM in web-06
Software- und Web-Engineering I · TH Lübeck
1 Frontend-Frameworks
2 SSR, SSG & Hydration
3 KI-gestützte Entwicklung
4 Web-Security-Basics
5 Wie geht es weiter?
Wo das HTML herkommt, das im Browser ankommt.
Software- und Web-Engineering I · TH Lübeck
CSR
Server schickt ein fast leeres HTML plus JavaScript. Der Browser baut die Seite.
SSR
Server baut das fertige HTML pro Anfrage und schickt es.
SSG
HTML wird beim Build erzeugt und liegt als Datei bereit.
Das kennt ihr schon
Thymeleaf (web-10) und Handlebars (web-12) sind SSR.
Software- und Web-Engineering I · TH Lübeck
Erste Anzeige
Gut geeignet für
CSR
spät: erst nach dem JavaScript
Anwendungen hinter dem Login, Dashboards
SSR
früh: HTML kommt fertig angut für Suchmaschinen
Inhalte, die pro Nutzer:in unterschiedlich sind
SSG
sofort: nur eine Datei ausliefern
Blogs, Dokumentation, Marketing-Seiten
Software- und Web-Engineering I · TH Lübeck
HTML vom Serversichtbar, aber tot
→
JavaScript lädtFramework startet
→
Ereignisse werden verknüpftSeite wird bedienbar
Hydration
Das Framework übernimmt im Browser das bereits vorhandene, serverseitig erzeugte HTML und macht es interaktiv, statt es neu aufzubauen.
Die Lücke dazwischen ist spürbar: die Seite ist sichtbar, aber Klicks passieren noch nichts. Ein häufig unterschätztes Problem.
Software- und Web-Engineering I · TH Lübeck
Meta-Frameworks verbinden beide Welten
Next.js (React), Nuxt (Vue), SvelteKit (Svelte), Analog (Angular)Pro Seite entscheidbar: statisch erzeugen, pro Anfrage rendern oder erst im Browser
Routing, Datenabruf und Build gehören zum Paket
Der Trend geht nicht zu „alles auf dem Server“ oder „alles im Browser“, sondern zur Wahl pro Seite .
Herstellerdokumentation; Details altern schnell und werden jährlich aktualisiert
Software- und Web-Engineering I · TH Lübeck
Warum das überhaupt gemessen wird
Largest Contentful Paint
Wann ist der größte sichtbare Inhalt da?
Interaction to Next Paint
Wie schnell reagiert die Seite auf Eingaben?
Cumulative Layout Shift
Springt das Layout beim Laden?
Diese Werte sind messbar, vergleichbar und beeinflussen die Sichtbarkeit in Suchmaschinen. Deshalb ist die Frage „wo entsteht das HTML“ eine Geschäftsfrage, keine Geschmacksfrage.
Core Web Vitals, web.dev
Software- und Web-Engineering I · TH Lübeck
1 Frontend-Frameworks
2 SSR, SSG & Hydration
3 KI-gestützte Entwicklung
4 Web-Security-Basics
5 Wie geht es weiter?
Ehrlich über das, was die meisten von euch längst benutzen.
Software- und Web-Engineering I · TH Lübeck
Wo Assistenten stark sind
Gut
Wiederkehrendes Gerüst: DTOs, Konfiguration, Boilerplate
Testfälle zu vorhandenem Code
Fremden Code erklären lassen
Fehlermeldungen einordnen
Erste Fassung, die man selbst überarbeitet
Schwach
Die richtigen Anforderungen finden
Architekturentscheidungen mit Folgen
Konsistenz über viele Dateien hinweg
Alles, was Domänenwissen aus eurem Projekt braucht
Erfundene Bibliotheken und Methoden, überzeugend formuliert
Software- und Web-Engineering I · TH Lübeck
Ein Assistent kann euch Code schreiben. Er kann nicht wissen, was eure Nutzer:innen brauchen.
Anforderungen und Anwendungsszenarien (P2 ) entstehen aus Gesprächen, nicht aus Prompts
Die MVP-Auswahl (P4 ) ist eine Entscheidung über Wert und Aufwand in eurem Kontext
Die Architektur muss zu eurem Team passen, nicht zum Durchschnitt des Trainingsdatensatzes
Die Anforderungsarbeit bleibt eure Arbeit. Genau sie ist der Teil des Berufs, der nicht wegautomatisiert wird.
Anforderungserhebung in swt-04 und swt-05
Software- und Web-Engineering I · TH Lübeck
Verantwortung bleibt bei euch
Ihr gebt Code ab, den ihr erklären können müsst : im Praktikum wird genau danach gefragt
Generierter Code ist ungeprüfter Code, bis ihn jemand gelesen und getestet hat
Lizenz- und Datenschutzfragen: was ihr in ein Werkzeug eingebt, verlässt euren Rechner
Prüfungsrechtlich gelten die Regeln des Kurses und der Hochschule, nicht die Gewohnheit
Die Präsentationskriterien in P4 prüfen Hintergrundwissen. Wer den eigenen Code nicht erklären kann, verliert dort Punkte, unabhängig davon, wie er entstanden ist.
Software- und Web-Engineering I · TH Lübeck
In die Runde gefragt, ehrlich und ohne Bewertung:
Wofür habt ihr im Projekt Assistenten benutzt?
Wo hat es euch wirklich Zeit gespart?
Wo habt ihr am Ende mehr Zeit mit Nachbessern verbracht als gespart?
Software- und Web-Engineering I · TH Lübeck
1 Frontend-Frameworks
2 SSR, SSG & Hydration
3 KI-gestützte Entwicklung
4 Web-Security-Basics
5 Wie geht es weiter?
Drei Angriffe, die euer Projekt heute betreffen.
Software- und Web-Engineering I · TH Lübeck
Cross-Site Scripting (XSS)
Der Angriff: Fremder Text landet als Code in eurer Seite.
el.innerHTML = kommentar;
Enthält kommentar ein <script> oder ein<img onerror="...">, führt der Browser es aus.
Die Gegenmaßnahme:
el.textContent = kommentar;
textContent schreibt Text , niemals MarkupFrameworks maskieren beim Rendern automatisch
Wer die Maskierung umgeht, ist wieder angreifbar
Das betrifft euer Projekt direkt: innerHTML mit Daten aus einem Eingabefeld ist der häufigste XSS-Weg.
OWASP Top Ten · innerHTML in web-05
Software- und Web-Engineering I · TH Lübeck
Der Angriff: Eingaben werden Teil der Abfrage.
"SELECT * FROM users WHERE name = '"
+ name + "'"
Mit name = ' OR '1'='1 liefert die Abfrage alle Datensätze.
Die Gegenmaßnahme: Werte binden statt zusammenkleben.
JPA und TypeORM erzeugen parametrisierte Abfragen
Repository-Methoden und Query-Parameter sind bereits sicher
Gefährlich wird es erst bei selbst gebautem SQL
Wer Spring Data oder TypeORM so benutzt, wie es in web-10 und web-12 gezeigt wurde, ist hier bereits geschützt.
OWASP Top Ten · Repositories in web-10, ORM in web-12
Software- und Web-Engineering I · TH Lübeck
Unsichere Eingaben und Authentifizierung
Typische Fehler
Nur im Front-End validieren
Passwörter im Klartext speichern
Autorisierung nur über eine ausgeblendete Schaltfläche
Geheimnisse im Repository
Im Kurs-Stack
Validation Pipes und DTO-Validierung (web-12)
Spring Security mit gehashten Passwörtern (web-10)
Prüfung im Back-End , bei jeder Anfrage
Konfiguration über Umgebungsvariablen
Front-End-Validierung ist Bedienkomfort, keine Sicherheit. Wer die Anfrage direkt schickt, umgeht sie vollständig.
OWASP Top Ten · Spring Security in web-10, Validation in web-12
Software- und Web-Engineering I · TH Lübeck
Frameworks schützen euch nur so lange, wie ihr sie nicht umgeht.
Die drei typischen Umgehungen:
innerHTML statt textContent, weil Markup gebraucht wirdSelbst gebautes SQL statt Repository-Methode, weil die Abfrage komplizierter war
Ein Endpunkt ohne Berechtigungsprüfung, weil er „nur intern“ benutzt wird
Wenn ihr eine Abkürzung nehmt, schreibt einen Kommentar dazu, warum sie sicher ist. Wenn euch keiner einfällt, ist sie es nicht.
Software- und Web-Engineering I · TH Lübeck
1 Frontend-Frameworks
2 SSR, SSG & Hydration
3 KI-gestützte Entwicklung
4 Web-Security-Basics
5 Wie geht es weiter?
Das Semester läuft aus, die Themen nicht.
Software- und Web-Engineering I · TH Lübeck
Im Studium
SWE II : baut auf diesem Stack aufProjekte und Praktika: hier zahlt sich Plattformwissen aus
Abschlussarbeiten mit Web-Anteil
Selbst weitermachen
Ein kleines Framework-Projekt bauen: euer Projekt-Front-End noch einmal, diesmal mit React oder Vue
MDN als Referenz, nicht als Tutorial-Sammlung
Den eigenen Projektcode in einem halben Jahr noch einmal lesen
Der Unterschied zwischen „kann ein Framework bedienen“ und „versteht Web-Entwicklung“ ist genau das, was ihr dieses Semester aufgebaut habt.
Software- und Web-Engineering I · TH Lübeck
Diese Woche
Endabgabe P4 am Sonntag, 17.01.Danach: Abschlussgespräche im Praktikum
Nächste Woche
Projekt-Pitches in der VorlesungHinweise zur Klausuranmeldung
Fragen zur Klausur mitbringen
Denkt an die Klausuranmeldung. Die Frist liegt vor dem Prüfungszeitraum und wird nicht verlängert.
Software- und Web-Engineering I · TH Lübeck
Fragen?
Software- und Web-Engineering I · TH Lübeck
- Vorletzte Mi-Vorlesung, Endabgabe P4 am Sonntag darauf (17.01.)
- Bewusst leichterer Termin in der Endphase der Umsetzung
- Vier Kurzthemen statt eines Monolithen
- Kurz wuerdigen, was sie geschafft haben, das ist ehrlich gemeint
- Direkt die React-Frage ansprechen, sie kommt sonst als Zwischenruf
- Ausdruecklich sagen, dass nichts davon in der Klausur vorkommt
- Das nimmt den Druck und erhoeht die Aufmerksamkeit
- An konkrete Erlebnisse aus den Praktika anknuepfen
- Wichtig fuer die Motivation: das Problem zuerst, die Loesung danach
- Das ist die eine Idee, die sie mitnehmen sollen
- Alles andere an React ist Beiwerk gegenueber dieser Umkehrung
- Code nicht Zeile fuer Zeile erklaeren, nur den Unterschied im Blick zeigen
- Ausdruecklich sagen: JSX muessen sie nicht koennen
- Komponenten kennen sie aus web-06 als Web Components
- Zustandsverwaltung ist der Punkt, an dem eigene Loesungen am schnellsten kippen
- Keine Empfehlung aussprechen, die Wahl haengt am Team und am Projekt
- Bruecke zu web-09 betonen, DI ist kein Back-End-Thema
- Die Aufloesung, auf die sie das ganze Semester gewartet haben
- Ehrlich sagen: die Regel war unbequem und trotzdem richtig
- Nicht als Framework-Ersatz verkaufen, sondern als anderen Zuschnitt
- Beispiel: Firmen-Designsystem, das in mehreren Frameworks benutzt wird
- Anknuepfen: serverseitiges Templating kennen sie schon
- Vierte Spalte ist der Aha-Moment: SSR ist fuer sie nichts Neues
- Der Begriff ist neu, die Sache nicht
- Nicht auswendig lernen lassen, die Logik dahinter reicht
- Faustregel: je persoenlicher der Inhalt, desto weniger vorab erzeugbar
- Die tote Phase ist der Punkt, den man erlebt haben muss
- Beispiel: Cookie-Banner, der erst nach zwei Sekunden auf Klicks reagiert
- Keine Version, keine API-Details, das altert zu schnell
- Kernbotschaft: die Entscheidung ist granularer geworden
- Nur nennen, nicht vertiefen, Details gehoeren nicht in dieses Semester
- Bruecke: Performance ist eine Qualitaetsanforderung, vgl. swt-05
- Offener, ehrlicher Ton, keine Verbotsvorlesung
- Die rechte Spalte an einem eigenen Beispiel belegen, wenn moeglich
- Der letzte Punkt rechts ist der gefaehrlichste, weil er plausibel aussieht
- Das ist die wichtigste Folie des Abschnitts
- Motivierend formulieren, nicht als Drohung
- Klar und ohne Drohgebaerde formulieren
- Auf die Kursregeln im Lernraum verweisen
- Ausdruecklich sagen, dass das keine Pruefungssituation ist
- Selbst ein eigenes Beispiel beisteuern, das senkt die Hemmschwelle
- Erfahrungsgemaess kommt viel bei „mehr Zeit mit Nachbessern“
- Bewusst nur drei, dafuer mit konkretem Bezug zum Kurs-Stack
- Direkt in ihrem eigenen Code zu finden, das macht es konkret
- Kurz zeigen, wie ein onerror-Payload aussieht, nicht ausfuehrlich
- Entwarnung ist hier ehrlich: ihr ORM schuetzt sie
- Aber: native queries und String-Konkatenation heben den Schutz auf
- Der Merksatz unten ist die Botschaft des Abschnitts
- Kurz zeigen, wie leicht man eine Anfrage mit curl direkt schickt
- Der letzte Satz ist eine brauchbare Heuristik fuer die Praxis
- Verweis auf die Code-Qualitaetskriterien der P4 im Leitfaden
- Ehrlich motivierend abschliessen
- Der Vorschlag, das eigene Front-End mit einem Framework nachzubauen, ist praktisch und machbar
- Konkrete Daten aus dem Terminplan einsetzen
- Anmeldefrist ausdruecklich nennen, das wird jedes Jahr vergessen
- Zeit fuer Rueckfragen lassen
- Falls keine kommen: nach Wuenschen fuer die Pitch-Vorlesung fragen