Smashing Podcast Folge 32: Rückblick auf das Jahr 2020

In dieser Folge blicken wir auf 2020 zurück. Mit wem haben wir dieses Jahr in unseren Folgen gesprochen und was haben wir gelernt? Hören wir uns einige Clips an, um es herauszufinden.

Notizen anzeigen

Unter podcast.smashingmagazine.com finden Sie alle unsere vergangenen Folgen, einschließlich einer vollständigen Abschrift aller Interviews.

Wir sehen uns 2021, alle zusammen!

Abschrift

Drew McLellan: Im Januar sprach ich mit Amy Hupe über ihre Arbeit am Designsystem der britischen Regierung und insbesondere darüber, wie das Team die Akzeptanz des Systems durch die breitere Organisation durch die Förderung von Beiträgen erhöhte. Hier ist Amy.

Amy Hupe: Wir haben sehr früh angefangen. Lange bevor wir also eine Art öffentliches Designsystem hatten, begannen wir, uns mit Leuten zu beschäftigen, von denen wir dachten, dass sie interessierte Mitwirkende sein würden. Ich sollte hier erwähnen, dass wir einen brillanten Servicedesigner im Team hatten. Sie schloss sich uns an … Ich werde die Daten im Moment in keiner Weise richtig machen, aber ich denke, sie hat das ganze Jahr 2018 mit uns zusammengearbeitet, und ihr Name ist Ignacia. Sie hat einfach einen fantastischen Job gemacht, herumzugehen und Leute zu begeistern. Eines der Dinge, die sie tat, war, all die verschiedenen Muster in der Regierung und all die verschiedenen Arten von Variationen dieser Muster zu identifizieren. Also rausgehen und sagen: „Okay. Es gibt 10 verschiedene Möglichkeiten, um nach einer Adresse in der Regierung zu fragen. Lassen Sie uns sie alle zusammen betrachten und entscheiden, welcher unserer Meinung nach der geeignetste Ansatz ist. Wie können wir diese zu einem konsolidieren?“

Amy Hupe: Sie hat einen großen Workshop geleitet, um zu versuchen, die Leute dazu zu bringen, sich diese anzuschauen und diese Art von Konsolidierung als Team durchzuführen. Ich denke, ihr Ansatz, eine Art Zusammenarbeit aufzubauen, bevor wir tatsächlich etwas für die Öffentlichkeit veröffentlichten, hat definitiv dazu beigetragen, weil es bedeutete, dass die Leute bereits ein solches Bewusstsein dafür hatten und viele Leute bereits auf irgendeine Weise dazu beigetragen hatten oder eine andere, bevor wir sie tatsächlich an die Öffentlichkeit brachten. Wir waren also ein paar Schritte voraus. Ich denke, das war wirklich wichtig und einfach Beharrlichkeit, viel Beharrlichkeit des gesamten Teams, um den Menschen zu helfen, einen Beitrag zu leisten.

Amy Hupe: Ich denke, es gibt eine Idee, dass es ein ziemlich süßer Auftritt ist, wenn Sie Leute dazu bringen, zu einem Designsystem beizutragen, weil Sie einfach Leute dazu bringen können, die ganze Arbeit für Sie zu erledigen, und Sie sitzen einfach da und Sie Machen Sie Ihre kleinen Code-Korrekturen, und jeder gibt Ihnen tatsächlich all die guten Sachen. Aber eigentlich weiß jeder, der an einem Designsystem gearbeitet hat, dass es unglaublich komplex ist. Es ist sehr schwierig, eine zentralisierte Lösung zu erstellen, die für mehrere verschiedene Teams funktioniert.

Amy Hupe: Wirklich, es sei denn, Sie haben an einem Designsystem gearbeitet, es ist nicht vernünftig zu erwarten, dass irgendjemand wirklich versteht, was dazu erforderlich ist. Es gibt also eine Menge Art von Händchenhalten. Es ist eine Menge Arbeit damit verbunden, Mitwirkende zu unterstützen, einen Beitrag zu leisten. Ich glaube, ich habe das schon einmal gesagt, aber ich denke, es dauert wahrscheinlich länger, jemandem zu helfen, zu einem Designsystem beizutragen, als es tun würde, das Ding einfach selbst und das zentralisierte Team zu machen. Aber ich denke, den Wert zu erkennen, den es bringt, und beharrlich in Ihren Bemühungen zu sein, den Menschen ihren Beitrag bewusst zu machen, ihnen dabei zu helfen, ihnen zu helfen, sich irgendwie motiviert zu fühlen, es zu tun, ich denke, ja, diese Beharrlichkeit war wirklich so wichtig unser Erfolg in diesem Bereich.

Drew: Wir wurden von Stephanie Stimac und Aaron Gustafson von Microsoft begleitet, um darüber zu sprechen, dass Edge Chromium als Rendering-Engine einführt. Ich fragte Aaron nach der Wettbewerbslandschaft zwischen Browsern und wo die Verschmelzung mehrerer Browser auf derselben Rendering-Engine diesen gesunden Wettbewerb ausmerzen und daher schlecht für das offene Web sein würde.

Aaron Gustafson: Das ist etwas, womit ich definitiv ein bisschen zu kämpfen habe, da ich schon seit langem ein Experte für Webstandards bin. Ich verstehe die geschäftliche Rechtfertigung dafür. Aus Sicht von Microsoft machte es sehr viel Sinn. Aus Sicht der Frontend-Entwickler ist es schön, sich nicht um eine Reihe verschiedener Engines kümmern zu müssen. Ich meine, im Großen und Ganzen haben diejenigen von uns, die schon lange im Web arbeiten, sicherlich eine Menge Konvergenz in Bezug auf das Rendering gesehen. Wir haben nicht mehr so ​​viele Probleme wie damals, sagen wir einmal in Netscape für sieben Tage, wo wir einfach so etwas hatten … Ich kannte Firmen, die einzigartige Stylesheets für jeden unterschiedlichen Browser erstellten, was einfach unhaltbar war.

Aaron Gustafson: Aber ich denke, was jetzt irgendwie anders ist, ist, dass es damals in den ursprünglichen Browser-Kriegen all diese proprietären Engines gab und jeder in einem Spiel der Überlegenheit war, wenn es darum ging, neue Plattformfunktionen auszuliefern und neue JavaScript-Features oder im Fall von Microsoft Reverse Engineering JavaScript, um JScript zu erstellen und herauszufinden, wie man alles zusammenfügt.

Aaron Gustafson: Aber jetzt haben wir die Möglichkeit, tatsächlich in Open-Source-Projekten zusammenzuarbeiten und immer noch den Dialog zu führen und trotzdem … ich weiß nicht. Kämpfen ist nicht das richtige Wort, aber ernsthafte Diskussionen über die Auswirkungen verschiedener Ansätze zu führen und sich gegenseitig zu widersprechen und wirklich daran zu arbeiten, Spezifikationen wirklich gut zu machen, und auch konkurrierende Ansätze für den zugrunde liegenden Code im Kontext von, sagen wir, Chromium zu haben project oder WebKit oder so etwas oder Missoula im Firefox-Bereich.

Aaron Gustafson: Also ja. Einerseits haben wir eine weitere Rendering-Engine verloren, und ich fühlte den gleichen Schmerz, als sich Opera für Chromium entschied. Aber ich fühle mich etwas ermutigt, bei Microsoft zu sein und zu sehen, wie engagiert wir uns dafür einsetzen, tatsächlich auf sinnvolle Weise am Chromium-Projekt teilzunehmen und uns nicht nur zurückzulehnen und einfach alles zu akzeptieren, was Chromium nachgelagert kommt, sondern tatsächlich zu prüfen, was passiert die Plattform und die Teilnahme daran … Ja.

Aaron Gustafson: Das ermutigt mich ein bisschen und ich habe das Gefühl, dass wir nicht nur da sind, um von diesem Projekt zu nehmen und einfach alles zu akzeptieren, was von all den verschiedenen Leuten weitergegeben wird, die an diesem Projekt beteiligt sind, sondern um tatsächlich auch dort mitarbeiten.

Drew: Im Februar habe ich mit Stephanie Walter darüber gesprochen, mit UI-Frameworks wie Bootstrap und Co. zu arbeiten und dies mit den individuellen Anforderungen einer nutzbaren Benutzeroberfläche in Einklang zu bringen. Ich habe Stephanie gefragt, ob es möglich sei, eine äußerst benutzerfreundliche Benutzeroberfläche zu erstellen, während man ein Standard-Framework verwendet, oder ob es immer ein etwas umständlicher Kompromiss sein würde.

Stefanie Walter: Ja. Ich halte es für. Aber es hängt auch von der Kompromissbereitschaft ab, zu der Sie bereit sind, und dies bedeutet Kompromisse auf beiden Seiten. Im Moment kompromittiere ich zum Beispiel viele Schaltflächen, weil Sie einige wirklich spezifische Schaltflächen in einer materiellen Benutzeroberfläche haben. Ich mag den Welleneffekt auf dem Knopf nicht wirklich. Ich denke, es funktioniert auf Mobilgeräten hervorragend, da Sie auf Mobilgeräten eine Art großes Feedback benötigen, wenn der Benutzer auf die Schaltfläche klickt oder sie berührt. Aber dann treten sie diese Art von Welleneffekt auf, der bis zum Knopf reicht. Es ist ein bisschen übertrieben, besonders wenn es viele Knöpfe gibt. Aber wir werden diesen Welleneffekt trotzdem beibehalten, weil es sehr komplex wäre, ihn zu entfernen, weil er in das React-Framework eingebaut war, und um einen weiteren Hover-Effekt auf dieser Schaltfläche zu haben, etwas Subtileres, das nicht so buschig wäre Hier. Es wäre superkomplex. Das ist also die Art von Kompromissen, die Sie eingehen.

Drew: Ethisches Design war das Thema meines Gesprächs mit Trina Felber und Martin Michael Fredrickson. Ich fragte, ob eine ethische Herangehensweise an das Design und die Vermeidung dunkler Muster ein Fall sei, um langfristig über die Gesundheit und das Wachstum eines Unternehmens nachzudenken und nicht nur über kurzfristige Verkaufsziele. Hier ist Martin.

Martin Michael Fredrickson: Das ist vollkommen richtig. Ich denke, Sie müssen das Geschäft, das Sie online machen, so betrachten, als hätten Sie ein Geschäft an der Hauptstraße einer mittelgroßen Stadt, in dem Sie Ihren Ruf intakt halten müssen. Wenn Sie Ihre Kunden nicht gut behandeln, dann werden Sie, wenn Sie Ihre Kunden nicht gut behandeln, langfristig das Geschäft verlieren, weil die Leute zu einem anderen Geschäft gehen oder online kaufen. Was auch immer Sie also online tun, Sie müssen wirklich daran denken, dass es einen langfristigen Effekt gibt, und auch, dass es versteckte Kosten gibt, Dinge zu tun, die komplex oder manipulierend sind. Wenn Sie, wie Trina sagt, aufräumen, sparen Sie langfristig, und das wird nie berechnet, wenn Sie über das Geschäftsmodell sprechen. Sie sprechen immer davon, wie viel Geld Sie verdienen können. Sie sprechen nie über die Kosten, um so viel Geld zu verdienen.

Drew: Im März sprach ich mit Eduardo Boucas über ein Open-Source-Tool namens Sourcebit, das Inhalte aus unterschiedlichen Quellen sammelt und sie Ihrem Static-Site-Generator zur Verfügung stellt. Ich fragte Eduardo, ob dies die Benutzererfahrung bei der Autorisierung für eine SSG verbessern könnte, indem die Integration mit Tools wie Headless CMS ermöglicht wird.

Eduardo Boucas: Genau. Ja. So wie es könnte … Ich sehe zwei verschiedene Möglichkeiten, das Tool zu verwenden, die Entwicklern helfen können. Einer macht Sourcebit zu einem Teil Ihrer Bereitstellungsroutine. Wenn Sie also beispielsweise eine Hosting-Plattform wie Netlify verwenden und Ihre Deploy-Befehle so konfigurieren, dass sie, ich weiß nicht, Hugo-Build sind, oder so, der Build-Befehl für Hugo oder so, die Art von Befehl das generiert die statischen Dateien für Hugo. Sie hätten auch einen anderen Befehl als Teil dieser Routine. Das wäre so etwas wie Sourcebit fetch. Zur Build-Zeit wird Sourcebit also alle anderen Daten abrufen, alle Dateien generieren, die Hugo benötigt, und dann wird die gesamte Bereitstellung diese Dateien bereits verwenden und den gesamten Inhalt bereitstellen, der vom CMS kommt.

Eduardo Boucas: Das ist also ein möglicher Anwendungsfall für Sourcebit. Die andere besteht darin, Sourcebit als lokale Entwicklung im lokalen Entwicklungsworkflow zu verwenden. So können Sie Sourcebit mit etwas ausführen, das wir den Überwachungsmodus nennen. Sourcebit sucht also ständig nach Änderungen in der entfernten Datenquelle, also in diesem Fall im Headless CMS. Wann immer Sie also einen Artikel veröffentlichen oder einen Eintrag im CMS ändern, wird Sourcebit dies bestätigen und alle Dateien lokal für Sie neu generieren.

Eduardo Boucas: Für lokal arbeitende Entwickler bedeutet das also, dass Sie Ihr CMS-Fenster neben Ihrer Hugo-Site lokal ausführen lassen können und dann Änderungen in Echtzeit sehen können. Sie ändern etwas am CMS und können dann sehen, dass sich diese Änderung auf der lokalen Website widerspiegelt, was ich sehr nützlich finde. Das sind also die zwei Möglichkeiten, wie Sie Sourcebit verwenden können.

Drew: Conversion-Optimierung war das Thema des Tages. Als ich mit dem erfahrenen Podcaster und Berater Paul Boag sprach. Wir haben über einige der Techniken gesprochen, die Websites verwenden, um Besucher in Kunden umzuwandeln. Aber ich wollte Paul fragen, wie Sie die Auswirkungen der von Ihnen vorgenommenen Änderungen messen. Paulus erklärte.

Paul Boag: Ja. Absolut. Ich denke, noch einmal, viele Organisationen sind ziemlich schlecht darin, sich darüber im Klaren zu sein, wie sie den Erfolg messen werden. Nun, ja, Ihre Konversionsrate ist eine Metrik. Du solltest unbedingt folgen. Aber selbst bei der Konvertierung müssen Sie ein bisschen raffinierter sein, als viele Leute kaufen. Sie müssen auch auf den durchschnittlichen Bestellwert achten. Sie müssen besonders auf den Lebenszeitwert achten, oder? Also, wie viel ein Kunde über sein gesamtes Leben wert ist, denn Sie werden vielleicht feststellen, dass Sie eine ziemlich hohe Kundenabwanderung bekommen, wenn Sie dunkle Muster und ähnliches verwenden. Aber eigentlich sollte die Konversion nur eine der Metriken sein, die Sie messen.

Paul Boag: Es gibt auch Dinge wie, dass Sie auf das Engagement achten müssen, wie engagiert die Leute mit Ihren Inhalten sind, denn das macht einen großen Unterschied darin, ob sie schließlich konvertieren. Sie sehen sich also Dinge an wie: Wie viel kosten Ihre Videos, werden sie angesehen, wie lange verbringen sie auf Ihrer Website und was sehen sie sich dabei an? Beteiligen sie sich an sozialen Medien und solchen Dingen? Dann ist der letzte Aspekt natürlich die Benutzerfreundlichkeit. Sie müssen messen, wie schnell jemand eine bestimmte Aufgabe auf seiner Website erledigen kann und wie einfach er das System zu bedienen findet, sowie verschiedene andere Kriterien.

Paul Boag: Es gibt viele Mechanismen, mit denen man diese verschiedenen Dinge messen kann. Es gibt einige großartige Tools und auch einige gute Metriken, die Sie übernehmen können. So gibt es zum Beispiel bei der Benutzerfreundlichkeit eine sogenannte Systembenutzerfreundlichkeitsskala, die eine sehr nützliche Messgröße sein kann. Aber ebenso gibt es Tools wie maze.design, die ich oft verwende, die messen, wie lange jemand braucht, um einen Einkauf zu tätigen, zum Beispiel, um durch die Kasse zu kommen. Also ja. Mit dieser breiten Palette an Kennzahlen konzentrieren Sie sich nicht nur darauf, wie viele Verkäufe wir in diesem Quartal getätigt haben? Du musst das Gesamtbild betrachten.

Drew: Im April habe ich mit Laura Kalbag von Better Blocker über Online-Datenschutz gechattet. Wir sprachen über die immer dünner werdenden Grenzen zwischen dem, was als öffentlich und privat gilt, und darüber, dass die Dinge, die wir als privat betrachten, von den Unternehmen, denen wir unsere Daten anvertrauen, möglicherweise nicht so gesehen werden. Hier ist Laura.

Laura Kalbag: Ich habe ein klassisches Beispiel dafür, das mir vor ein paar Jahren passiert ist. Also war ich auf Facebook und meine Mutter war gerade gestorben und ich bekam Anzeigen für Bestattungsunternehmen. Ich fand es wirklich seltsam, weil niemand aus meiner Familie zu diesem Zeitpunkt etwas auf einer Social-Media-Plattform gesagt hatte. Keiner aus meiner Familie hatte etwas auf Facebook gesagt, weil wir uns darauf geeinigt hatten, dass niemand so etwas über einen Freund oder ein Familienmitglied über Facebook erfahren möchte. Also hatten wir nicht darüber gesprochen.

Laura Kalbag: Also habe ich meine Geschwister gefragt: „Oh, hat einer von ihnen irgendetwas auf Facebook gesagt, das das seltsam machen könnte.“ Weil ich normalerweise nur Werbung für Make-up und Kleider und Schwangerschaftstests und all diese lustigen Dinge bekomme, über die sie gerne reden. Es sind Frauen in einem bestimmten Alter. Stattdessen meldete sich meine Schwester bei mir. Sie sagte: „Nun ja. Mein Freund lebt in Australien.“ Also schickte ich ihr eine Nachricht auf Facebook Messenger und sagte ihr, dass unsere Mutter gestorben war. Natürlich wusste Facebook, dass wir Schwestern sind. Es hat diese Beziehungsverbindung, die Sie dort hinzufügen können. Ich meine, es könnte wahrscheinlich sowieso vermuten, dass wir Schwestern sind, aufgrund der Orte, an denen wir zusammen waren, der Tatsache, dass wir einen Nachnamen teilen und entschieden haben: „Oh, das ist eine angemessene Werbung, um sie in ihre Füße zu stellen.“

Drew: Es ist ernüchternd, nicht wahr, zu glauben, dass die Technologie diese Entscheidungen für uns trifft, die Menschen in diesem Beispiel möglicherweise in einer ziemlich sensiblen oder verwundbaren Zeit betreffen?

Laura Kalbag: Ja. Wir sagen, es ist gruselig. Die Leute sagen oft: „Oh, es ist fast so, als würde mir das Mikrofon meines Telefons oder Laptops zuhören, weil ich gerade dieses Gespräch über dieses bestimmte Produkt geführt habe, und plötzlich taucht es überall in meinem Feed auf.“ Ich denke, was wirklich beängstigend ist, ist die Tatsache, dass die meisten von ihnen keinen Zugriff auf Ihr Mikrofon haben. Aber es ist die Tatsache, dass Ihr anderes Verhalten, Ihre Suche, die Tatsache, dass es aufgrund Ihrer Nähe zueinander und Ihres Standorts auf Ihren Geräten weiß, mit wem Sie sprechen. Es kann all die Dinge verbinden, die wir vielleicht nicht miteinander verbinden, um einfach zu sagen: „Oh, vielleicht interessieren sie sich für dieses Produkt, weil sie wahrscheinlich schon darüber nachgedacht und darüber gesprochen haben.“

Drew: Als die Coronavirus-Pandemie zuschlug und viele Nationen in eine Art Lockdown gerieten, sprach ich mit Rachel Andrew darüber, wie Smashing seine persönliche Konferenz anpasste, die stattdessen online stattfinden sollte. Nachdem ich gerade die Smashing-Konferenz in San Francisco verschieben musste, fragte ich Rachel, was der Plan sei, anstehende Konferenzen und Workshops in den virtuellen Bereich zu verlegen.

Rachel An Drew: Sehr, sehr schnell, als uns klar wurde, dass wir San Francisco verschieben mussten, haben wir natürlich Workshops, sowohl ich als auch Vitaly leiten Workshops bei smash and comp, und beide waren in San Francisco ausverkauft unsere Werkstätten. Offensichtlich haben wir viele andere Leute, die kommen und Workshops für uns leiten, Leute, mit denen wir lange Zeit zusammengearbeitet haben, und sie fanden heraus, dass alle ihre Workshops, und diejenigen von uns, die Workshops machen, sie tatsächlich a wichtiger Teil unseres Einkommens.

Rachel An Drew: Öffentliches Reden, normalerweise verdient man nicht viel Geld, wenn man öffentlich spricht. Die meisten Leute werden nicht viel bezahlt, nicht wenn man bedenkt, wie viel Zeit es braucht, um Vorträge zu schreiben und so weiter. Workshops sind in der Regel eine nette Möglichkeit für Leute, die dieses Zeug gut unterrichten können, um etwas Geld zu verdienen. Sie repräsentieren also das Einkommen der Menschen. Also brauchten nicht nur ich und Vitaly unsere Werkstätten Anfang dieses Jahres verloren. Wir stellten auch fest, dass viele unserer Smashing-Sprecher ebenfalls auf diese Workshops angewiesen waren.

Rachel An Drew: Also dachten wir: „Nun, warum bringen wir sie nicht einfach online?“ Sehr, sehr schnell, wirklich innerhalb von Tagen, nachdem das passiert war, entschieden wir, dass ich und Vitaly irgendwie die Ersten sein würden, die unsere Köpfe über die Macht strecken würden, aber vorausgesetzt, wir sind es und wir könnten irgendwie herausfinden, wie wir es machen. Wir haben auch sehr unterschiedliche Werkstätten. Vitaly ist viel kooperativer. Er hat Gruppenaktivitäten und so. Ich unterrichte im Klassenzimmer. Also dachten wir unter uns: „Nun, wir decken irgendwie alle Grundlagen ab.“ Also dachten wir: „Lass es uns einfach tun. Mal sehen, ob es funktioniert.“ Also werben wir für sie. Wir haben irgendwie herausgefunden, wie lange jeder gedauert hat, und dann haben wir uns irgendwie hingesetzt und gesagt: „Nun, wie sieht ein Online-Workshop wirklich aus? Was ist das?"

Drew: Ich denke, aus technischer Sicht als Webentwickler, die sofort denken, wie um alles in der Welt sollen wir so etwas liefern, ich meine, es muss viele verschiedene Plattformen geben, die Sie sich angesehen haben. Was waren die verschiedenen Dinge, die Sie sich angesehen haben, und was bringt Smashing schließlich mit sich?

Rachel An Drew: Wir haben uns also alle möglichen Dinge angeschaut und sind immer noch dabei, das zu tun. Wir verwenden derzeit Zoom. Der Grund, warum wir Zoom verwenden, ist Barrierefreiheit. Es war die zugänglichste der Plattformen. Natürlich wollen wir die Leute nicht wegen der von uns gewählten Plattform ausschließen. Ich denke, die anderen Plattformen werden besser und die Leute sind … Ich denke, dass viele Plattformen von Leuten besucht wurden und sagten: „Ja, du siehst toll aus. Aber wir brauchen Sie, um erreichbar zu sein.“ Daher ist Zoom für die Leute im Moment am einfachsten zu verwenden.“ Deshalb haben wir sie schließlich verwendet. Ich weiß nicht, ob wir das für immer tun werden. Aber das ist es, was wir im Moment verwenden, und es hat ziemlich gut funktioniert, um dieses Zeug zu machen.

Drew: Als die Zoom-Müdigkeit einsetzte und die Welt begann, sich auf das einzustellen, was schnell als neue Normalität bezeichnet wurde, sprach ich mit Phil Smith darüber, wie Technologie uns helfen kann, auf Situationen wie COVID-19 zu reagieren. Erstellung der React Native App, CardMedic in nur 10 Tagen. Ich habe Phil gefragt, wie er es schafft, die beste Technologie für den Job auszuwählen und die Technologien, mit denen er vertraut ist und mit denen er schnell arbeiten kann, in Einklang zu bringen.

Phil Smith: Das ist eine gute Frage. Ich denke, sobald mir das Projekt genannt wurde, dachte ich, ich weiß genau, wie ich das alles bauen werde. Wenn ich keine Kinder hätte und in einem dunklen Raum säße, hätte ich wahrscheinlich in fünf Tagen alles drehen können, wenn ich solide, solide, solide daran gearbeitet hätte, weil die Anforderungen sehr hoch waren im Einklang mit meiner Erfahrung beim Erstellen von Apps. Ich habe ähnliche Dinge gebaut, wo es eine API aufruft, die Ergebnisse im Zustand speichert und sie präsentiert. Ich bin jetzt an einer Position, wo es einige Stellen gibt, an denen ich denke: „Okay, ich muss zurückgehen und das umgestalten.“

Phil Smith: Ich habe über die Eingabe von Zinn gesprochen, aber tatsächlich können die Typen in der App ziemlich locker sein, und das muss gestrafft werden. Am Backend gibt es nicht viele Tests und jetzt fangen wir an, das Backend herauszubringen, weil viele Leute sich gemeldet haben und gesagt haben: „Eigentlich ist dies eine großartige Ressource. Ich würde gerne meine Dienste anbieten, um dies in meine Muttersprache zu übersetzen.“ Die Backends werden von mehr Leuten verwendet, also denke ich nur: „Warte, ich brauche hier noch ein paar Tests, um sicherzustellen, dass nichts kaputt gehen kann, weil es Leute gibt, die das jetzt in der Produktion verwenden.“ Ich glaube, ich habe deine Frage beantwortet. Im Wesentlichen gab es keine Entscheidungsfindung. Ich musste es einfach so schnell wie möglich rausbringen.

Drew: Da die Arbeitsplätze geschlossen wurden und sich viele von uns an die Arbeit zu Hause gewöhnt haben, habe ich mit Ben Frain darüber gesprochen, dass die Optimierung Ihres Heimarbeitsplatzes zu einem komfortablen und produktiven Ort nicht zu langfristigen körperlichen Gesundheitsproblemen führen wird. Da das Budget für die Einrichtung zu Hause begrenzt war, fragte ich Ben, ob ein guter Stuhl der beste Ausgangspunkt sei.

Ben Frain: Das wäre mein Rat. Ja. Ich meine, ich kann nicht behaupten, eine Autorität in diesen Dingen zu sein, aber es scheint, dass es wahrscheinlich das Wichtigste ist, was Sie tun können, um es sich den ganzen Tag über bequem zu machen. Sie können mit etwas ziemlich Teurem beginnen. Ich habe den gleichen Fehler gemacht und am Ende einen 45-Pfund-Bürostuhl von Amazon bekommen, und mir war nicht klar, dass er keine Neigung nach vorne, wie auch immer das richtige Wort für dieses Ding ist, auf der Achse hatte. Was ich also herausfand, war, dass es sich in die Unterseite meiner Oberschenkel grub, sozusagen hinter meinen Knien, und ich dachte: „Warum werden meine Beine tot, nachdem ich 45 Minuten in diesem Ding gesessen habe?“

Ben Frain: Ich denke, besonders wenn Sie für ein Unternehmen arbeiten, das anständige Bürostühle anbietet, nehmen Sie sie einfach als selbstverständlich hin, und erst wenn Sie sich diese bestimmte Marke und Marke ansehen, denken Sie: „Oh mein Gott, das ist ein 700-Dollar-Stuhl.“ Wenn dir klar wird, dass Leute darüber nachgedacht und viel für dich getan haben, und dann kommst du offensichtlich in deine häusliche Umgebung und denkst: „Warum nicht X-hundert Dollar für einen Stuhl ausgeben?“ Aber vielleicht lohnt es sich. Vor allem, wenn Sie auf lange Sicht hier sind.

Drew: Und die Langstrecke ist das, was wir haben. Etwas anderes, das es auf lange Sicht gibt, ist Drupal. Im Juni sprach ich mit Angie Byron über die Änderungen in Drupal 9. 20 Jahre nach seiner ersten Veröffentlichung hat Drupal einen langen Weg zurückgelegt. Ich habe Angie gefragt, wie der Prozess des Upgrades einer bestehenden Drupal-Site beim Umstieg auf Drupal 9 aussah und ob es wahrscheinlich eine große Belastung für diejenigen mit lang laufenden Sites sein würde.

Angie Byron: Ich denke, es gibt im Grunde drei Szenarien. Das eine ist, wenn Sie Drupal 8 ausgeführt haben und jedes Mal, wenn eine neue Nebenversion von Drupal 8 herauskam, Sie sie sofort auf eine aktualisiert haben und angefangen haben, die neuen Dinge zu nutzen. Ihr Weg wird im Grunde nichts sein. Du hast bereits die ganze Arbeit gemacht und es geht dir gut. Wenn Sie vor einiger Zeit zu Drupal 8 gewechselt sind und mit den BC-Änderungen nicht Schritt gehalten haben, gibt es ein wenig Arbeit für Sie.

Angie Byron: Es ist definitiv das einfachste Upgrade unserer Software seit über einem Jahrzehnt, und wir haben eine Menge verschiedener Tools, die Ihnen dabei helfen. Es gibt ein Dashboard, das alle beigetragenen Module und ihre Drupal 9-Situation zeigt. Es gibt automatisierte Tools, mit denen Sie Ihren Code durchgehen und überprüfen und veraltete Funktionen kennzeichnen können, und es gibt Tools, mit denen Sie automatisch nach oben gehen und feststellen können: „Oh, das ist die neueste Version Ihres Moduls, und es ist bereit für Drupal 9? Du solltest es herunterladen“, solche Sachen.

Angie Byron: Also von Drupal 8 bis 9 würde ich sagen, dass dieser Teil ziemlich gut abgedeckt ist. Wenn Sie von einer früheren Version von Drupal kommen, sagen wir Drupal 7 oder niedriger zu Drupal 9, sieht das etwas schwieriger aus. Unter den Änderungen, die wir in Drupal 8 vorgenommen haben, wo wir beispielsweise vollständig auf objektorientiertes PHP umgestiegen sind, haben wir begonnen, Designmuster zu verwenden, die in anderen Softwareprojekten gefunden wurden, was architektonisch eine wirklich kluge Sache ist, aber es tut es bedeutet, dass Sie, wenn Sie in Ihrem alten Leben eine Menge benutzerdefinierten Code hatten, in Drupal 9 Alternativen dafür finden müssen.

Angie Byron: Acquia ist also ein Produkt und eine Entwicklung namens Acquia Migration Accelerator, die darauf abzielt, dieses Problem zu lösen, indem wir eine nette React-definierte Anwendung erstellen, die Ihre alten Drupal 7-Daten einliest und äquivalente Drupal 8-Daten für Sie erstellt Zusammen mit allen Modulen, die Sie benötigen werden, ordnen Sie diese nach Möglichkeit Ihren alten Drupal 7-Modulen zu, um zu versuchen, diesen Prozess erheblich zu beschleunigen, da wir sicherstellen möchten, dass jeder, der ältere Versionen verwendet, es immer noch zu dem machen kann neue Weltordnung, wo alle auf der gleichen Version sind und wir alle zusammenarbeiten.

Angie Byron: Dann haben wir zusätzlich noch Drupal 7 erweitert… Die Open-Source-Community von Drupal, deren Lebensende in Drupal 7 ab November nächsten Jahres. Derzeit müssen wir sowieso diskutieren, ob COVID das beeinflusst oder nicht. Aber es gibt eine Reihe verschiedener Unternehmen, und Acquia ist eines davon, das darüber hinaus erweiterten Support für Drupal 7 bis mindestens 2024 anbietet. Das macht es also so, dass Leute, die ein einfaches Upgrade haben, anderthalb Jahre Zeit haben, um es zu erledigen, Leute, die ein weniger einfaches Upgrade haben, möglicherweise dreieinhalb Jahre haben, um es zu erledigen, oder länger, wenn sie müssen, und wir bemühen uns sehr, es allen zu ermöglichen, umzuziehen, und entwickeln dann Tools wie Acquia Migrate Accelerator, um den Prozess zu beschleunigen.

Drew: Learning React war das Thema eines Gesprächs mit Mina Markham. Mina und ich waren beide zum ersten Mal in der Lage, React zu lernen. Als ich darüber nachdachte, wie viel Last Frameworks wie React für den Browser bedeuten, fragte ich Mina, ob es ein Fehler sei, so viel Kontrolle in die Hände des Clients zu legen.

Mina Markham: Ich möchte ja sagen, mit dem Vorbehalt, dass sich meine Erfahrung wiederum stark auf meist statische Websites beschränkt. Ich mache nicht viel Produktentwicklung. Vielleicht macht das in diesem Bereich mehr Sinn. Aber aus meiner Sicht habe ich das Gefühl, dass wir oft ein Beil benutzen, wenn wir nur ein Buttermesser brauchen. Ich weiß nicht, warum wir das alles in den Browser packen müssen, so viel Arbeit und so viel Druck auf den Kunden ausüben, wenn wir viele Dinge tun können … Ich habe das Gefühl, wir könnten das viel einfacher machen. Eines der Dinge, die mich immer etwas zögerlich gemacht haben, React zu verwenden, oder ich sage zögerlich, aber was ich meine, wenn es mich innerlich wütend gemacht hat und ich mich aktiv dagegen ausgesprochen habe, war, wenn ich auf eine Website gegangen bin und buchstäblich nichts gerendert hätte weil Es gab einen Fehler oder so etwas wie wirklich die gesamte Seite ist kaputt, weil eine Funktion zusammengebrochen ist.

Mina Markham: Es hat mich nur irgendwie geärgert, dass es oft ein Alles-oder-Nichts-Ansatz war. In einem der Vorträge, die ich in der Vergangenheit bei AEA und an anderen Orten in der Vergangenheit gehalten habe, ging es darum, wie man progressive Verbesserung einbeziehen kann, und nicht nur Ihre Entwicklung, sondern auch eine umfassendere künstlerische Leitung und das Design von Websites. Ich möchte besonders auf Beispiele von Websites hinweisen, die keine progressive Verbesserung oder irgendeine Art von anmutiger Verschlechterung durchgeführt haben. Entweder haben Sie das JavaScript im Browser ausgeführt, oder Sie erhalten absolut nichts. Es wäre nur eine einfache Website, die Informationen über die Geschichte des Webdesigns darstellt, die eine der Websites war, über die tatsächlich gesprochen wurde, die Geschichte des Webdesigns von etwa 1990 bis heute. Es war eine wunderschöne Website mit vielen Zeitleisten und Animationen von Dingen. Aber es hätte auch statisch nur mit einer Liste gerendert werden können. Es gab Schritte zwischen dem Zeigen von nichts und dem Zeigen dieser wunderbar verbesserten Erfahrung, die meiner Meinung nach aufgrund der Art und Weise, wie wir uns der modernen Webentwicklung nähern, verloren gegangen ist.

Drew: Ich habe mit Andy Bell über CUBE CSS gesprochen, eine Styling-Methodik nach Art von BEM, SMACSS und OOCSS. Viele CSS-Ansätze versuchen, den natürlichen Eigenschaften von CSS wie der Kaskade entgegenzuwirken. CUBE begrüßt dieses Verhalten sehr. Hier ist Andi.

Andy Bell: Eine gute Art von Analogie dafür ist, dass SCSS, wie Sass, eine Erweiterung der natürlichen CSS-Sprache ist, nicht wahr? In CSS hast du immer noch ziemlich recht. CUBE CSS ist also so. Es ist also eine Erweiterung von CSS. Also sollten wir immer noch CSS schreiben, wie CSS sollte … nun ja, es soll geschrieben werden. Mal ehrlich, so soll es geschrieben werden. Der Name verrät es, Cascading Style Sheets. Also nehme ich das wieder an, weil ich herausgefunden habe, dass ich den ganzen Weg bis hinunter zur Mikrooptimierungsebene gegangen bin. Ich bin den Weg gegangen, den ich in letzter Zeit viele Leute gesehen habe, die dort hinabgegangen sind, wo … Ich habe das auch in dem Artikel erwähnt, wo ich sehen kann … Es gibt kürzlich einige Beweise dafür. Ich habe gesehen, dass Leute Abstandhalterkomponenten und ähnliches erstellt haben, und ich verstehe dieses Problem. Ich war in dieser Situation.

Andy Bell: Die Art und Weise, wie ich es behoben habe, war, dass ich, anstatt einen Drilldown durchzuführen und zu versuchen, Mikrooptimierungen vorzunehmen, tatsächlich anfing, stattdessen auf einer kompositorischen Ebene über die Dinge nachzudenken, weil es keine Rolle spielt, wie klein Ihre Komponenten sind. Irgendwann werden sie Seiten sein. Sie werden Ansichten sein. Das kannst du nicht vermeiden. So wird es sein. Anstatt also zu sagen: „Richtig, ich brauche diese winzigen Helfer für dieses Layout“, sagen Sie: „Richtig, ich habe einen Kontaktseitenaufruf oder einen Produktseitenaufruf, und das ist eine skelettartige Layoutkomposition. Darin kann ich dann alle Komponenten einsetzen, die ich will.“

Andy Bell: Wir haben jetzt Dinge wie Grid und Flexbox, die das viel einfacher machen, und Sie können im Wesentlichen alles, was Sie wollen, in das Skelettlayout einfügen. Es spielt keine Rolle. Dann sollten sich die Komponenten zu diesem Zeitpunkt so verhalten, wie Sie es möchten, mit oder ohne Containerabfragen.

Drew: Gatsby war das Thema meines Gesprächs mit Marcy Sutton. Während die meisten Static-Site-Generatoren Front-End-Code-agnostisch sind, verwendet Gatsby React, und daher läuft der Gatsby-Code als Teil Ihrer endgültigen Web-Erfahrung. Ich fragte Marcy, was das für ein Code sei und welche Funktionalität er bereitstelle.

Marcy Sutton: Ja. Ich würde sagen, der größte Teil davon ist das clientseitige Routing. Also verwendet Gatsby gerade Runderneuerer unter der Motorhaube. Es ist nur eine Art eigene Implementierung. Aber das ist das Stück, wenn Sie Ihre statische Site zum ersten Mal laden, gibt es dort HTML-Dateien. Wenn also der Benutzer JavaScript aus irgendeinem Grund deaktiviert, sollte Ihre Website immer noch da sein, immer noch Inhalte haben. Aber wenn JavaScript aktiviert ist, findet dieser Hydratationsschritt statt, bei dem, wenn Sie Links auf Ihrer Gatsby-Site verwenden, Ressourcen von dieser Seite vorab abgerufen werden. Es wird also schneller geladen. Das alles ist also mit dieser JavaScript-Ebene möglich, die Gatsby Ihnen gibt.

Marcy Sutton: Darüber hinaus hängt es wirklich davon ab, was Sie auf Ihrer Website verwenden, was in diesem JavaScript-Bundle landen wird. Aber für Dinge, die viel Interaktivität erfordern, wie zugängliche Schnittstellen, ist dies ein guter Ort. Ich persönlich genieße es wirklich, JavaScript jederzeit zur Verfügung zu haben und mein Markup einfach an einem guten Ort zu haben. Ich weiß, es ist eine Frage der Vorlieben, ob Sie Ihr HTML und Ihr JavaScript und Ihr CSS alle irgendwie sauber gekoppelt haben möchten, und es gibt Raum für Variationen beim Erstellen von Gatsby. Sie müssen nicht immer so etwas wie CSS und JS verwenden. Aber es geht wirklich darum, Ihnen die Leistungsfähigkeit dieser dynamischen JavaScript-Ebene zur Verfügung zu stellen, während Sie Ihre Website schreiben. Es ist nicht wie dieses Add-On in einer separaten Datei.

Drew: Wenn ich daran denke, wie ein statischer Website-Generator normalerweise funktioniert, denke ich an Inhalte in vielleicht Markdown-Dateien und der Generator läuft über diese Inhalte und führt sie mit Vorlagen zusammen und erstellt Zehn, Hunderte, Tausende von HTML-Dateien, die das sind Seiten Ihrer Website. Wenn ich an eine React-Site oder -App denke, denke ich eher an Single-Page-Erlebnisse, bei denen die Schnittstellen von React on the fly erstellt werden. Sie sagen also, Gatsby macht beides? Es erstellt alle Seiten und verbessert sie auch mit JavaScript?

Marcy Sutton: Das ist es, ja. Gatsby wird Node.js zur Build-Zeit verwenden, es wird Ihre React-Komponenten durchgehen und sie in HTML-Dateien kompilieren, was ehrlich gesagt, als ich mir Gatsby zum ersten Mal ansah, würde ich JavaScript nicht deaktivieren und sagte: „In Ordnung, gibt es hier noch andere seiten? Was ist das?" Ich war so froh, dass Gatsby standardmäßig so funktioniert. Es erstellt erstellte Dateien aus Ihren React-Komponenten, was großartig ist.

Marcy Sutton: Ich habe progressivere Verbesserungsansätze untersucht, seit es JavaScript gibt, wie zum Beispiel, was ist, wenn Sie etwas progressiv Verbessertes für Benutzer ausgeben möchten, wo, wenn sie JavaScript deaktiviert haben, Sie all diesen kaputten Code nicht wollen, der JavaScript voraussetzt Gibt es. Es gibt also einige Macken damit. Aber Sie können so etwas umgehen, zumindest für Ihre Kernbenutzerströme, bei denen Sie möchten, dass jemand immer noch etwas kaufen kann. Möglicherweise müssen Sie für diese Anwendungsfälle etwas Unterstützung hinzufügen. Aber ich war angenehm überrascht, wie Gatsby das standardmäßig ausrollt.

Marcy Sutton: Es ist also eine Entscheidung, die sie getroffen haben, Websites auf diese Weise zu erstellen, und wir evaluieren immer, ob es immer noch der beste Weg ist? Was müssen wir tun, um unseren Benutzern das zu geben, wonach sie fragen? Wir führen also intern einige Erkundungen durch, um sicherzustellen, dass Gatsby beim Erstellen einer Website die bestmögliche Arbeit leistet. Halten Sie also die Paketgrößen klein und stellen Sie sicher, dass wir für das, was wir sagen, einen leistungsfähigen Code mit pre-Kompromissen eingehen - Holen Sie sich, haben wir die Daten, um das zu belegen? Das ist die Art von Dingen, an denen ich als Developer Advocate sehr interessiert bin, sicherzustellen, dass das, was wir auf Websites packen und bündeln, tatsächlich benötigt wird und wirklich die beste Gatsby-Site wird, die sie machen kann.

Drew: Als ich im Juli mit Chris Ferdinandi sprach, fragte ich, ob moderne Best Practices schlecht für das Internet seien. Chris backs a movement known as the Lean Web, and I asked him what that entailed. Here's Chris.

Chris Ferdinandi: When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. Ich bin zu der Überzeugung gelangt, dass vieles, was wir heute als Best Practices betrachten, das Web tatsächlich schlechter machen könnte. The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I'm sorry, not the developer experience, the user experience rather, over the developer experience and the ease of building things from a team perspective, which is what I think where we put a lot of focus today.

Chris Ferdinandi: As we'll probably get into in our conversation, I've actually come to find that a lot of these things we think of as improving the developer experience do so for a subset of developers but not necessarily everybody who's working on the thing you're building. So there's a whole bunch of kind of issues with that too that we can kind of dig into. Aber eigentlich geht es beim Lean Web darum, sich auf Einfachheit und Leistung für den Benutzer zu konzentrieren und wirklich Prioritäten zu setzen oder den Fokus auf die Menschen zu legen, die die von uns hergestellten Dinge verwenden, und nicht auf uns, die Menschen, die sie herstellen.

Drew: In August, Chris Coyier joined us to talk about all things serverless. I asked him what sort of the tasks they were putting serverless to over at CodePen?

Chris Coyier: Well, there's a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… The point of CodePen is that you write each HTML, CSS, and JavaScript in the browser, and it renders it in front of you, right? Sie können aber auch Präprozessorsprachen auswählen. Nehmen wir an, Sie mögen Sass. Sie aktivieren Sass im CSS und schreiben Sass. Naja, irgendwas muss die Sass verarbeiten. Heutzutage wird Sass in Dart oder so geschrieben. Theoretically, you could do that in the client. Aber diese Bibliotheken, die die Vorverarbeitung durchführen, sind ziemlich groß. Ich glaube nicht, dass ich Ihnen die gesamte Sass-Bibliothek schicken möchte, nur um das Ding zu betreiben. I don't want to. That's not the right architecture for this necessarily. Maybe it is down the road. I mean, we could talk about offline crap, yada, yada, web workers.

Chris Coyier: There's a million architectural things we could do. Aber so funktioniert es jetzt, gibt es ein Lambda. Es verarbeitet Sass. Es hat einen winzigen, winzigen, winzigen, kleinen Job. You send it this blob of Sass, and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job, and we probably pay for that lambda like four cents or something. Because lambdas are just incredibly cheap, and you can hammer it too. Sie müssen sich keine Sorgen um die Skalierung machen. You just hit that thing as much as you want, and your bill will be astonishingly cheap.

Chris Coyier: There is moments where serverless starts to cross that line of being too expensive. I don't know what that is. I'm not that master of stuff like that. But generally, any serverless stuff we do, we basically all nearly count as free, because it's that cheap. Aber es gibt einen für Sass. Es gibt einen für weniger. Es gibt einen für Babbel. Es gibt eine für TypeScript. Es gibt einen für … All das sind individuelle Lambdas, die wir betreiben. Here's some code, give it to the lambda. It comes back, and we do whatever we're going to do with it. Aber wir verwenden es für viel mehr als das, sogar in letzter Zeit.

Chris Coyier: Here's an example. Jeder einzelne Stift auf CodePen hat einen Screenshot. Das ist irgendwie cool, oder? So the people make a thing, and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. Wenn Sie es in Slack teilen, erhalten Sie eine kleine Vorschau davon. We use it on the website itself to render… Instead of an iframe, if we could detect that the Pen isn't animated, because an iframe's image is much lighter, so why not use the image? Es ist sowieso nicht animiert. Nur solche Leistungsgewinne.

Chris Coyier: So each of those screenshots has a URL to it, obviously. We've architected it so that that URL is actually a serverless function. Es ist ein Arbeiter. So if that URL gets hit, we can really quickly check if we've already taken that screenshot or not. That's actually enabled by CloudFlare Workers, because CloudFlare Workers are not just a serverless function, but they have a data store too. They have this thing called key-value store. So the ID of that, we can just check really quick, and it'll be, “True or false, do you have it or not?”

Chris Coyier: If it's got it, it serves it, and it serves it over CloudFlare, which is super fast to begin with and then gives you all this ability too because it's an image CDN, you can say, “Well, serve it in the optimal format. Servieren Sie es als diese Dimensionen.“ Ich muss das Bild nicht in diesen Dimensionen machen. You just put the dimensions in the URL, and it comes back as that size, magically.

Drew: I talked to Next.js co-creator, Guillermo Rauch about the features on offer in Next.js and asked about its automated code splitting functionality. As the size of our JavaScript bundles can have quite an impact on performance, I was interested to know if Next had ways to tackle that. Here's Guillermo.

Guillermo Rauch: Yeah. Your observation is 100% right. So one of the biggest things with the web and one of the biggest weights on the web is JavaScript. Just like different materials have different densities and weights, irrespective of the actual physical volume, JavaScript tends to be a very dense, heavy element. Even small amounts of JavaScript compared to, for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.

Guillermo Rauch: So Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. So the first one that was my first intuition when I first sort of came up with the idea for Next.js was, okay, you're going to define, for example, 10 routes. In the Next.js world you create a pages directory, and you drop your files in there, index.js, about.js, settings.js, dashboard.js, terms-of-service.js, signup.js, login.js. Diese werden zu Einstiegspunkten für Ihre Anwendung, die Sie über alle Arten von Medien teilen können.

Guillermo Rauch: When you enter those, we want to give you JS that is relevant for that page, first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Next.js, das sehr, sehr nett ist, ruft auch automatisch den Rest der Seiten vorab ab, die mit diesem Einstiegspunkt verbunden sind, sodass es sich wie eine Single-Page-Anwendung anfühlt. So a lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Well, look. You can define those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it's better optimized with regards to that initial paint, that initial entry point.”

Drew: In September, I had the pleasure of talking to Cassie Evans about SVG animation. We talked about the approachability of SVG for developers who are already familiar with HTML. Here's Cassie.

Cassie Evans: I think that that's what I love the most about SVG is I'm really into creative coding and also teaching people, and I found that teaching people who are more of a creative leaning, they sometimes get a little thrown off when you immediately jump in with JavaScript or Python or something like that for creative coding. But without fail, I've managed to get anyone that I taught on board with SVG because there some really approachable entry points because it does look like HTML.

Cassie Evans: So you can give someone with an understanding of HTML and how to build websites SVG, and it looks the same, but it's the graphics instead of documents, and then you can animate that with CSS to start off with, which is also a little bit more comfortable, and then you can kind of progress to animating it with JavaScript. So it's a really good learning curve.

Drew: Of course, it can be dynamic. It's not just a case of creating motion. You can actually make the properties of it dynamic. So one of the interesting things I've seen SVG used for, and it's a grand term, but data visualization, dataviz, and drawing graphs and charts and of course things like dashboards that we seem to have everywhere these days. SVG is sort of perfect for that, isn't it?

Cassie Evans: Yes, definitely. SVG is great for dataviz. All the way from kind of small dataviz up to D3 which is very well known dataviz library that uses SVG under the hood. But you could also just, if you've got a little bit of data that you wanted to show on a web page, you could create a chart in a graphics editing program, and then you could just use JavaScript to change those values and kind of change how your graph looks. So you don't have to go all in with a massive database library. You can kind of just start off small.

Drew: The Jamstack framework, RedwoodJS was the topic of conversation with Anthony Campolo. I asked Anthony what it meant to be a full-stack Jamstack framework in practical terms.

Anthony Campolo: Yeah, it's pushing the boundaries of what a Jamstack application can be. So by calling it full-stack Jamstack, it's about, how do we go beyond just the front end to having the same sort of deployment paradigm of just get pushed, getting your whole code deployed? How do we get that but also with our back end and have it all connected?

Drew: Vue.js version three was released in October, and I caught up with Natalia Tepluhina from the Vue core team. Discussing the new version, I was curious if the major version bump was just a result of a few backward incompatible modifications or if this was a very clear revisiting of Vue to make deeper changes to the framework.

Natalia Tepluhina: No. I think it was an idea to create a new version due to a few very important things. Zunächst einmal gab es also eine Motivation, die Reaktivität zu ändern. Previous one was built upon Object.defineProperty, and it had a few caveats. They're all documented, but still, even if you document something that people shouldn't do, they will do it anyway, and you would need to point them to the documentation. Nobody reads documentation, by the way. For some reason, it just happens. Until you point people out, it doesn't exist in docs, it does. Aber okay. Wir unterrichten Sie trotzdem.

Natalia Tepluhina: So reactivity was one of the things. Performance was the next. Vue 2 still had and has not the worst performance, but we had a few ideas about how to make Vue faster, and also, there was one pain point for a particular part of our, let's say audience, people that use Vue. Es war TypeScript. Vue 2 internally was written in Flow, which is still strongly typed one, but typing with TypeScript were a real nightmare especially if you were working with our state management Vuex.

Natalia Tepluhina: Das war also wieder ein Riesenteil. Das letzte war, dass wir die Funktionalität zur Abstraktion von Logik irgendwie vermisst haben, nicht in Bezug auf Komponenten, sondern in Bezug auf zusammensetzbare Logikteile, wie Funktionshelfer und so weiter, aber sie sollten auch in der Lage sein, Vue-Aktivitäten einzuschließen. Ein schönes Beispiel hier könnten React Hooks sein, oder? Sie ermöglichen es Ihnen, die Teile der Funktionalität zu abstrahieren, und das hat in Vue eindeutig gefehlt. Ich weiß, dass es sich im Moment anhört wie: „Du hast das Feature von React gestohlen.“ Nicht in der Tat. Ich glaube, dass die gegenseitige Befruchtung von Ideen ein großer und schöner Teil in unserem Ökosystem ist und Entwicklern auch hilft, zwischen Favoriten zu wechseln, oder? Also haben wir an diesen Hauptfunktionen gearbeitet, um Vue 3 als Hauptversion zu erstellen.

Drew: Anschließend haben wir uns mit Stefan Baumgartner mit TypeScript beschäftigt, um herauszufinden, wie es uns helfen kann, besseren Code mit weniger Fehlern zu schreiben. Angesichts des Trends, dass Unternehmen ihre Codebasis vollständig auf JavaScript umstellen, fragte ich Stefan, ob TypeScript etwas sei, von dem größere Teams mehr profitieren würden als Einzelpersonen.

Stefan Baumgartner: Also ich bin gerade in der gleichen Umstellung. Wir haben also viele Java- und C++-Entwickler, die in Zukunft viel JavaScript schreiben werden. TypeScript kann eine Art Leitfaden für diese beängstigenden Bereiche der neuen Programmiersprache sein. JavaScript hat viele Macken, viel Geschichte und viele Vorurteile, wenn Sie aus einer anderen Programmiersprache kommen. TypeScript kann also ein Leitfaden sein, da es einige Konzepte gibt, mit denen Sie im Typsystem vertraut sind.

Stefan Baumgartner: Aber ich denke auch, besonders wenn viele Leute an derselben Codebasis arbeiten oder viele Leute zusammenarbeiten müssen, kann dies eine zusätzliche Führungsebene in Ihrem Projekt sein, wo Sie es nicht tun Am Ende gibt es keine bösen Überraschungen. Technologie löst also natürlich keine Kommunikationsprobleme. Dafür ist TypeScript nicht gedacht. Aber es kann weniger oder viel mehr Platz für die richtige Diskussion schaffen, als wenn Sie nicht darüber sprechen müssen, was Sie von mir in Ihrem Code erwarten, sondern was Ihr Code tun soll oder was Ihr Code tun soll Bibliothek tun?

Stefan Baumgartner: Ich sage immer, wenn Sie jemals Code für andere Leute schreiben oder wenn Sie Code mit vielen Leuten schreiben oder wenn Sie Code nur für sich selbst schreiben, müssen Sie am nächsten Tag noch einmal darüber nachdenken, TypeScript in Betracht zu ziehen, weil es Ihnen in der Zukunft helfen könnte auf lange Sicht. Dies ist nicht nur eine Investition für das nächste Projekt nächste Woche, sondern eher für jemanden, der sagt, okay, besonders wenn Sie langfristige Projekte für Monate, zwei oder Jahre haben, bieten Sie das auf jeden Fall an. Sie werden nie wissen, woran Sie gedacht haben, als Sie das kleine Stück Code vor einem Jahr geschrieben haben, aber Typen können Ihnen einen Hinweis darauf geben, was Sie gemeint haben.

Drew: Im November unterhielt ich mich mit David Darnes über den Static-Site-Generator Eleventy. Wir haben über Templating gesprochen und darüber, wie viele Static-Site-Generatoren ziemlich uneins darüber sind, welche Art von Templating Sie verwenden sollten. Ich fragte mich, ob Eleventy die gleichen starken Überzeugungen hatte. Hier ist David.

David Darnes: Nein, ich muss sagen, es ist so nah wie möglich an Meinungslosigkeit. Ein bisschen eine persönliche Sichtweise, aber ich hatte Mühe, einen Rahmen oder irgendetwas zu sehen, das unvoreingenommen sein kann, denn um etwas zu schaffen, muss man eine Meinung dazu haben, wie man etwas tun möchte. Es ist eine Art Oxymoron. Ich bin sicher, die Leute könnten mich da korrigieren. Aber ja. Sie können zu jeder Vorlagensprache wechseln, mit der Sie sich am wohlsten fühlen. Ich meine, wir haben gerade über Sprachen gesprochen, mit denen Sie sich wohlfühlen. Eleventy appelliert in gewisser Weise daran, welche Templating-Sprachen in Ihrem HTML oder sogar in Ihrem CSS verwenden, wenn Sie möchten.

David Darnes: Für mich bin ich direkt zu den Nunjucks gegangen, weil Nunjucks die Standard-Template-Sprache innerhalb von Eleventy ist. Das heißt, ich kann die Punkt-HTML-Erweiterung verwenden und sie so lassen, wie sie ist. Jetzt werde ich die Leute nur noch mehr verwirren und sagen: „Du kannst das sowieso benennen, wie du willst. Damit kann man richtig Spaß haben.“ Aber Sie können einen Lenker verwenden. Ich denke, Sie können einfach normale JavaScript-Vorlagen verwenden und so iterieren. Lenker sehr beliebt und auch Liquid. Mir fallen nicht alle auf Anhieb ein, aber wenn Sie alles in der Konfiguration einrichten, können Sie einfach auswählen, wie Sie es möchten.

David Darnes: Ich würde sagen, ich bin ein wirklich großer Fan von Template-Sprachen im Allgemeinen. Es ist noch nicht lange her, als ich herausfand, dass man Twig in WordPress verwenden kann, und das hat mich umgehauen. Ich dachte: „Oh, Gott sei Dank. Ich muss keine for-Schleife innerhalb von PHP handhaben.“ Auch hier denke ich, etwas komfortabler und verständlicher, auch lesbarer. Also ja. Eleventy hat viele verschiedene Templating-Optionen, und es sollte Leute ansprechen, die mit diesen verschiedenen vertraut sind.

Drew: Ich habe mit Leslie Cohn-Wein darüber gesprochen, wie Netlify seine eigene Plattform verwendet, um Netlify zu erstellen, und wie ihre Deploy Preview-Funktion zu einer effektiven Staging-Plattform für Front-End-Änderungen wird.

Leslie Cohn-Wein: Vielleicht ist mein Lieblingsteil dieses ganzen Prozesses die Magie von Deploy Previews, die wir durch Netlify erhalten. Was also passiert, ist, dass Sie in GitHub arbeiten und Ihre PR nach oben treiben. Sie öffnen also Ihre PR in GitHub, und das wird automatisch einen Build Ihrer Deploy Preview der App erstellen. Also verwenden wir Deploy Previews der App selbst zum Testen, um sicherzustellen, dass alles so funktioniert, wie es sollte. Wir führen unsere Tests durch. Das verwenden wir sozusagen, um während der Codeüberprüfung manuell zu überprüfen. Wir haben also sozusagen all diese kontinuierliche Bereitstellung direkt von GitHub aus eingerichtet.

Leslie Cohn-Wein: Eines der anderen coolen Dinge, die wir eingerichtet haben, ist, dass wir tatsächlich ein paar verschiedene Netlify-Sites haben, die aus demselben Repository ziehen, in dem sich unsere App befindet. Also haben wir beide unsere App. Wir haben eine Instanz von Storybook, die eine Art unserer UI-Komponenten für die App enthält. Wir haben also sowohl unsere App selbst. Wir haben die Storybook-UI-Komponenten, und wir haben im Grunde eine Netlify-Site, die unsere Storybook-UI zeigt, und dann haben wir auch eine dritte Site, die einen Webpack-Bundle-Analysator ausführt. Es handelt sich also um eine Art visuelle Benutzeroberfläche, die Ihnen eine Baumkarten-Visualisierung aller App-Bundles bietet, und wir können ihre Größe einschätzen, und es ist nur eine Erinnerung für uns, bei jeder Bereitstellung der App doppelt zu überprüfen raus, wir können nachsehen und sicherstellen, dass wir mit unserer Bündelgröße dort nichts Seltsames machen.

Leslie Cohn-Wein: Alle drei dieser Seiten werden also in einem Pull-Request der App generiert. Sie erhalten also Links zur Vorschau, im Wesentlichen zu Ihren Bereitstellungsvorschauen, sowohl des App-Storybooks als auch zu diesem App-Profil, damit wir es überprüfen können.

Drew: Im Dezember habe ich mit Chris Murphy über Produktdesign gesprochen und darüber, was es für Unternehmen bedeutet, fokussiert gestaltet zu sein. Wir haben diskutiert, ob der Designfokus eines einzelnen Gründers in das Unternehmen eindringt und ob ein Produkt natürlich eine Erweiterung der Person ist, die es entwickelt hat.

Chris Murphy: Ich denke, das ist eine wirklich gute Frage, Drew, und ich denke, die Antwort darauf ist, dass es darauf ankommt. Ich denke, es hängt von dieser Person ab, und es hängt von der Größe des Unternehmens ab. Wenn Sie sich Hiut Denim ansehen, und ich verwende Hiut oft in meinem Unterricht, ist es ein wirklich gutes Beispiel für ein Unternehmen, das eine Sache gut macht, und das sind ihre Art von Jeans mit Riemen. Ich denke, wenn Sie sich Davids vorherige ansehen … David und Clare, weil sie eine Partnerschaft sind. Wenn Sie sich das frühere Unternehmen von David Hieatt und Clare Hieatt ansehen, Howies, war dieses Unternehmen so groß geworden, dass so viele Menschen daran beteiligt waren.

Chris Murphy: Sobald sich die Skalierung einschleicht, wird es sehr schwierig, all die kleinen Berührungspunkte im Auge zu behalten, die in der Customer Journey wichtig sind. Ich denke, es ist wirklich aufschlussreich, dass, als sie Howies verließen, weil Howies gekauft wurde von … Es ist kompliziert. Lies es doch mal im Internet. Aber es war Timberland, und Timberland wurde gekauft, und da ist diese ganze Geschichte.

Chris Murphy: Ich finde es wirklich interessant, dass sie sich jetzt auf Jeans konzentrieren. Das ist es. Sie erzählen eine erstaunlich gute Geschichte rund um Jeans. Sie verpacken auch alles sehr, sehr gut, und die Jeans sind wirklich wie ein Vehikel für Geschichten. Das ist etwas, von dem ich denke, Drew, dass es wichtiger wird, wenn wir am anderen Ende von COVID herauskommen, von dem ich hoffe, dass wir am anderen Ende herauskommen. Jeder, der diese Jeans herstellt, bekommt einen angemessenen Lohn. Eines der Probleme, die ich im Moment habe, wenn ich auf die Welt schaue, ist, dass nicht jeder einen angemessenen Lohn bekommt, und ich finde das ein bisschen besorgniserregend, als jemand … Schauen Sie, ich bin 51. Mein Sohn ist 25, 24 , 25, so ähnlich. Es ist schrecklich. Ich sollte all diese Dinge wissen. Er ist Hochzeitsfotograf. Er ist seit ungefähr einem Jahr und ein bisschen Hochzeitsfotograf. Sein Geschäft ist völlig dezimiert, weil momentan niemand wirklich heiratet, weil es einfach schwierig ist. Er hat kein Gehalt, weil er nicht genug selbstständige Bücher hatte, um die Unterstützung zu bekommen.

Chris Murphy: Er ist durch das Raster gefallen, und es gibt eine Menge anderer Leute, die durch das Raster gefallen sind. Ich würde argumentieren, dass das ein Designproblem ist, dass wir das als Designproblem betrachten müssen. Aber wenn ich mir auch das breitere Thema COVID und die Regierung und all diese Dinge anschaue, ohne zu politisch zu werden, habe ich gestern einen Artikel im Guardian über Matt Hancocks Nachbarn gelesen, und jeden, der zuhört, der nicht aus Großbritannien kommt, Matt Hancock ist es der Gesundheitsminister. Sein Nachbar, der ein Geschäft führte, schrieb ihm eine SMS und bat um Rat: „Wie liefere ich Produkte für dieses COVID-Ding?“ Es gibt eine Menge Gerüchte um die Chumokratie, nennen es die Zeitungen, Freunde von Freunden von Regierungsministern, die Jobs zu bekommen scheinen, weil sie die richtigen Leute kennen.

Chris Murphy: Ich habe das Gefühl, dass wir zum anderen Ende kommen und dies sehen werden … Einzelpersonen sehen das und sie denken: „Nun, wo fließt dieses Geld hin und werden die Leute angemessen bezahlt? Was kostet dieses Ein-Pfund-T-Shirt aus Shop X?“ Ich möchte keine Marken nennen. Aber für alles muss bezahlt werden, und für alles, was hergestellt wird, müssen Menschen bezahlt werden, um es herzustellen. Ich denke, die Leute interessieren sich zunehmend dafür, ob die Leute fair bezahlt werden?

Drew: GraphQL war das Thema unserer letzten, vollständigen Episode des Jahres, und ich habe mich mit Eve Porcello unterhalten und gefragt, wo GraphQL in den Entwicklungsstapel passt.

Eve Porcello: Ja. GraphQL passt irgendwie zwischen das Frontend und das Backend. Es lebt also irgendwie in der Mitte zwischen den beiden und bietet Front-End-Entwicklern und Back-End-Entwicklern viele Vorteile. Wenn Sie ein Front-End-Entwickler sind, können Sie alle Datenanforderungen Ihres Front-Ends definieren. Wenn Sie also beispielsweise eine große Liste von React-Komponenten haben, könnten Sie eine Abfrage schreiben, die alle Felder definiert, die Sie benötigen, um die Daten für diese Seite zu füllen.

Eve Porcello: Jetzt, mit dem Backend-Stück, ist es wirklich eigen, weil wir viele Daten aus vielen verschiedenen Quellen sammeln können. Wir haben also Daten in REST-APIs und Datenbanken und all diesen verschiedenen Orten, und GraphQL bietet uns diese nette kleine Orchestrierungsebene, um das Chaos, in dem sich all unsere Daten befinden, wirklich zu verstehen. Es ist also wirklich nützlich für so ziemlich jeden auf dem ganzen Stack.