Mit zwölfjähriger Geschichte und über 5.000 Downloads pro Folge ist Working Draft
der etablierteste Podcast für Webentwickler im deutschsprachigen Raum.
Wenn ihr neue Entwicklerkollegen sucht oder ein Produkt für Webentwickler
anbietet, schreibt uns unter sponsoring@workingdraft.de.
Annähernd drei Jahre ist es her, dass wir zuletzt mit Oliver Schöndorfer (Twitter) über Typografie im Web reden durften. Seitdem ist viel passiert, unter anderem nämlich dass Oliver einen eigenen Youtube-Kanal zum Thema „Gute Schriftwahl“ ins Leben gerufen hat. Und genau über dieses Thema wollten wir mit ihm gerne reden. Wie geht man am besten vor, wenn man auf der Suche nach einer passenden Schriftart ist?
5. Januar 2021 | Kommentare deaktiviert für Revision 458: Cypress
In dieser Revision dürften wir Priyanka Kore und Tobias Struckmeier von der Adesso als Gäste begrüßen und mit Ihnen über End-to-End-Testing mit Cypress sprechen.
Bevor sich unser Gespräch auf Cypress einschießt, klären wir, inwiefern Tests hilfreich sind, welche Software-Test-Methodiken es gibt, und wie diese alle sich zur berühmten Testing-Pyramide zusammenfügen:
End-to-End-Tests (E2E) decken das ganze System ab und sind damit die umfassendsten Tests, sie durchzuführen stellt einen allerdings vor so manche Herausforderung:
ggf. fehlt die nötige Infrastruktur dafür
das Setup ist aufwändig
sie laufen langsam und sind ressourcenhungrig
das Management von Testdaten ist nicht einfach
sie sind schwer in bestehende Projekte zu bringen
und sie harmonieren nicht immer mit hochdynamischen SPA
Die meisten der genannte Probleme lassen sich darauf zurückführen, dass E2E-Tests über das recht eigene Selenium Webdriver gesteuert und sie in üblichen Browsern auf diversen Betriebssystemen durchgeführt werden. Mit dieser Vorgehensweise bricht Cypress und löst damit die meisten der oben genannten Probleme – und nimmt natürlich auch gewisse Nachteile in Kauf.
Cypress nutzt vom Fleck weg bestehende Browser im System und unterstützt alle Chromium-basierten Browser und den Mozilla Firefox. Desweiteren bringt Cypress auch einen eigenen Browser mit für den Fall, dass kein unterstützter Browser vorhanden ist, sowie hilfreiche Zusatztools wie Mocha, eine Assertion Library, Launcher/Runner, Reporter und einen Proxy. Unterstützt wird all das von einer exzellenten Dokumentation Cypress ist also schnell und ohne großen Aufwand installiert, es läuft deutlich schneller als Selenium, zum einen weil es lokal läuft, zum anderen weil man bei der Interaktion mit dem DOM anders vorgehen kann als in Selenium und es lassen sich Dinge wie XHR-Calls und/oder Testdaten durch integrierte Tools sehr einfach simulieren. Und schließlich kann man Tests bei Fehlern sofort stoppen und ein Entwickler übernimmt die Fehlersuche in dem noch offenen Browser.
Wie erwähnt, hat Cypress natürlich auch Nachteile, welche die folgenden wären:
Es werden nur Chromium- und Mozilla-Browser unterstützt
Cypress kann keine Tests durchführen, die mehr als einen Origin gleichzeitig umfassen
Cypress kann nicht mehrere Tests parallel durchführen, sofern man nicht deren payed Service nutzt
Es gibt keinen Standard-Weg Up- und Downloads zu testen, stattdessen viele mögliche Hacks
Außerdem sprechen wir im Verlauf der Sendung über über die automatische Erzeugung von bebilderten Anleitungen via Cypress-Book und über das Testen von einzelnen Komponenten in Isolation.
24. November 2020 | Kommentare deaktiviert für Revision 452: CORS, CORP, (C)ORB, COOP und COEP
Wie Ihr Euch erinnert, hatten wir in Revision 447Frederik Braun von Mozilla zu Gast, mit dem wir über den Themenblock „Cross-Site-Scripting“ gesprochen haben. Wir hatten damals noch einen zweiten Themenblock auf der Agenda, nämlich „Site Isolation“, zu dem wir aus Zeitgründen nicht mehr kamen und den wir auf eine zukünftige Folge vertagt haben. Hier kommt sie!
Schaunotizen
[00:01:46] CORS, CORP, (C)ORB, COOP und COEP
Zur Einführung gehen wir auf eine Angriffsmethode namens „Spectre“ und das Konzept der Site-Isolation ein, um das Problem zu verstehen, für das wir im Folgenden die Lösungen erörtern wollen. Außerdem rufen wir uns ins Gedächtnis, wie die „Same Origin Policy“ in den Browsern greift und wie man seit einigen Jahren per „Cross Origin Resource Sharing“ (CORS) darauf einwirken kann. Und wir klären den Unterschied zwischen „Same Site“ und „Same Origin“. Damit haben wir die Grundlagen gelegt, um einigermaßen neue, fest eingebaute Mechanismen wie (Cross) Origin Request Blocking (Video) ((C)ORB) zu Verstehen, aber vor allem auch, was es mit dem neuen „Cross-Origin Resource Policy“ (CORP) Header auf sich hat. Um es kurz zu machen: Während CORS dem Browser über Origin-Grenzen hinweg Zugriff auf per JavaScript weiterbearbeitete Ressourcen gewährt, verhindert entsprechend gesetztes CORP die passive Anzeige von von fremden Ursprüngen stammender, aber üblicherweise zulässiger Bausteinen wie etwa Bilder. Danach erörtern wir, was es mit einer Gruppe Sicherheitslücken namens „xsleaks“ auf sich hat, um zu verstehen, wie zwei weitere neue HTTP Header namens „Cross-Origin-Opener-Policy“ (COOP) und „Cross-Origin-Embedder-Policy“ (COEP) da hineinspielen. Weil diese ganzen Sicherheitsmaßnahmen die Funktionsweise der Seite stark beeinflussen, ist es ratsam, vor einem Scharfschalten von der Reporting API, respektive dem Report-to-Header Gebrauch zu machen (und Probleme zum Beispiel an sentry.io senden zu lassen). Ob wir am Ende alles richtig gemacht haben und unsere Seite erfolgreich abschotten konnten, können wir im Browser auf der globalen Property window.crossOriginIsolated / self.crossOriginIsolated abfragen. Als Belohnung für unsere Mühen eröffnet uns der Browser Zugang zu Features wie eine hohe Genauigkeit des DOMHighResTimeStamps, SharedArrayBuffers oder performance.measureMemory().
Viel zu lange ist es her (nämlich fast 6 Jahre), dass wir das letzte Mal über das Thema „Security“ im Frontend gesprochen haben. Mit Frederik Braun (@freddyb) von Mozilla haben wir endlich wieder jemand zu Gast, der sich damit auskennt und der uns über neue fiese Tricks und aktuelle wie auch zukünftige Abwehrstrategien ins Bild setzen kann.
Angefangen bei einer Begriffsdefinition von Cross-Site-Scripting, aka XSS, und ihrem historischen Einsatz arbeiten wir uns langsam vor zu den eher neueren Kategorien der „Script Gadgets (Video)“ (PDF) und der „Mutated XSS“ (Video) (Slides), bei denen im ersten Fall ein Frontend-Framework wie Bootstrap, und im zweiten die im Browser eingebauten (und standardisierten) HTML-Parser und -Serialisierer clever zu Komplizen gemacht werden. In solch einem Fall helfen einem Content Security Policy (CSP) oder auch Tools wie HTML Purifier, DOMPurify oder Bleach nicht. Und auch Chromes Konzept der Trusted Types dürfte für den Durchschnittsentwickler nicht geeignet sein. Deshalb arbeitet Frederik bei Mozilla neuerdings an einer in den Browser eingebauten HTML Sanitizer API, die all die oben beschriebenen Schwächen nicht hat (benötigt aktuell den Firefox Nightly mit aktiviertem dom.security.sanitizer.enabled-Flag in about:configure).
Natürlich war Preact der initiale Grund für Marvin, sich mit End-to-End-Testing-Frameworks zu beschäftigen, denn Marvin suchte nach einem Tool, das das von Preact erzeugte DOM extrahieren und gegen einen Snapshot testen konnte. Darüberhinaus arbeitet Marvin zur Zeit bei der Firma, die hinter den Tonie Boxen steckt. Und auch dort war man auf der Suche nach einem Testing-Framework, das den gesamten Flow von Inbetriebnahme einer neuen Tonie Box, über das Flashen per Web-Oberfläche hin zum Kauf und Teilen von Hörbüchern abtesten konnte. Karma mit dem darunter befindlichen WebDriver war für das Preact-Szenario nicht geeignet, weil es an bestimmten Stellen durch den genutzten Stack limitiert wird. An Jest wiederum stört, dass dieses keine echte Browser zum Testen nutzt, sondern nur ein simuliertes DOM (jsdom), das aber manche Dinge, wie zum Beispiel Intersection Observer nicht implementiert. Und wenn man Jest mit Puppeteer verknüpft, dann kann man keine zwei parallelen Browser-Instanzen steuern. Was macht man also, wenn man nichts vernünftiges findet? Genau! Sein eigenes Testing-Framework programmieren: pentf.
Nach SelfHTML feierten am 23. Juli 2020 auch die MDN Web Docs ein Jubiläum, nämlich ihr fünfzehnjähriges Bestehen. Für uns ein toller Anlass, einen Gast einzuladen, mit dem wir schon länger sprechen wollten: Kadir Topal, Mozilla-Urgestein und Product Lead der MDN Web Docs.
Für die Zukunft ist geplant, Einsteiger-Leitfäden in der MDN Learning Area bereitzustellen, die nicht mehr nur Browser-Technologien zum Fokus haben, sondern die beim Einstieg in JavaScript-Frameworks oder Node.js helfen.
Sollten wir Euer Interesse geweckt haben und Ihr Euch fragt, wie Ihr Euch in das Projekt einbringen könnt, dann ist hier der richtige Anlaufpunkt für Euch.
Wenn Ihr das MDN-Projekt lieber finanziell unterstützen möchtet, dann schaut Euch im MDN Web Docs Store um und vielleicht findet Ihr dort das eine oder andere an Merch, das Euch gefällt?
Lange geplant, jetzt in die Tat umgesetzt, haben wir diese Revision Harald Kirschner zu Gast, um über den gesamten Firefox Cosmos zu sprechen. Harald ist aktuell nicht nur Produkt Manager für die Firefox Developer Tools und Performance Tooling zuständig, sondern hat zuvor maßgeblich am Projekt „Quantum“ mitgewirkt, bei dem Firefox‘ Infrastruktur nach und nach durch modernere und performantere Bausteine ersetzt wurde.
„Quantum“ ist ein gutes Stichwort, denn dieses vor einem halben Jahrzehnt begonnene Projekt hat „Firefox Preview“ (interner Projektname „Fenix“) erst möglich gemacht: Einen mobilen Browser, der ganz ohne Tricksen und Abkürzen wahnsinnig schnell ist. Ein wesentlicher Bestandteil von „Quantum“, der das möglich gemacht hat, ist „Web Render“, eine neugedachte und fürs Web optimierte Render-Engine, die auf OpenGL basiert, multithreaded ist, und die für das Abbilden eines Rendertrees optimiert ist anstatt einen General-Purpose-Ansatz zu verfolgen. Und auf Firefox Preview wiederum basiert der neue GeckoView, der es anderen Produkten leicht macht, Gecko als Web-Engine zu integrieren.
Version 3 von Puppeteer bringt eine experimentelle Unterstützung von Firefox mit. Wir sprechen darüber, dass Puppeteer eigentlich das Chrome Debugging Protocol (CDP) nutzt und Firefox für die Anbindung an Puppeteer vom Mozilla-Team um CDP-Fähigkeiten erweitert wurde (und weiterhin wird). Wir sprechen außerdem kurz über Playwright, hinter dem auch viele der Puppeteer-Leute stecken, das eigens dafür gepatchedte Firefoxe und WebKits mitliefert. Und schließlich sprechen wir über CDP selbst, über die Frage, warum die Debugging Protokolle der verschiedenen Browser nicht kompatibel gemacht werden, sowie über die Unterschiede von CDP und der standardisierten Web Driver Schnittstelle, und wie Web Driver 3 irgendwann alles besser machen wird.
Intern hat Mozilla lange einen sehr mächtigen Profiler genutzt, um seine Fortschritte beim „Quantum“-Umbau besser messen zu können. Dieser steht uns jetzt allen zur Verfügung, und zwar nicht nur in Form eines mitgelieferten Devtools-Panels, sondern als externe Web-basierte App, die lokale Messungen anzeigt. Kollaborativ kann man die dann auch hochladen und mit anderen Entwickler per URL teilen und vergleichen. Die typischen Flame Charts und Call Trees lösen alles bis ins kleinste Detail auf und für die Abenteuerlichen können auch Firefox-Internals angezeigt werden.
Wer Lust bekommen hat, das Devtools-Team zu unterstützen und vielleicht sogar neue Features zu implementieren, findet hier alle relevanten Ressourcen für einen gelungenen Einstieg.
30. Juni 2020 | Kommentare deaktiviert für Revision 431: 25 Jahre SelfHTML
Anlässlich seines 25-jährigen Jubiläums und weil einige von uns ohne niemals zur Webentwicklung gekommen wären, luden wir Matthias Scharwies und Gunnar Bittersmann (bittersmann.de / @g16n) vom SelfHTML-Projekt in die Sendung ein.
Mit SelfHTML hat Schepp Ende der Neunziger Webseiten Coden gelernt und Rodney war damals sogar Contributor und Teil der SelfHTML-Community. Und nicht zuletzt liefen Schepp und Rodney sich im SelfHTML-Forum überhaupt das erste Mal über den Weg. Mit Matthias und Gunnar ließen wir die Geschichte des Projekts Revue passieren, von seinen Anfängen auf Diskette, dem später davon abgeleiteten Buch, von den Schwierigkeiten, so ein Projekt ohne Versionierungssystem mit mehreren Leuten zu bearbeiten und auf Stand zu halten, bis hin zur großen Implosion und der anschließenden Auferstehung mit modernem, handgeschriebenen Forensystem. Wir sprachen außerdem über die tolle Community und die nicht minder coolen, jährlichen „SelfTreffen“.
Zur Abwechslung beschäftigen wir uns in dieser Revision einmal nicht mit Technik, sondern mit dem relativ neuen Phänomen der Coding Bootcamps. Mit dabei sind Marie von der Wehl (marie.vonderwehl@sumcumo.com / @MarWehl), die ein solches Bootcamp im vergangenen Jahr bei neue fische in Hamburg durchlaufen ist, sowie Franziska Gertz (franziska.gertz@sumcumo.com / @frau_scholle), die als Teamlead für UI Engineers bei sum.como von vielen Vorzügen der Bootcamp-Abgänger zu berichten weiß.
Von Marie erfahren wir zunächst, wie sie als Logopädin auf die Idee kommt, es doch lieber mit der Programmiererei zu versuchen, und wie sie auf das Angebot der „neuen fische“ gestoßen ist. Wir reden darüber, wie der erste Kontakt zum Anbieter zustande kam und wie anschließend die Ausbildung im Schnelldurchlauf sowohl vom Ablauf her als auch inhaltlich vonstatten ging. Natürlich wollen wir auch wissen, wie sich solche Bootcamps ihre Leistung entlohnen lassen. Und schließlich interessiert uns, wie Marie sich nach der abgeschlossenen Ausbildung auf dem Arbeitsmarkt geschlagen hat.
Von Franzi wiederum bekommen wir attestiert, dass diese Bootcamps tatsächlich tollen Output liefern und ihre Firma derweil einige „neue fische“-Abgänger beschäftigt, nämlich ganze drei Entwicklerinnen und zwei Entwickler. Franzi und ihr gesamtes Team genießen die Begeisterung und den Wissensdurst, den alle Bootcamp-Abgänger gleichermaßen in die Firma einbringen (und den man bei Marie hört). Gleichzeitig ist aber auch klar, dass so ein Bootcamp nur der Anfang ist und so unterstützt und begleitet ihr Team die Neueinsteiger:innen, so dass sie sich bestmöglich in der Praxis einfinden (oder auch in Vue anstelle des im Bootcamp behandelten React).
Uns hat das Befragen der beiden sehr viel Spaß gemacht und wenn Ihr oder bekannte von Euch ebenfalls über ein Coding Bootcamp nachdenken, dann hört diese Folge und kommt gerne auf Marie oder Franzi mit weiteren Fragen zu. Und wenn Ihr selbst ein solches Bootcamp absolviert habt, dann würde uns interessieren, wie Eure Erfahrung war. Hinterlasst gerne eine Nachricht in unserem Kommentarbereich!
28. April 2020 | Kommentare deaktiviert für Revision 422: Web Worker, ComLink und WASM
Nachdem es schon wieder unglaubliche zwei Jahre her ist, dass wir mit ihm über das „Actor Model“ reden durften, war es nun höchste Eisenbahn, Surma wieder einzuladen und über aktuelle Entwicklungen im (multigethreadedten) Web zu plaudern.
[00:00:29] Schaunotizen
Web Worker
Eines von Surmas Steckenpferden ist es, alles was nicht bei „Drei!“ auf dem Baum ist in separate Threads auszulagern. Wir sprechen über Sinn und Zweck dieser Heranangehensweise am Beispiel der Projekte Squoosh und Proxx des Chrome Developer Relations Teams (siehe auch die Google Chrome Labs auf Github). Wir erfahren, dass das Ziel dabei weniger ist, mehr Geschwindigkeit auf ohnehin schnellen Plattformen herauszuholen, sondern vielmehr dem UI-Thread auf Einsteiger-Hardware den Rücken frei zu halten.
ComLink
Einer der Nachteile von Web Worker ist die Tatsache, dass sie anstrengend im Umgang sind. Moderne Programmierparadigmen und Surmas Open-Source-Projekt ComLink schaffen hier allerdings Abhilfe. Und auch wenn das Motto „Comlink makes WebWorkers enjoyable“ lautet, so lässt sich diese Bibliothek auch ganz prima für eine angenehme Kommunikation mit Service Workern oder über Frame-Grenzen hinweg einsetzen (also im Prinzip alles, was auf das Message-Interface setzt).
Wasm, WASI und Interface Types
Surma kennt sich aber nicht nur mit elegant programmierbarem Multithreading aus, sondern auch mit WebAssembly, kurz: Wasm. So nutzt unter anderem das eingangs erwähnte Squoosh unter der Haube von C++ nach Wasm portierte, gebräuchliche Bildkompressoren wie MozJPEG oder OptiPNG. Wir unterhielten uns außerdem über kommende Neuerungen wie Interface Types, sowie nochmal über WASI (höre dazu auch Revision 394). Und wir sinnierten über den Grund, weswegen es so aussieht, als ob Wasm schaffen wird, was Java und Silverlight nicht gelungen ist, nämlich das langersehnte, universelle Runtime-Environment zu werden.
If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let’s hope WASI is up to the task! https://t.co/wnXQg4kwa4
Dieses andere Projekt von Surma in Zusammenarbeit mit Jason Miller ermöglicht es, analog zu ES Modulen, Funktionen aus Web Workern transparent in den UI-Thread „zu importieren“ und sie dort wie gewohnt zu nutzen.
Nachdem dank Coronavirus auch die Google Developer Relations Menschen von zu Hause arbeiten müssen, setzen Jake und Surma ihre Serie nun einfach in Form eines Podcasts fort (we approve!).
Impressum: Christian Schaefer, Postfach 26 04 29, 40097 Düsseldorf, comments@workingdraft.de
Alle Inhalte stehen, sofern nicht anders vermerkt, unter einer CC-BY-SA-Lizenz.
