So vermeiden Sie, dass Frontend-Technologie uns verärgert

Es wird viel darüber geschrieben, wie verwirrend und überwältigend das Frontend geworden ist (eine Übersicht finden Sie unter „JavaScript Frameworks – Auf dem Weg ins Jahr 2025“), und ich glaube, dass dies viel mit den Anreizen dafür zu tun hat verschiedene Parteien, und ich diskutiere, was nötig ist, um eine bestehende Lücke zu schließen und ein gesünderes Ökosystem zu schaffen.

Die Realität für einen Entwickler

Wenn ein Frontend-Entwickler verschiedene Technologien in Betracht zieht, muss er eine Möglichkeit finden, die Stakeholder (sowohl Geschäftsleute als auch ihre Entwicklerkollegen) zu überzeugen, und der einzige Weg, dies zu erreichen, besteht darin, Dinge zu erstellen und zu messen und so die Vorteile zu beweisen die Erwartungen verwalten. (Der Treiber könnte die Notwendigkeit sein, etwas völlig Neues zu bauen, etwas bereits Bestehendes zu verbessern oder vielleicht einfach nur zu beweisen, dass keine Änderung notwendig ist und kein Nutzen durch eine Alternative erzielt werden kann, wenn beispielsweise externe Parteien beteiligt sind üben Druck auf das Unternehmen aus, darüber nachzudenken.)

Ein Beispiel könnte ein Entwickler sein, der die Verwendung weiterer React Server-Komponenten in Betracht zieht (der Fokus liegt nicht auf RSC selbst, sondern es kann sich genauso gut um etwas anderes, ein anderes Framework oder eine andere Technologie handeln). Sie müssen ihre Architektur anpassen, um einen Server einzubeziehen, neue Programmiermuster übernehmen, über die Dateiorganisation mit diesen neuen Routern und Anweisungen nachdenken, über die Einschränkungen all dessen nachdenken, die Leute über all das aufklären, sich an internen Best Practices und Bedürfnissen ausrichten, Sprechen Sie mit Kunden und aktualisieren Sie SLAs und Dokumentationen, ... Das alles ist sehr kostspielig und riskant, daher darf eine Entscheidung nicht leichtfertig getroffen werden.

(Dieser anstrengende und sehr kostspielige Prozess des Vergleichs verschiedener Technologien und der Durchführung von Architekturmigrationen ist etwas, das ein großer Teil der Teams auf der ganzen Welt durchläuft. Denken Sie nur daran, wie viele Blog-Beiträge und Videos es über gescheiterte Versprechen eines gab Stück Technik (Sie brauchen Next.js nicht – Warum wir als eines der neuesten von Next zu React migriert sind).)

Der Entwickler stellt jedoch sehr schnell zu Beginn der Entwicklung von POCs fest, dass viele Technologieangebote mit dem Argument „Vertrauen Sie uns, Bruder“ beworben werden.

Jedes neue Stück Technologie, das aus der Rahmenküche kommt, erzählt eine Geschichte großartiger Verbesserungen, die in recht plastischen Demos demonstriert werden. Aber die Realität ist oft weitaus chaotischer, die Vorteile marginal und dennoch sind Experimente und Migration sehr kostspielig. Die Herausforderung besteht für jedes Unternehmen und jedes Team darin, das Rad neu zu erfinden und Wege zu finden, um zu beweisen, dass es tatsächlich einen gewissen Nutzen für ihren speziellen Fall gibt. Um verschiedene Optionen ganzheitlich und umfassend zu prüfen und zu testen, sind enorme Ressourcen und internes Fachwissen erforderlich.

Die gesunde Dynamik des Frontend-Ökosystems gerät in Gefahr, wenn ein Unternehmen, das die Yet Another™-Funktion als „The Now Best Thing Ever™“ anpreist, wie aus der Aussage „Trust Me Bro™“ hervorgeht, den Entwickler dazu bringt, sich daran zu beteiligen und die Funktion einzuführen Ich bemühe mich, dorthin zu migrieren, und muss dann feststellen, dass schwierige Probleme tatsächlich schwer zu lösen sind und der ROI nicht da ist. Wenn man sich auf diese Weise zu oft verbrennt, führt das mit der Zeit zu Groll, Burnout und einer allgemeinen Abneigung gegenüber zukünftigen Risiken.

Die Unternehmen, die diese coolen neuen Technologien entwickeln (und die können wirklich cool sein!), sind überrascht, dass die Leute Ressentiments verspüren und scheinbar rücksichtslos gegenüber dem Arbeitsaufwand wirken, den diese Art von Bemühungen erfordern, und der Unzugänglichkeit überprüfbarer Methoden zur Aussage was die realistischen Erwartungen sein könnten. Es kann alles, nun ja, unehrlich aussehen.

Die Erkenntnis ist, dass die Unternehmen, die diese neuen Technologien entwickeln, die Verantwortung tragen, zu beweisen, dass ihre Technologie funktioniert, und zwar nicht nur durch Werbung, sondern auch dadurch, dass sie den Entwicklern Tools zur Verfügung stellen, die sie bei ihren Entscheidungen unterstützen und die Vorteile für sich selbst bestätigen .

Die Werkzeuge

Wie sehen diese Tools eigentlich aus?

Die Tools würden kontinuierlich über die Kennzahlen berichten, die den Entwicklern wichtig sind (die objektiv gemessen werden können), ganzheitlich kombiniert und mit den Änderungen korreliert, die Entwickler vornehmen, um ihnen zu helfen, die Kompromisse zu verstehen:

• Bundle-Größen (umfassende Berichte zu pro Seite und geteilten Bundles, Einblicke in zusätzliche Bundles, die langsam (bei Interaktionen) und/oder automatisch (Servicemitarbeiter, Vorladen und andere Aufwärmvorgänge) geladen werden)
• Metriken über das Netzwerk (bei mehr Serialisierung ist es gut zu wissen, wie hoch die tatsächlichen Einsparungen auf dem Client sind und wie sich dies auf die Kommunikation zwischen dem Server und dem Client auswirkt)
• Zeitaufteilungen und Leistung (die sowohl Server als auch Client umfassen, z. B. wie lange es dauert, Inhalte zu rendern und wie viel davon auf dem Server im Vergleich zum Client ist, die Netzwerklatenz und -übertragung usw.)
• Web-Vitals (brauchen wir detailliertere Aufteilungen für verschiedene Teile von Webseiten, die sowohl progressiv geladen als auch gerendert werden? Ist es mehr ausreichend, einmalige Metriken nur für den anfänglichen Ladevorgang zu haben?)
• Trends (im Laufe der Zeit) und Korrelationen zwischen all diesen verschiedenen Metriken auf der Ebene eines gesamten Projekts (damit ein Team den Überblick über den Fortschritt der Dinge behalten und unangenehme Überraschungen durch Leistungseinbußen im Laufe der Zeit oder die Einführung eines Grenzfalls vermeiden kann). nur an einigen Stellen und auf einigen Seiten)

Bei den hier erwähnten Dingen handelt es sich um dieselben wenigen Dinge, die jedes Team interessieren würde, doch die Tools, um zu solchen Erkenntnissen zu gelangen, scheinen schwierig und umständlich einzurichten und manchmal praktisch unmöglich zu sein, wenn es um Frameworks geht, die sich wie ein Schwarzer verhalten Box.

Anreize

Diese Art von Werkzeugen muss nicht unbedingt von denselben Unternehmen bereitgestellt werden, die diese neuen Technologien selbst entwickeln, sondern könnte auch von einem anderen Unternehmen gebaut werden (möglicherweise gibt es bereits Hinweise auf ähnliche Überlegungen? Evan You – Vue, Vite, VoidZero und die Zukunft der JavaScript-Tools, oder ich interpretiere Evan möglicherweise falsch. Ich glaube jedoch, dass dasselbe Unternehmen, das neue Technologien entwickelt, dasjenige sein sollte, das auch die Werkzeuge zur Überprüfung seiner Vorteile bereitstellt, weil die Anreize auf seiner Seite sind:

Durch den Aufbau eines solchen Tools, das transparent über verschiedene Metriken und Unterschiede zwischen verschiedenen Implementierungen berichtet, kann ein Unternehmen, das eine neue Technologie/ein neues Framework entwickelt, zunächst intern den Fortschritt und die Ansprüche überprüfen und sich dabei helfen, die Kompromisse zu verstehen und diese dann zu optimieren richtige Kennzahlen. Auf diese Weise bleibt das Unternehmen rechenschaftspflichtig und ehrlich. So kann die gesamte Verbesserungs-Feedbackschleife intern stattfinden, lange bevor sie überhaupt die Öffentlichkeit erreicht.

Indem das Unternehmen dieselben Tools dann auch der Öffentlichkeit zur Verfügung stellt, kann es das Risiko falscher Behauptungen und Enttäuschungen vermeiden und stattdessen jedem die Möglichkeit bieten, die Dinge bei seinen eigenen Projekten einfach selbst zu überprüfen. Das würde wiederum noch mehr Vertrauen und Dankbarkeit erzeugen.

Das Unternehmen, das die Technologie entwickelt, ist auch am besten in der Lage, die Werkzeuge dafür zu entwickeln – es versteht seine APIs und Fähigkeiten am besten und weiß, wie viel oder wie wenig davon geöffnet werden muss, damit die Werkzeuge funktionieren (das ist eine andere Möglichkeit). um das Unternehmen ehrlich und fair zu halten).

Letztendlich könnte das Unternehmen dies tun, wenn es sein Geschäftsmodell erweitern möchte, indem es diese Werkzeuge kostenpflichtig macht. (Derzeit manifestiert sich ein ähnlicher Ansatz in der Regel durch Vertragsabschlüsse und die direkte Zusammenarbeit mit Kundenunternehmen. Durch die Bereitstellung von Werkzeugen könnte das Ganze jedoch weitaus eigennütziger werden, was allen Parteien zugute kommen könnte.)

Abschluss

Wir befinden uns in einer Zeit konkurrierender Technologien, in der es keine einzige beste Lösung gibt und Architekturmigrationen bei immer größeren Projekten nicht billig sind. Um eine intelligente Entscheidungsfindung und Vorgehensweise zu ermöglichen, sind umfassendere Tools und Berichte erforderlich, die Entscheidungen, Änderungen und Kompromisse kontinuierlich leiten und bewerten und nicht erst dann Bericht erstatten, wenn alles erledigt ist.

Die Unternehmen, die diese neuen Technologien und Frameworks entwickeln, würden am meisten von solchen Werkzeugen profitieren und sind am besten in der Lage, sie zu entwickeln.

Das obige ist der detaillierte Inhalt vonSo vermeiden Sie, dass Frontend-Technologie uns verärgert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!