Working Draft

In dieser Revision sprechen wir mit Marius Kleidl (Web [https://mariuskleidl.net/] / LinkedIn [https://www.linkedin.com/in/marius-kleidl/] / Mastodon [https://mastodon.social/@acconut] / GitHub [https://github.com/Acconut]), Webentwickler bei Transloadit [https://transloadit.com/] und Mitwirkender am Open-Source-Projekt TUS [https://tus.io/], über das Thema Resumable Uploads – also Datei-Uploads, die fortgesetzt werden können, wenn zwischendurch mal die Verbindung abraucht oder das Tab versehentlich geschlossen wird. SCHAUNOTIZEN [00:01:13] Resumable Uploads Wir starten mit der Frage, warum klassische Upload-Methoden im Web oft unzuverlässig sind – vor allem bei großen Dateien wie Videos. Gerade bei instabilen Verbindungen oder auf Mobilgeräten ist Frust vorprogrammiert: Einmal abbrechen heißt meistens von vorne anfangen. Mit Resumable Uploads gehört das der Vergangenheit an. Stattdessen kann der Upload pausieren, später fortgesetzt werden – ganz ohne Datenverlust. Im Zentrum der Folge steht TUS [https://tus.io/], ein Open-Source-Protokoll für Resumable Uploads, das Marius mitentwickelt. Wir reden über die Entstehung des Projekts, die technischen Grundlagen und wie man TUS in eigene Anwendungen integriert – sei es in Node.js, Go oder mit vorhandenen Client-Libraries. Besonders spannend: Die Spezifikation wird derzeit mit der IETF abgestimmt [https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/], mit dem Ziel, Resumable Uploads langfristig als offiziellen HTTP-Standard zu etablieren. Marius gibt uns außerdem einen Einblick in die Community-Arbeit hinter TUS, den Beitrag anderer Open-Source-Projekte und wie Entwickler:innen durch eigene Implementierungen zur Verbesserung beitragen können. Wir streifen Themen wie Caching, Storage-Backends und was eigentlich alles im Hintergrund passieren muss, damit so ein Upload wirklich „resumable“ ist. Natürlich kommen auch die praktischen Fragen nicht zu kurz: Was muss man beachten, wenn man Resumable Uploads in ein bestehendes Projekt integriert? Wie sieht die Kommunikation zwischen Client und Server aus? Und wie viel Aufwand steckt wirklich dahinter? LINKS TUS-Projekt [https://tus.io/] Die offizielle Webseite des TUS-Projekts, welches Resumable Uploads ermöglicht. Transloadit [https://transloadit.com/] Der Dienstleister für File-Processing, der Resumable Uploads unterstützt und individuelle Lösungen anbietet. Uppy [https://uppy.io/] Ein Open-Source-Projekt, das eine flexible API für den Datei-Upload aus verschiedenen Quellen bereitstellt.

Peter, Stefan und Vanessa besprechen auch diese Woche wieder die Ergebnisse des State of JS 2024 [https://2024.stateofjs.com/en-US]. In Teil 1 [https://workingdraft.de/653/] stürzten sich die Hosts vor allem auf die neuen JavaScript Features, in Teil 2 [https://workingdraft.de/655/] besprachen sie die Pain Points von JavaScript und Browser APIs,  die Leseliste und die Bibliotheken. In diesem vorletzten Teil schaffen die Hosts ganze zwei weitere Seiten der Umfrage: Meta-Frameworks und Testing. SCHAUNOTIZEN [00:01:17] Meta-Frameworks Die Hosts wenden sich zunächst der Frage zu, was Meta Frameworks denn eigentlich sind. Bekannte Namen sind Nuxt [https://nuxt.com/], Next.js [https://nextjs.org/], Remix [https://remix.run/], SvelteKit [https://svelte.dev/], etc. Doch was genau was so ein Meta Framework aus? Ist es eine „All in One“ Lösung? Muss es zwangsweise auf einem anderen Framework basieren? Das bringt uns auch zu einer Endlos-Diskussion: Ist React ein Framework oder eine Library (deutsch: Bibliothek)? Wobei, React hat diese Frage nun selbst beantwortet: Es ist eine Library [https://react.dev/#:~:text=with%20a%20framework-,React%20is%20a%20library,-.%20It%20lets%20you]. Nun gut, die Hosts einigen sich darauf, dass man eine gewisse Erwartungshaltung an Meta-Frameworks hat: Sie kommen mit einem Router [https://entwickler.de/javascript/vuejs-unter-der-lupe-der-vue-router], Zustandsverwaltung (State Management) [https://entwickler.de/webentwicklung/die-sache-mit-dem-state], SSR und SSG [https://www.it-schulungen.com/wir-ueber-uns/wissensblog/was-ist-ssr-und-ssg.html] und weiteren bereits eingebauten Features. Meta-Frameworks kommen mit diesen vielen nützlichen Features, keine Frage. Dennoch stellt man auch eine neue Abhängigkeit her. Das Benutzen dieser Meta-Frameworks kann es schwieriger machen, Bugs zu finden und zu fixen. Wie so oft, wenn man nicht mehr die Kontrolle über den kompletten Code hat. Sie können auch mit Sicherheitslücken kommen, wie es kürzlich der Fall bei Next.js [https://www.heise.de/en/news/Next-js-Critical-gap-allows-web-apps-to-be-compromised-10327299.html] war. Wie auch in den beiden vorherigen Teilen sind sich die Hosts wieder in einem Punkt sicher: Es kommt auf die Entwickler:innen an, nicht auf das Meta-Framework. Kleine Bibliotheken wie Eleventy [https://www.11ty.dev/] sind dennoch immer eine gute Wahl. Das liegt bei Eleventy daran, dass man HTML und CSS losgelöst von dem Tool schreibt. Das ermöglicht eine leichte Migration in der Zukunft. [00:43:32] Testing Bei dem Thema Testing leben die Hosts in verschiedenen Welten. Während Vanessa sich schon seit Jahren mi Tests in der Welt von Frontend Frameworks beschäftigt, hat der in der Rust [https://www.rust-lang.org/]-Welt lebende Stefan kaum Berührungspunkte mit Framework-Component Testing und kann die ganze Problematik daher gar nicht so genau nachvollziehen. Vanessa klärt also zunächst einmal über die ganze Tragödie von Unit Tests [https://entwickler.de/testing/unit-testing-nach-frontend-art] über Component Tests [https://web.dev/learn/testing/get-started/component-testing?hl=de] zu End to End Tests [https://www.testautomatisierung.org/lexikon/e2e-testing/] oder doch auch Visual Regression Tests [https://bleech.de/blog/wie-funktioniert-visual-regression-testing/] und Snapshot Tests [https://www.novatec-gmbh.de/insights/blog/wann-snapshot-testing-dich-ueberschnappen-lassen/] auf. Die Umfrage verrät, dass aktuell viel Jest [https://jestjs.io/] eingesetzt wird, jedoch niemand mehr so richtig glücklich mit diesem Tool ist. Vitest [https://vitest.dev/] ist stark auf dem Vormasch, genauso wie Playwright [https://playwright.dev/]. In Revision 652 [https://workingdraft.de/652/] sprach kürzlich erst Stefan Judis [https://www.stefanjudis.com/] über automatisiertes Testing mit Playwright. ÄHNLICHE REVISIONEN * Revision 655: State of JS 2024, Teil 2/4 [https://workingdraft.de/655/] * Revision 653: State of JS 2024, Teil 1/4 [https://workingdraft.de/653/] * Revision 652: Automatisiertes Testing mit Playwright [https://workingdraft.de/652/] * Revision 633: State of CSS 2024, Teil 1/3 [https://workingdraft.de/633/] * Revision 634: State of CSS 2024, Teil 2/3 [https://workingdraft.de/634/] * Revision 635: State of CSS 2024, Teil 3/3 [https://workingdraft.de/635/]

Peter, Stefan und Vanessa besprechen weiterhin die Ergebnisse des State of JS 2024 [https://2024.stateofjs.com/en-US], so wie in der Vergangenheit auch bereits der State of CSS (Revision 633-635) besprochen wurden. In Teil 1 [https://workingdraft.de/653/] stürzten sich die Hosts vor allem auf die neuen JavaScript Features. Nun geht es weiter mit den Schmerzpunkten von JavaScript und Browser APIs,  der Leseliste und den Bibliotheken. SCHAUNOTIZEN [00:01:35] JavaScript Pain Points Die JavaScript Pain Points Angaben in der Umfrage kamen durch eine Freitext Eingabe in der Umfrage zustande, Wie Peter, Stefan und Vanessa finden, eine wichtige Zusatzinformation, um die Ergebnisse etwas besser interpretieren zu können. Denn diese sind bei näherem Betrachten der eigentlichen Antworten gar nicht mehr so konkret wie die Liste an Kurzantworten erst erscheinen lässt. Ein viel besprochenes Thema ist EcmaScript Module & Common JS. Das ES Module ist ein standardisiertes JavaScript-Modulsystem, das in ECMAScript 2015 (ES6) eingeführt wurde. Es wird in modernen Browsern und Node.js unterstützt. Das CJS Modulsystem wird hauptsächlich in Node.js verwendet. Es wurde entwickelt, bevor JavaScript ein offizielles Modulsystem hatte. Vor allem die Migration von CJS auf ESM wird als komplex und kompliziert genannt. Ebenfalls benannt wird das Fehlen von Typen. Hierbei kommen Peter und Stefan zu dem Schluss, dass man TypeScript „einfach“ dazu installieren, oder notfalls per IDE Extension hinzufügen kann. Sie sind also anderer Meinung als die Umfrage Ergebnisse. Der nächste Schmerzpunkt, der genannt wird, ist der, der fehlenden Standardbibliothek. Hier argumentiert Stefan, dass das eigentlich kein Problem von der Sprache JavaScript, sondern der Runtime sei. Er streut nebenbei das Wissen herein, dass es ein Standard Committee gibt, dass sich nun um serverseitige Runtimes kümmern wird: das TC55 [https://ecma-international.org/technical-committees/tc55/]. Stefan erzählt weiterhin, Rust [https://www.rust-lang.org/] hätte noch viel weniger Standards, da wäre alles frei konfigurierbar. Der letzten besprochenen Schmerzpunkt ist die asynchrone Programmierung. Da hätte Stefan gerne viele mehr Prozente gesehen. Denn gerade seit es async/await [https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Statements/async_function] gibt, gibt es viele Verständnislücken über die asynchrone Programmierung. Er weist auf den hilfreichen Blogartikel „What color is your function [https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/]“ von Bob Nystrom hin. [00:30:35] Browser API Pain Points und Readlist Die Liste der Schmerzpunkte über Browser APIs ist doch sehr erheiternd zu lesen: Safari und Firefox. Und eigentlich auch Chrome. Peter, Stefan und Vanessa arbeiten sich durch die Liste und finden heraus: Das Hautproblem sei wohl, dass Chrome einige APIs freischaltet, die die anderen Browser noch nicht unterstützen. Dadurch gibt es Indifferenzen zwischen den Browsern. Doch ob es wirklich die Lösung ist, dass Chrome sich besser absprechen könnte? In Teil 1 [https://workingdraft.de/653/] besprachen die Hosts das JavaScript Feature error.cause [https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Error/cause]. Umso schöner nun zu sehen, dass viele der Ausfüllenden der Umfrage sich auch dieses Feature auf die Leseliste gesetzt haben. [00:44:04] Bibliotheken Über die Bibliotheken gibt es massig viele Daten anzuschauen. Doch für wen sind diese nun eigentlich interessant? Vermutlich eher, wenn man Inhalte für Blogartikel und Vorträge sammelt. Dennoch wüten sich Peter, Stefan und Vanessa durch die Daten. Webpack ist das meistebenuzte Tool, jedoch nicht das Beliebteste. React und Vite stehen beide hoch im Kurs. Zum konkreten Thema der JavaScript Frameworks besprechen die Hosts, dass man wohl irgendwie eine Entscheidung treffen muss – und richtig falsch ist keine, aber wohl oft trifft man wohl auch nicht die Richtige, wie man an den Schmerzpunkten wieder sieht. Denn hier werden Frameworks auch oft als zu komplex beschrieben. Die Hosts finden, dass Entwickler und Entwicklerinnen generell flexibel sein müssen in ihrem Beruf. Und jederzeit zwischen Frameworks wechseln können sollten. LINKS * State of JS – Outreach [https://dev.to/sachagreif/state-of-js-2024-outreach-and-diversity-report-n0e#fn-footnotes-1] ÄHNLICHE REVISIONEN * Revision 653: State of JS 2024, Teil 1/4 [https://workingdraft.de/653/] * Revision 633: State of CSS 2024, Teil 1/3 [https://workingdraft.de/633/] * Revision 634: State of CSS 2024, Teil 2/3 [https://workingdraft.de/634/] * Revision 635: State of CSS 2024, Teil 3/3 [https://workingdraft.de/635/]

Wusstet ihr, dass man mit der richtigen TypeScript-Config plötzlich wieder Lust auf JavaScript bekommt? Kein Witz – wir haben’s ausprobiert! SCHAUNOTIZEN [00:01:08] TypeScript 5.8 [https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/] Wir steigen ein mit einem TypeScript-Feature, das Stefan so begeistert hat, dass er direkt eine ganze Revision darüber machen wollte: die „Erasable Syntax Only“-Option. Wir diskutieren, warum diese Einstellung TypeScript endlich wieder zu einem erfreulichen Tool macht – besonders in Verbindung mit einer besseren Developer Experience und weniger magischem Code. Danach nehmen wir TypeScript in Node-Projekten auseinander, sprechen über das Für und Wider von Linting vs. Type-Checking zur Laufzeit und streifen dabei auch Themen wie Build-Systeme, tsc vs. esbuild und warum man manchmal doch wieder Bock auf „einfaches JavaScript“ bekommt. Zum Ende hin geht’s noch kurz um die Realität in Teams, in denen nicht alle TypeScript gleich intensiv nutzen – und um die Frage, ob TypeScript bald nur noch Linter mit Typen sein sollte.

Peter, Stefan und Vanessa besprechen die Ergebnisse des State of JS 2024 [https://2024.stateofjs.com/en-US], so wie in der Vergangenheit auch bereits der State of CSS (Revision 633-635) besprochen wurden. In Teil 1 stürzen sich die Hosts vor allem auf die neuen JavaScript Features. SCHAUNOTIZEN [00:03:44] State of JS 2024 – Teil 1 Peter, Stefan und Vanessa sind sich zumindest bei Einem einig: Die Motivation, um die Umfragen „State of X“ auszufüllen, ist die eigene Weiterbildung. Dieses Jahr gab es 14.000 Personen, die die Umfrage ausgefüllt haben. Ob die Ergebnisse generell nur eher etwas über Enthusiasten aussagt? Egal ob JS, HTML [https://2024.stateofhtml.com/en-US] oder CSS [https://2024.stateofcss.com/en-US]. Gar nicht mehr zu einig waren sie sich dann darin, wie interessant die einzelnen abgefragten JavaScript Features sind, oder auch wie interessant die Ergebnisse davon. Zuerst widmen sich die Hosts der Funktion groupBy. Doch vielmehr als nur über die Funktion zu sprechen, besprechen Peter, Stefan und Vanessa, ob es sich lohnt, bestehende Alternativen mit der nun nativen Funktion auszutauschen. Stefan spricht sich für eine Verschlankung der Codebasis aus und plädiert dafür, neue Sprachfunktionen zu nutzen, sobald sie verfügbar sind. Peter wirft die Frage auf, welcher bestehende Code dadurch ersetzt würde. Ein Beispiel dafür ist eine selbstgeschriebene groupBy-Funktion, die nicht ersetzt wird, weil sie gut funktioniert und leicht anders arbeitet als mögliche Alternativen. Zudem gibt es hier kein Risiko. Anders sieht es aus, wenn externe Programmbibliotheken ins Spiel kommen – hier könnten unvorhergesehene Änderungen auftreten, und generell ist das Ziel, die Anzahl an Abhängigkeiten möglichst gering zu halten.Im Gespräch über die bekannte Bibliothek Lodash wird darauf hingewiesen, dass man das Rad nicht neu erfinden möchte. Gleichzeitig merkt Peter an, dass es in bestimmten Fällen doch notwendig sein kann, eigene Lösungen zu schreiben, um spezielle Anforderungen zu erfüllen. Insgesamt herrscht jedoch Einigkeit darüber, dass Lodash nicht mehr zeitgemäß ist. Viele seiner Funktionen stammen aus einer anderen Entwicklungsära und lassen sich mittlerweile durch native Sprachmittel ersetzen. [00:21:03] Syntax features: Private Fields, error.cause Neben diesen strategischen Überlegungen geht es auch um aktuelle Neuerungen in JavaScript. Private Felder für Klassen erweisen sich als nützlich, um Objekte zu erweitern – etwa durch zusätzliche Methoden für Zeichenketten oder Mengen. Die Fehlerbehandlung wird mit der cause-Eigenschaft verbessert. Damit ist es möglich, einen abgefangenen Fehler mit einer neuen Meldung erneut auszulösen und dabei die ursprüngliche Ursache zu erhalten, was insbesondere für Fehlerprotokollierung nützlich ist. Wer sich näher damit beschäftigen möchte, findet eine ausführliche Beschreibung bei MDN [https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Error/cause]. [00:30:36] Nullish Coalescing Ein weiteres Thema ist der sogenannte Nullish Koaleszenzoperator (??), die sich vom logischen Oder-Operator (||) dadurch unterscheidet, dass sie nur bei null und undefined greift, während || auf alle falschen Werte reagiert – also auch auf false, die Zahl 0, leere Zeichenketten oder NaN. Beide Operatoren lassen sich beliebig verketten. MDN [https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing]. Eng damit verbunden ist die Kurzschreibweise für logische Zuweisungen (||=), die es ermöglicht, Werte nur dann zu setzen, wenn sie bislang einen falschen Zustand haben. MDN [https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Operators/Logical_OR_assignment]. Ein weiteres kleines, aber oft übersehenes Detail ist die sogenannte Hashbang-Syntax (#!). Diese ist vor allem in Kommandozeilen-Werkzeugen von Bedeutung, die in JavaScript geschrieben sind. Sie ermöglicht es, Skripte ohne expliziten Aufruf der Laufzeitumgebung auszuführen, etwa beim Starten eines Programms aus einer Paketkonfigurationsdatei heraus. [00:34:40] Logical Assignment Inneren Feldern von Objekten lassen sich nun auch neue Werte zuweisen, wenn ihr aktueller Wert falsy ist. Also wiederum nun wieder alle falsy Werte im Gegensatz zu dem vorher besprochenem Thema. [00:41:12] String Features, Array Features Beim Blick auf die neuen Möglichkeiten zur Verarbeitung von Zeichenketten zeigt sich, dass diese nur selten gebraucht werden. Ein Beispiel ist die Methode replaceAll, die etwa genutzt werden kann, um überflüssige Leerzeichen aus nutzergenerierten Inhalten zu entfernen. Zum Thema Array Features gibt es eine Liste von Funktionen, die es eigentlich vorher auch schon so gab – nur jetzt sind die Objekte immutable geworden. Also die Funktion ändert nicht mehr das Originalobjekt, sondern gibt ein neues Array wieder. Doch ihr Nutzen hält sich unserer Hosts nach in Grenzen. Besonders in reaktiven Anwendungsarchitekturen wie React könnten sie jedoch für die Verarbeitung unveränderlicher Daten hilfreich sein. [00:46:36] Async Features, Set Features, Group Features, Language Pain Points In der asynchronen Programmierung zeigt sich, dass Promise.allSettled hilfreich ist, wenn auf mehrere Dateien für die Lokalisierung einer Anwendung gewartet werden muss. Neue Funktionen für Mengen (Sets) sind zwar interessant, aber wären mit einer besseren grafischen Darstellung leichter verständlich gewesen. Die Beantwortung der Nutzungshäufigkeit von groupBy wird kritisch hinterfragt. Nur ein Drittel der Befragten gibt an, diese Funktion zu verwenden – doch möglicherweise liegt das auch daran, dass viele bereits eigene Lösungen im Einsatz haben. Schließlich geht es um den Einsatz von Programmiersprachen und Werkzeugen. Die Nutzung von TypeScript ist ungebrochen hoch, mit einer Umfragequote von nahezu 100 Prozent. Künstliche Intelligenz spielt im Entwicklungsalltag eine eher untergeordnete Rolle: Ein Fünftel verzichtet ganz darauf. JavaScript wird von 95 Prozent der Befragten im Beruf eingesetzt, 40 Prozent programmieren auch in der Freizeit damit – wobei hier eine gewisse Überschneidung wahrscheinlich ist. [00:55:21] Browser APIs Abschließend widmen sich den Hosts den Antworten zum Thema der Browser APIs. Es gint viel Begeisterung für die bevorstehende Temporal-API, die die Arbeit mit Zeitwerten erheblich vereinfachen wird. MDN [https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Temporal]. Ein oft geäußerter Wunsch bleibt die Einführung statischer Typisierung direkt in JavaScript sowie umfangreichere Standardbibliotheken. LINKS * State of JS – Outreach [https://dev.to/sachagreif/state-of-js-2024-outreach-and-diversity-report-n0e#fn-footnotes-1] ÄHNLICHE REVISIONEN * Revision 633: State of CSS 2024, Teil 1/3 [https://workingdraft.de/633/] * Revision 634: State of CSS 2024, Teil 2/3 [https://workingdraft.de/634/] * Revision 635: State of CSS 2024, Teil 3/3 [https://workingdraft.de/635/]