Als Podcast versuchen wir die Qualität der Aufnahmen hoch zu halten. Dafür verwenden wir Equipment und Tools, die nicht kostenlos sind. Und jede Folge kostet Zeit: Aufnehmen, Schneiden und Shownotes schreiben, Gäste und Termine koordinieren.
Mit rund 15.000 Downloads pro Folge im Schnitt haben wir auch Herausforderungen im Hosting zu bewältigen.
Um diese Kosten decken zu können, suchen wir Sponsoren. Wir glauben, dass unser Podcast eine gute Plattform ist, um darüber gleichgesinnte Programmierkollegen als Verstärkung für Euer Team zu finden. Wenn Ihr das auch so seht, dann sprecht doch mal mit Euren Chefs.
Bei Interesse, kontaktiert uns per E-Mail: sponsoring@workingdraft.de.
Hans und Peter fragten Rodney zu React Native aus!
Schaunotizen
[00:00:50] React Native und Expo
React Native ist ein (ehemaliges) FB-Projekt um mit JavaScript UIs für Android und iOS zu bauen. Es bildet eine Abstraktion über die UI-Komponenten, trotzdem gibt es Unterschiede zwischen iOS- und Android-UI-Widgets, mit denen man sich auseinandersetzen muss. Rodney vergleicht daher React Native mit jQuery oder Raphael. Für mehr Spaß am Gerät setzt Rodney (nachdem sich NativeBase nicht bewährte) Expo ein, „das Developer-Experience-Paket für React Native“. Trotz aller Tools bleibt React Native aber knifflig. Für Vektorgrafiken gibt es gar keine befriedigende Lösung und Testing (mit Jest und Enzyme) ist zwar machbar, aber nicht trivial. Im Vergleich zwischen Native, Web und react-native-web gibt es keinen klaren Gewinner. Gerade wenn nicht nur unterschiedliche Betriebssysteme, sondern ganz unterschiedliche Geräteklassen zum Einsatz kommen (Hallo React Native für Windows) wird es wohl nie möglich sein, ein UI zu bauen um sie alle zu knechten.
Der Resize Observer lässt Nutzer auf Größenänderungen eines Elements reagieren. Mit dem Resize Observer lassen sich die vielgenannten Container Queries in JavaScript abbilden. Wie das alles genau funktioniert erklärt Schepp. Wir sprechen über Anwendungsbeispiele und erwähnen einige Tools, die hilfreich sein können.
Hier die Links dazu:
Nach Revision 382 meldet sich Stefan Tilkov zu Wort um ein paar andere Ansichten zum Thema Web-Architekturen zu liefern.
Schaunotizen
[00:02:20] Webarchitekturen
Groß ausschweifend sprechen wir über REST und was es denn eigentlich ist, die URL als Pfeiler guter Web-Architekturen, und die Geissel der modernen Web-Anwendungen: Die Single Page Applications. Es treffen traditionelle Architekturen und Ansichten auf moderne Frameworks, und wir versuchen einen Konsens zwischen dem was war, dem was ist, und dem was sein könnte zu treffen. Themen die wir dabei besprechen: SPA vs ROCA, HTML und HatEoAS, GraphQL, Web Components und natürlich viel Kultur, Organisation und allerlei. Viel Spaß!
12. Mai 2019 | Kommentare deaktiviert für Revision 385: React Hooks
Schepp, Hans und Stefan in einer flotten Diskussion über ein neues React Feature, das die klassische klassenbasierte Komponenten-Bibliothek ein wenig auf den Kopf stellt.
React kündigte im November 2018 mit Hooks ein neuartiges, beinah revolutionär wirkendes Konzept zur funktionalen Komponenten-Entwicklung an. State-Management ohne Schmerzen. Wir sind interessiert! Wir sehen uns an, was nun wirklich dahintersteckt, wie es mit Custom Hooks aussieht, und machen den Praxis-Test. Das ganze funktioniert natürlich auch mit TypeScript! Stefan entschuldigt sich auch gleich mal für die vielen Male, wo das Lag die anderen Leute nicht ausreden hat lassen und erwähnt nicht, dass Hans ihn anschließend als Professor bezeichnet hat.
8. Mai 2019 | Kommentare deaktiviert für Revision 384: Micro-Frontends
Komplexe Web-Applikationen und -Seiten werden oft in unterschiedliche Domänen geteilt. Frontend wird klassisch als eine eigene Domäne angesehen. Doch was passiert, wenn man den Micro-Service-Gedanken auch ins Frontend überträgt und die Zuständigkeiten des Frontend-Codes auch an die korrekten Business-Domänen anpasst? Das klären wir gemeinsam mit Mark Lubkowitz der uns einen Einblick in seine Erfahrungen mit Micro-Frontends gibt.
Nach einer Einführung in das Thema und das Beleuchten der Vor- und Nachteile von Micro-Frontends, beschäftigen wir uns mit den Erfahrungen auf dem Gebiet. Neben Mark, spricht auch Hans über seine Arbeit bei einem großen Online-Shop, bei dem der Gedanke der Micro-Frontends verfolgt wurde.
Tim Schumacher, seines Zeichens Backend-Entwickler in Jena und großer TypeScript-Fan, fand sich mit Hans und Peter zusammen, um genüsslich eine Runde über TypeScript allgemein und TS im Backend im Speziellen zu plauschen.
Schaunotizen
[00:02:18] TypeScript im Backend
Es hat sich viel getan, seitdem wir TypeScript zuerst in Working Draft erwähnten (damals ganz am Rande der Revision 90)! Neben den altbekannten Typ-Annotationen und Generics gibt es mittlerweile auch auf Decorators basierende Späße wie den Class Validator und vor allem Tools wie ts-node. Die mit ts-node einhergehenden Performacenachteile könnten in deno (Node mit nativem TypeScript-Support) nicht mehr ins Gewicht fallen und wenn alls Stricke reißen ist auch das gute alte nodemon noch da und unterstützt ebenfalls TypeScript. Weitere Tools im Alltagseinsatz sind noch immer TSLint (demnächst dank ESLint überflüsig) in Kombination mit Husky und der typescript-formatter. An Backend-Libraries kommen neben TypeORM und Sequelize der praktische class-transformer und routing-controllers für Express und Koa.
Die Revision 382 beschäftigt sich mit modernen Austauschformaten zwischen Software System. Wir sprechen mit Dr. Ralf Engelschall zu den Themen REST und GraphQL und lassen uns über die Vor- und Nachteile aufklären.
Schaunotizen
[00:03:52] REST
REST ist als Programmierparadigma stark verbreitet. Viele Schnittstellen folgen dem Standard, der sich in den vergangenen Jahren stark verbreitet hat. REST bietet einige Vorteile, die Ralf mit uns durch geht. Wir sprechen aber auch darüber, dass Themen wie Stateless oder das Caching mit REST zum Problem werden können.
[00:23:18] GraphQL
Eine mögliche Lösung für diese Probleme ist das bereits in einigen Revisionen, zuletzt Revision 292 angesprochene GraphQL, eine graph-artige Anfragestruktur für Daten. Ralf gibt uns einen Einstieg in GraphQL, wie es technisch funktioniert und was das spannende an GraphQL ist. Anhand eines Beispiels aus seiner täglichen Arbeit lassen sich die Vor- und Nachteile gut erkennen.
Nacktes GraphQL ist manchmal zu wenig für Anwendungen aus Frontend und Backend. Um die beiden Teile zusammen zu bringen, hat Ralf eine All-in-One Lösung gebaut, mit der die Implementierung von GraphQL für Entwickler wesentlich vereinfacht wird.
24. März 2019 | Kommentare deaktiviert für Revision 381: Layered APIs und der Stand der Dinge bei HTTP/2
In kleiner und gemütlicher Runde besprachen Stefan und Schepp, was es mit dem Konzept der Layered APIs auf sich hat und wie es derzeit so um HTTP/2 steht.
Bei den Layered APIs handelt es sich um sowas wie eine im Browser mitgelieferte Standard-Bibliothek, welche neuen syntaktischen API-Zucker bereitstellt, ohne dazu auf neue API-Primitive zurückgreifen zu müssen. Die Idee dabei ist, den Entwicklern an den Standardgremien vorbei schneller bessere Werkzeuge zu liefern, die Sie zudem auch nur bei Bedarf hochfahren/laden können. Das hält die Browser schlanker. Da die neue APIs rein per JavaScript geschrieben sind und auf längst bestehenden APIs aufsetzen, können Browser, die diese Layered APIs nicht eingebaut mitbringen, diese Bibliotheken einfach aus dem Netz nachladen. Analog zu einem Polyfill. Dafür gibt es eine spezielle, neue und rückwärtskompatible Modul-Syntax. Der erste Kandidat für eine Layered API ist der KV Storage, den man jetzt per Origin Trial Verfahren auf seine Besucher loslassen kann.
Unser zweites Thema befasste sich nach längerer Zeit mal wieder mit HTTP/2. Anlass war der oben verlinkte Artikel, in dem getestet wurde, inwiefern veränderte Bundling-Strategien zu besserer Performance führen, und wo Dinge sich ins Negative verkehren. Das ist insofern relevant, als dass mittlerweile gut 50% aller Webseiten mit dem Prototoll ausgeliefert werden. Wir fanden außerdem beiläufig heraus, dass rund 75% aller Webseiten auf HTTPS laufen.
swc, der „speedy web compiler“, ist ein in Rust geschriebener, besonders schneller JavaScript-Transpiler, der laut eigener Aussage Feature-technisch mit Babel gleichauf liegt.
sucrase ist ein Babel-Fork und verfolgt ähnliche Ziele. Diese werden in diesem Fall dadurch erreicht, dass verlangsamende, aber auch kaum benötigte Features aus Babel wegfallen. Darunter das Rückkompilieren zu älteren ES-Versionen. Dadurch wird sucrase also eher zu einem Metasprache-nach-Current-ES-Compiler.
Der Feature Policy Playground möchte eine Art „Can I Use“ für Feature Policy Features sein. Es geht zum einen um den aktuellen Browser-Support, als auch darum, auf die entsprechenden Explainer-Dokumente zu verlinken.
20. März 2019 | Kommentare deaktiviert für Revision 380: Chrome-Devtools-Extension-Entwicklung
Eine Rarität! Das komplette Podcast-Kernteam vereint in einer Revision. Keine ganz so große Rarität: der Löwenanteil der Sprechzeit entfällt auf Peter, der einen Einblick in die Entwicklung einer Chrome-Devtools-Extension gibt.
Schaunotizen
[00:02:40] Chrome-Devtools-Development
Für Warhol, ein Joint Venture von Peter und Hans, entsteht eine Browser-Extension, von deren Entwicklung Peter lang und breit berichtet. Zu den Herausforderungen zählt die Verteilung der einzelnen Extension-Bauteile über viele verschiedene Browsing Contexts, die Verwendung von TypeScript (@types/chrome hilft) und die nicht besonders strukturierte API-Dokumentation (für Extensions allgemein und für Devtools im Besonderen), in deren Angesicht Stack Overflow Gold wert ist.
17. März 2019 | Kommentare deaktiviert für Revision 379: Requirements Engineering, Agilität und Wasserfälle
Für diese Revision holten sich Schepp, Peter und Rodney Unterstützung von Yara Meyer (Principal Consultant bei , auf Twitter @whythecode) in Studio, um die Untiefen der Projektplanung zu erforschen.
Schaunotizen
[00:01:28] Requirements Engineering, Agilität und Wasserfälle
Yara hat im Rahmen ihres Schaffens als Consultant schon so manches mehr oder weniger erfolgreiches Projekt begleitet und quatscht mit uns über Requirements Engineering, Agilität und alles, was in der Softwareentwicklung so schief läuft. Als ein großes Problem ist die Planung von Software durch Nicht-Software-Firmen zu nennen, die sich besser Requirements Engineering von einem extern Dienstleister eingekauft hätten. Das ist aber gar nicht mal so leicht zu verkaufen. Agilität (vor allem innerhalb von Legacy-Strukturen und großen Konzernen), Deadlines, Features und Milestones sind genau so Thema wie Berichte über ein paar Worst Cases vom Planeten Wasserfall.
