The Kind of Development I Like

Ich werde nächstes Jahr 40 (igitt!) und obwohl ich seit über 25 Jahren Websites erstelle, habe ich das Gefühl, dass ich endlich anfange zu verstehen, welche Art von Entwicklung mir gefällt. Wie erwartet, sind dies keine neuen Erkenntnisse und meine Ansichten lassen sich durch zwei ältere Leitsätze der Informatik zusammenfassen, die meiner Karriere vorausgehen.

1. Komposition statt Vererbung
2. Konvention vor Konfiguration

Erlauben Sie mir, Sie auf eine kurze Reise mitzunehmen. In der modernen komponentengetriebenen Webentwicklung stoße ich oft auf oder sehe Strukturen wie diese.

<ComponentA>
  <ComponentB>
    <ComponentC />
  </ComponentB>
</ComponentA>

Dieser Weg führt zu einem System, bei dem alles verschachtelte Kindkomponenten sind und Props oder Daten von übergeordneten Komponenten nach unten weitergegeben werden. Es funktioniert, aber für mich nimmt es den Spaß am Programmieren. Es fühlt sich eher wie Klempnerarbeit als wie Programmieren an.

Als ich Frameworks von Mozilla sah, wie das neue ECSY-Framework für 2D-Spiele und 3D-Virtual-Reality-Szenen, fühlte ich mich sofort zu seinem Programmiermodell hingezogen, bei dem Komponenten ihre Verhaltensweisen an Objekte namens Entities ketten.

EntityA
  .addComponent('ComponentA')
  .addComponent('ComponentB')

Hey! Das sieht aus wie eine verkettete jQuery-Methode. Das gefällt mir, und das nicht nur aus Nostalgie. Es ist die „Komposition“ von Funktionalität, die mir gefällt. Ich weiß, dass CSS voller Vererbungsprobleme ist, aber es erinnert mich daran, gut geformte CSS-Klassen hinzuzufügen. Dazu neige ich. Zu wissen, dass ich persönlich Komposition bevorzuge, hat mir tatsächlich geholfen, einige seltsame widersprüchliche Gefühle aufzulösen, warum ich React Hooks (Komposition) wirklich mag, obwohl ich das größere React-Ökosystem (Vererbung) nicht besonders mag.

Ich denke, ich muss mich für viel fehlgeleiteten Ärger über React entschuldigen. Als Komponentensystem ist es großartig. Ich habe es bei einigen Projekten verwendet, aber nie wirklich eine Bindung dazu entwickelt. Ich glaube, ich habe mich geschämt, dass mir diese sehr beliebte Abstraktion nicht gefiel und ich mich nicht im Einklang mit der öffentlichen Meinung fühlte. Jetzt verstehe ich glaube ich besser, warum.

Ich sollte mich auch bei webpack entschuldigen. Als Bündelungs- und Tree-Shaking-Tool leistet es hervorragende Arbeit. Es ist sogar noch besser, wenn die gesamte Konfiguration in Tools wie Angular CLI und Nuxt versteckt ist. Meine Frustrationen waren real, aber da ich mehr über mich selbst lerne, erkannte ich, dass es vielleicht etwas anderes ist…

Meine Frustrationen mit der modernen Webentwicklung haben sich in immer niedrigere Abstraktionsebenen verlagert. Ich denke jetzt über npm nach und frage mich, ob es für einige der Schmerzpunkte der modernen Webentwicklung heute mitverantwortlich ist. Tatsächlich ist npm eine serverseitige Technologie, die wir auf dem Client übernommen haben, und ich glaube, wir spüren die Auswirkungen davon im Browser.

Die Unix-Philosophie ermutigt uns, kleine Mikrobibliotheken zu schreiben, die eine Sache tun und das gut. Das Node.js-Ökosystem hat dies in Hülle und Fülle getan. Das funktioniert gut auf dem Server, wo der Import einer kleinen Datei sehr geringe Kosten verursacht. Auf dem Client hat dies jedoch enorme Kosten. Also bauen wir Prozesse und Tools, um diese 46.000 Skripte zusammenzubündeln. Aber das verschleiert das Endprodukt. Es ist nicht ungewöhnlich, dass eine Website `fetch`, `axios` und `bluebird` gleichzeitig und das gesamte `lodash` verwendet, nur um eine `forEach`-Schleife zu schreiben.

In einer Welt, in der man „npm install die Probleme lösen lassen“, fühlt es sich an, als würden wir weniger programmieren und mehr Dinge konfigurieren, die wir aus dem Internet installiert haben. Da Abhängigkeiten in ihren Funktionen wachsen und flexibler werden, erlauben sie uns, einige der Optionsflags zu konfigurieren. Als Einzelfall sind Konfigurationen eine großartige Funktion. Aber kumulativ kann ich selbst bei einem „einfachen“ Projekt eine halbes Dutzend Konfigurationsdateien verwalten und darüber streiten. Eines Tages, als ich in einem Meer von JSON-Konfigurationen schwamm, dämmerte es mir: Ich mag keine Konfiguration.

„Konvention vor Konfiguration“ war eine Reihe von Idealen, die von David Heinemeier Hansson (@DHH) popularisiert wurden und viele der Designentscheidungen von Ruby on Rails leiteten. Obwohl die Aussage etwas an Popularität verloren hat, denke ich, dass sie die Art von Entwicklung zusammenfasst, die ich mag, insbesondere wenn Frameworks beteiligt sind. Frameworks sollten versuchen, eine Sammlung von Best Practices zu sein, um anderen zu ersparen, über Entscheidungen nachdenken zu müssen. Ich habe es schon einmal gesagt, aber ich denke, Nuxt macht das wirklich gut. Wenn ich in ein System von vordefinierten Konventionen und geringfügiger Konfiguration eintauche, bin ich viel glücklicher als im gegenteiligen System ohne Konventionen und viel Konfiguration.

Es ist ein wenig seltsam, 40 zu werden und so viel über den Job zu erfahren, den ich täglich mache. Aber es ist schön, Vokabeln und Prinzipien für das gefunden zu haben, was mir an Entwicklung gefällt. Ihre Liste der Dinge, die Ihnen gefallen, mag anders sein als meine, und das ist gut so. Ich würde gerne mehr darüber erfahren, welche Art von Entwicklung Ihnen gefällt. Was bauen Sie gerne? Was optimieren Sie? Was ist Ihre Definition von Erfolg?