Einmal alles andersherum! Diesmal führt unser Gast Ole Michaelis, Software-Entwickler, Konferenzsprecher, Organisator und Jonglierer, ein Interview mit unseren Hosts Hans und Vanessa zum Thema „wie schafft man sich eigentlich neues Wissen drauf“?
Schaunotizen
- [00:00:59] Lernen, Weiterbildung und Wissenserweiterung
- Ole erzählt uns zu Beginn, dass er mittlerweile lange genug im Bereich der (Web-)Entwicklungen arbeitet, um bei neuen Frameworks und Bibliotheken das Gefühl zu bekommen: das gab’s doch fast genauso vorher schonmal! Im Anschluss wird diskutiert, wie man eigentlich Trends und Hypes erkennt, und von Konzepten unterscheidet, die sich im Endeffekt durchsetzen werden oder durchgesetzt haben.
Auf dieser Grundlage, erörtern sie, we man sich dafür entscheidet, was man sich tatsächlich genauer ansieht und lernt. Für Ole war es zum Beispiel Haskell, worauf sich Vanessa hin an ihre schöne Standard ML (SML) Zeit in der Universität erinnert. Weiterhin werden verschiedene Medien zum Lernen besprochen, wie zum Beispiel Videos auf YouTube, Newsletter (Links siehe unten), Kursplattformen, etc.
Die nächste Frage, wenn man schon einmal angefangen hat zu lernen, ist die, wann man wieder aufhört. Ab welchem Zeitpunkt entscheidet man sich dafür, dass man genug über dieses Thema weiß?
Abschließend, ein sehr wichtiger Aspekt, geben Ole, Hans und Vanessa ihre Meinung zum Thema „Lernen während der Arbeitszeit“ bzw. „Lernen finanziert durch die Firma“ ab. Alle sind sehr interessiert an der Meinung der Hörerrinnen und Hörer!
Links
- Tools
- Programmierspiele und Co.
- Newsletter
Hans, Stefan und Vanessa hatten nach langer Zeit wieder das Vergnügen mit Backend-Entwickler Christoph Rumpel (@christophrumpel), Autor von Laravel Core Adventures und Mastering PhpStorm, ein Larastreamer und Host des Podcasts Call it a day, sprechen zu dürfen, diesmal über Laravel Livewire.
Schaunotizen
- [00:00:59] Laravel Livewire
- Laravel Livewire ist ein PHP/Laravel Package von Caleb Poruio, der ebenfalls der Autor von Alpine.js ist. Dieses Package eignet sich v.a. für Fullstack oder stark backend-lastige Developer Teams. Es ermöglichst dynamische Interface Funktionen, ohne tatsächliches JavaScript geschrieben werden muss. Die Grunfunktion basiert auf server-side gerendertem HTML Partials, ähnlich wir PJAX von jQuery. Doch alle Frontend Entwickler:innen wissen: Heutzutage bleibt es selten bei „einfach nur JavaScript“. Bei einem Framework wie Laravel Livewire fällt auch der Aufbau und die Wartung von Bundlern und ähnlichem Tooling weg. Die Idee kommt vom Framework Phoenix von Elixir. Ein ähnliches Framework für C#, um client-side Webapplikationen zu bauen, ist Blazor. Vergleichbar in der Welt von Ruby on Rails ist Hotwire. Als Beispiel nimmt Christoph uns mit in eine server-side geladene Applikation mit den üblichen Page Reloads. Nun landet man auf einer Seite mit einer Tabelle, für die es sich anbieten würde, wenn man diese Daten nun auch sortieren oder filtern könnte – und statt einem Page Reload lieber einen kurzen Loading Spinner anzeigen möchte. Darüberhinaus eignet es sich für Echtzeit-Validierung, Auto-Saving, Suchen, Auto-completes, dynamischen Dropdowns, Datei Uploads und vielem mehr. Auch das Schreiben von Tests mit mit Livewire kein Problem. Es hat sogar noch den Vorteil, dass dadurch, dass die Logik nicht in ein JavaScript Framework ausgelagert wurde, es keine zusätzlichen Integrations- oder Ende-zu-Ende-Test zwischen Frontend und Backend benötigt. Christoph bringt uns zwei Beispiele mit (siehe Links). Abschließend gibt es noch zu beachten, dass Entwickler:innen auf die Performance achten müssen, da ja jede Aktion einen Request erzeugen wird. Anm. der Redaktion: Performance ist aber auch mit einer Single-Page Applikation o.ä. auch nicht einfach, v.a. wenn erst einmal ein 4k Video geladen wird. Darüberhinaus gilt es auch den Überblick über sensitive Daten zu behalten, da durch Livewire eine offene Schnittstelle zum Client entsteht.
Links
- ChannelTest1 + ChannelTest2
- Zwei Livewire Tests von Christoph Rumpel.
- Livewire Deep Dive
- How Livewire works (a deep dive) von Autor Caleb Porzio
- Inertia.js
- Das Pendant zu Livewire – eine server-side Webapplikation
- Larastreamers GitHub Repository
- Die Codebase von Larastreamers
- TALL Stack
- Tailwind, Alpine.js, Laravel und Livewire
- TEA Stack
- Tailwind, Eleventy und Alpine.js
Verwandte Revisionen
- Revision 490
- Verwandte Revision über Alpine.js and Petite Vue.
-
- Revision 127
- Historische Revision über das INIT Boilerplatz und das Laravel PHP-Framework mit Christoph Rumpel aus 2013.
- Revision 283
- Vue.js und Chatbots mit Christoph Rumpel aus 2016.
Was gibt es eigentlich Neues bei Webpack 5? Das erzählt uns Tobias Koppers (@wSokra), der Gründer von Webpack, und gibt uns Einblicke in seine Zukunftspläne.
Schaunotizen
- [00:00:59] Der aktueller Status von Webpack
- In Revision 289: Tiefe Einblicke in die Webpack Entwicklung aus dem Jahr 2017 sprachen wir bereits mit Tobias über Webpack. Gestartet als ein sog. Module Bundler. Damals sprachen wir über Updates bzgl. Version 2. Seitdem hat sich einiges getan. Heutzutage bezeichnet Tobias Webpack als „Frontend Web App Optimizer“. Er vergleicht den heutigen Stand von Webpack mit ähnlichen Tools, den „Bundlern“ Rollup und Parcel und den „No-Bundlern“ Snowpack und Vite.
- Im Anschluss besprechen Hans, Vanessa und Tobias die Neuerungen von Webpack 5, wie Persistent und Long Term Caching, Module Federation, HMR Verbesserungen, TypeScript Typings, WebAssembly Support, und noch viele mehr.
- Ein endloser Support für Webpack 4 ist nicht geplant. Um nun all diese neuen Features nutzen zu können, heißt es also: migrieren! Wie Tobias im Podcast erzählt, ist die Anzahl der „Breaking Changes“ gering. Dank des Migration Guides sollte dies kein Problem sein.
Diesmal geht es wieder rein in die moderne Welt der Frontend Entwicklung. Mit Jon Uhlmann, Neos-Core Team Members, sprechen Hans und Vanessa über alpine.js und Petite Vue.
Schaunotizen
- [00:00:59] AlpineJS & Petite Vue
- AlpineJS und Petite Vue sind beides ähnliche, sehr leichtgewichtige Frontend Frameworks. Um eine Vorstellung davon zu bekommen, bezeichnet Jon sie als das jQuery des modernern Webs oder TailwindCSS des JavaScripts. Mögliche Use Cases sind Formvalidierung, Modals, Nachladen von Content, MixItUp Filters und mehr. Die Frameworks benötigen keinen virtuellen DOM. Dadurch sind die Pakete der Frameworks vergleichsweise klein. Petite Vue kommt mit 5kB. Dennoch steht Entwickler:innen die komplette Reaktivität auf Basis von Vue.js zur Verfügung, was den Kern beider Frameworks bildet. Auch globales State Management kann z.B. mit $store betrieben werden. Wie so oft sind beide der Frameworks trotz ihrer geringen Größe daher auch für größere Projekte geeignet. Neben der kleinen Größe des Builds, was vor allem Vorteile für die User Experience bringt, nennt Jon die schnelle Lernkurve und das damit verbundene schnell erreichte Ziel auf Seiten der Developer Experience als Pluspunkt. Außerdem untersützen die Frameworks Entwickler:innen beim Thema Barrierefreiheit. Als einzigen Nachteil sieht er das fehlende Tree-Shaking. Unterscheiden kann man AlpineJS und Petite Vue aktuell quasi nur in der Größe der vorhandenen Features. Petite Vue ist 3 Jahre jünger als AlpineJS. Dadurch fehlen hier (noch) Features wie Transitions. Aber natürlich sind wir hier guter Dinge! Weitere gute Nachrichten sind, dass Testing wie gewohnt zum Beispiel mit Jest und Cypress, durchgeführt werden kann. Wir wünschen viel Spaß beim Ausprobieren der beiden verlinkten Codepens!
Links
Verwandte Revisionen
Mit Fabian Friedl, DesignOps Team Lead bei Dynatrace, sprechen Vanessa, Hans und Stefan über Komponentenbibliotheken und Design Systeme.
Schaunotizen
- [00:00:00] Komponentenbibliotheken und Design Systeme
- Bevor ins Detail eingestiegen wird, erklärt Fabian erst einmal was eine Komponentenbibliothek überhaupt ist. Ein Hauptziel von Komponentenbibliotheken ist es, Konsistenz zwischen mehreren Applikation herzustellen. Darüberhinaus können sie allerdings auch Mehraufwand deutlich minimieren. So muss beispielsweise bei einem Redesign oder bei einer Erweiterung nicht jedes Featureteam die Änderung umsetzen. Stattdessen kommen Änderungen vom Team der Komponentenbibliothek. Die Basis von Komponentenbibliotheken sind Design Systeme. Als i-Tüpfelchen können Designer:innen und Entwickler:innen Design Tokens verwenden. Design Tokens geben atomic Styles an, die für verschiedene Plattformen, wie iOS, Android oder als Custom Properties für Web, exportiert werden können. Selbstverständlich kann es auch Nachteile geben. Doch diese lassen sich durch Organisation umgehen. Fabians Team arbeitet eng mit dem Designteam zusammen, eigentlich sind sie eher ein Team. Es gibt wöchentliche Designreviews, die für einen frühen Austausch sorgen. Eine wichtige Frage, die sich dann beim Entwickeln stellt ist: Wer ist der Konsument? Ist es ein komplettes Open Source Projekt, wie viele Feature Teams greifen auf die Bibliothek zu? Unabhängig davon, jeder Konsument der Bibliothek wird eine gute Dokumentation benötigen. Noch besser sind sogar Copy & Paste Snippets zum Ausprobieren. Je besser die Dokumentation ist, desto mehr erspart man sich Nachrichten über Chatsysteme mit immer den gleiche Fragen. Weiteres Material in den Links
Links
- Angular CDK
- Stilfreier Grundbaukasten für barrierefreie Angular Komponenten
- Calender Kit
- Schon mal ein Kalender-Widget gebaut? Hier gibt’s kopflose Unterstützung.
- React-aria
- React Hooks von Adobe zur Erstellung barrierefreier Komponenten. Sehr qualitativ!
- Headless UI
- Headless Components von den Tailwind Machern in React und Vue
- Reach
- Stilfreie, barrierefreie React Komponenten
- Polaris
- Das Shopify Design System
- Barista
- Das Dynatrace Design System
- Learnings from building a component Library
- Fabians Vortrag auf der NG-DE
Im September 2020 war das Release von Vue 3. Ein gutes halbes Jahr später besprechen wir mit Markus Oberlehner über Erfahrungen über die Einsatz der Änderungen in echten Projekten.
Schaunotizen
- [00:00:59] Vue 3 und die Composition API
- Über keine eine andere Änderung bei Vue 3 wird so viel gesprochen wie die Composition API. Denn, wenn man das so möchte, hat sie den größten Effekt auf die Programmierweise von Frontend Applikation mit Vue.js. Zudem gibt es Performance Boosts, das Entfernen des notwendig Root-Elements jeder Single File Component und die Möglichkeit mehrere v-models an Kind Komponenten zu binden. Die sind zwar alle super, aber deswegen haben Hans, Schepp, Vanessa und Markus auch nicht viel dazu gesagt. Vergleichbar ist die umumstrittene Composition API mit React Hooks, von denen sie wohl auch inspiriert war, wie Evan You, der Erfinder von Vue.js, in einem Tweet von 2018 durchblicken lässt. Markus und Vanessa sind sich einig, dass die Composition API eine tolle Sache ist, aber die Best Practices noch fehlen. Glücklicherweise sorgt Markus auf seinem Blog mit vielen hilfreichen Artikeln. Er berichtet über das Group, Extract, Share Konzept, den Einsatzgebieten von watch und watchEffect und Möglichkeiten im State Management, auch ganz ohne Vuex. Markus erzählt ebenfalls von swrv, einem state-while-revalidate Plugin. Außerdem gibt es ein Open Source Projekt über Lazy Hydration auf Github. Zum Abschluss besprechen sie den Support von TypeScript und IDE Extensions wie Vetur, Vue DX und Volar. Wer Vue 3 jetzt mal ausprobieren möchte, kann sich auf dem SFC Playground austoben.
Keine Schaunotizen
- markus.oberlehner.net/blog
- Der Blog von Markus.
- Revision 365
- Vue.js – Eine Einleitung
- Revision 367
- Vue.js – Der Deep Dive
Vanessa, Schepp und Stefan reden heute mit Mathias Schäfer (@molily) über Testing mit Angular.
Schaunotizen
- [00:00:29] Testing Angular
- Nachdem Mathias im Jahr 2017 sein Werk „Robust Clientside JavaScript“ veröffentlich hat, ist das nun erschienene „Testing Angular“ so etwas wie dessen Fortführung. Angular musste in dem Fall als Framework herhalten, allerdings können Mathias Empfehlungen aus dem Buch auf alle anderen Frameworks übertragen werden. Angular hat den Vorteil, dass es zu Beginn etwas mehr Tooling mitliefert als etwa React. Das Problem ist aber, dass man anschließend ohne Unterstützung bei der Test-Methodik allein gelassen wird. Diese Lücke wollte Mathias schließen. Dabei ist Mathias ohne vorgefertigte Meinung gestartet. Stattdessen ging es ihm darum, Testing zu durchdenken und zu einer eigenen Position zu kommen, die dann begründet wird. Das Buch erklärt, was sinnvolle Tests sind. Für Mathias sind es diejenigen Tests, die Komponenten als Ganzes testen, also inklusive dem DOM und nicht nur die dahinterstehende (Klassen-)Logik. Letzteres nennt man „White-Box-Tests“, weil man zum Testen wissen muss, wie das JavaScript aufgebaut ist. Besser sind aber die „Black-Box-Tests“, die das HTML abtesten und denen völlig egal ist, was hinter den Kulissen an Abläufen notwendig ist. Diese Art von Tests nehmen zudem stärker die Nutzerperspektive ein und sie gehen bei späteren Refactorings weniger oft kaputt, was weniger Wartungsaufwände an den Tests zur Folge hat. Mathias reiht sich damit hinter Vordenker wie Kent C. Dodds ein. Was Mathias als mitgeliefertes Werkzeug nicht überzeugt hat, ist Protractor, und zwar vorwiegend weil es WebDriver-basiert ist und weil es ein paar seiner ehemaligen Verzahnungen mit Angular verloren hat. Stattdessen bevorzugt er Cypress, das wir vor nicht allzu langer Zeit hier im Podcast zum Thema hatten. Folgende Links spielen im Laufe unseres Gesprächs eine Rolle:
Keine Schaunotizen
- expect(Exception)
- Vanessas Podcast über Frontend Testing.
- flowchart.fun
- Eine Web-App, in der man Flußdiagramme mit Hilfe von speziellem Markup schreibt/zeichnet
In dieser Revision durften wir wieder einmal Tim Seckinger, Mitwirkender von Jest und Entwickler bei YLD als Gast begrüßen. In Revision 436 sprachen wir bereits mit ihm generell über Frontend Unit-Testing, dieses Mal konkret über Jest.
Schaunotizen
- [00:00:28] Jest
-
Das Ecosystem Jests besteht aus mehreren Helfer-Tools, wie Airbnb Enzyme. Auch der Jest Runner lässt sich austauschen, von jsdom zu einem Playwright Environment bis hin zu sogar Python Tests. Etwas praxisnäher ist das Tool jest-runner-eslint, das wie andere Tools bei Awesome Jest aufgelistet ist.
Die nahe Zukunft bringt ein Major Release: Jest 27. Veränderungen sind: Inline Snapshots ohne Prettier und Node als Standard-Umgebung (bisher: jsdom). Das, und andere technische Änderungen, sorgt für eine schnelle Ausführung. Bei Jest 28 könnte die Testing Library wohl sogar aus einzelnen Packages bestehen, damit nicht jedes einzelne Feature automatisch installiert werden muss. Eine weitere Idee ist eine Hooks-like Syntax anstelle von Funktionen wie beforeEach/afterEach, wie man in Issue 10453 nachlesen kann.
Tim erzählt uns auch ausführlich, wie man Snapshot Tests am Besten einsetzen kann und was Anti-Patterns sind. Mit seiner Erklärung wird deutlich, wie man mit Jest sog. resilient tests, also robuste und nicht fehleranfällige Tests schreiben kann.
Keine Schaunotizen
- Jest Contributor
- Jest entstand vor bereits über 10 Jahren und wie React.js wurde es intern im Hause von FaceBook entwickelt. Doch mittlerweile wird Jest vor allem von drei Core Contributers, u.a. Tim verwaltet. Wenn du dich berufen fühlst, schau mal auf der GitHub-Seite vorbei. Dort gibts weitere Infos.
- Revision 458: Cypress
- Wer sich nun auch für End-to-End Testing interessiert, kann gerne in Revision 458 reinhören, in der wir mit Priyanka Kore und Tobias Struckmeier von der Adesso über Cypress sprachen.
Developer und Speaker Tobi Timm, Senior Product Engineer bei SinnerSchrader, Koorganisator bei Nodeschool MUX/AUX und React Munich, erzählte Stefan, Schepp und Vanessa über funktionale Programmierung und endliche Zustandsmaschinen in JavaScript.
Schaunotizen
- [00:00:29] Funktionale Programmierung en Vogue
- Durch die immer höhere Popularität von progressiven Frontend-Frameworks wie React.js und Vue.js, die jeweils Ansätze der Funktionalen Programmierung (FP) aufweisen, erlaubt die FP an sich einen Aufschwung in der Web Entwicklung. Neben Elm, ein von Haskell inspiriertes Framework, gibt es für JavaScript-Entwickler und -Entwicklerinnen die Bibliothek Ramda.js. Für ESLint steht das Plugin eslint-plugin-functional zur Verfügung. Das wohl wichtigste Paradigma der Funktionalen Programmierung besteht daraus, das ausschließlich Funktionen geschrieben werden. Die Konzepte kommen von Haskell, LISP, OCaml oder auch Scheme, einem Vorgänger von Javascript. Funktionen gelten als „First Class Citizen“ und werden dabei auch „Pure Functions“ genannt. Diese generieren bei gleichem Input immer den gleichen Output und verwenden keine Variablen außerhalb ihres Scopes. Ein Vorteil von Funktionaler Programmierung ist dadurch, dass Nebenläufigkeiten verhindert werden und der Code weniger fehleranfällig ist. Getestet werden müssen dann Werte von außerhalb, wie z.B. Nutzereingaben oder Antworten von APIs. Für den Einstieg in die FP in einer bestehenden Codebase, empfiehlt Tobi z.B. For-Schleifen durch Funktionen wie .map(), .filter() und .reduce() zu ersetzen. Zum Lernen empfehlen wir die Videos von Dr. Boolean.
- Finite State Machines
- Etwas, das ähnliche Effekte wie die FP erzeugt, sind State Machines und State Charts. XState von David Khourshid ist hier das Framework für pure Javascript Entwicklung. Wie auch bei der FP ist die Lernkurve allerdings etwas höher, doch es scheint sich zu lohnen, sich mit diesem Thema zu befassen.
