Wir spielen wieder Glücksrad und lassen uns durch eine bunte Mischung aus React- und TypeScript-Themen treiben. Mit dabei sind diesmal Stefan, Peter und Hans-Christian Otto und wie schon beim letzten Mal zeigt sich schnell: Ein einzelnes Thema reicht locker für eine halbe Stunde Diskussion.

Wir hangeln uns vom React-Compiler über TypeScript Assertion Signatures bis hin zu useState und verlieren uns dabei genüsslich in Details, Meinungen und Abschweifungen zu Compilern, CDNs und Programmierparadigmen.

Gleichzeitig wird kritisch hinterfragt, wie sinnvoll diese automatischen Optimierungen sind, da Memoization selbst Kosten verursacht und in vielen Fällen kaum messbare Vorteile bringt. Zudem kann der Compiler problematisch werden, wenn Code nicht den üblichen React-Konventionen folgt und dadurch unerwartete Bugs entstehen.

Ein weiterer Diskussionspunkt ist die grundsätzliche Rolle von Compile-Schritten im JavaScript-Ökosystem. Während Compiler-Optimierungen etabliert sind, wird auch kritisiert, dass Bundling und ähnliche Techniken moderne Browserfähigkeiten wie deduplizierte Ressourcen oder modulare Nutzung aushebeln können. In diesem Zusammenhang wird auch nostalgisch auf frühere CDN-Modelle geblickt, bei denen Bibliotheken zentral geladen wurden, mit allen Vor- und Nachteilen bezüglich Performance, Sicherheit und Kontrolle.

Typische Anwendungsfälle sind Assertions wie in Testframeworks oder Validierungsfunktionen, bei denen im Fehlerfall eine Exception geworfen wird. Nach erfolgreichem Durchlauf kann der Code davon ausgehen, dass bestimmte Bedingungen erfüllt sind.

Die Diskussion zeigt aber auch Schwächen in der TypeScript-Dokumentation auf: Manche Features sind schwer auffindbar oder nur in Release Notes dokumentiert. Zudem wird darauf hingewiesen, dass Keywords wie is oder asserts besondere Aufmerksamkeit erfordern, da sie direkten Einfluss auf das Typsystem nehmen.

Neben der eigentlichen Funktionalität wird auch über die Komplexität des TypeScript-Ökosystems gesprochen, etwa beim Schreiben eigener Parser oder beim Umgang mit nicht vollständig dokumentierten Sprachfeatures.

Die Diskussion zeigt jedoch deutliche Kritik an der API: Die Syntax wird als umständlich empfunden, insbesondere bei komplexeren Zuständen oder wenn Werte voneinander abhängen. Auch typische Fehlerquellen wie asynchrone Updates oder falsche Nutzung beim Ableiten neuer Zustände werden thematisiert.

Ein wiederkehrendes Problem ist, dass viele Entwickler useState verwenden, um Werte zu speichern, die eigentlich nur aus anderen Zuständen berechnet werden sollten. Das führt zu unnötigen Re-Renders und erhöht die Komplexität.

Darüber hinaus wird useState im Kontext von Programmierparadigmen diskutiert. Während React stark funktional geprägt ist, kommen viele Entwickler aus objektorientierten Hintergründen und erwarten andere Modelle, etwa Klassen mit Properties. Diese Diskrepanz führt häufig zu Missverständnissen und erschwert den Einstieg.

Gleichzeitig wird anerkannt, dass React durch seine Architektur Vorteile für zukünftige Konzepte wie paralleles Rendering bietet, auch wenn diese in der Praxis bisher selten eine Rolle spielen.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/