Interview mit Crank.js-Entwickler Brian Kim

„Crank.js benutzt alle 4 Syntax-Varianten für JavaScript-Funktionen, um Benutzer in die Lage zu versetzen, stärker deklarativen Code zu schreiben.“
Keine Kommentare

Mit Crank.js erweitert sich das JavaScript-Ökosystem um ein weiteres Framework. Konzipiert wurde es für die Erstellung von JSX-basierten Promises, außerdem bringt es eine eigene Syntax für Komponenten mit. Wir haben mit Entwickler Brian Kim über das Framework, dessen Nutzen und Erwartungen für die Zukunft gesprochen.

Entwickler: Hallo Brian und danke, dass du dir die Zeit für dieses Interview genommen hast. Mit Crank.js hast du ein weiteres JavaScript-Framework entwickelt. Wie kam es dazu?

Brian Kim: Das Erstellen eines eigenen JavaScript-Frameworks erfordert zu gleichen Teilen Hartnäckigkeit und Wahnsinn, weil man im Grunde sagt: „Alle Leute, die Apps programmieren, sollen das auf meine Art machen.“ Das ist eine großspurige Aussage. Deshalb habe ich die Aufgabe nicht auf die leichte Schulter genommen und die Entwicklung eines Frameworks als einen letzten Ausweg betrachtet. Kurz gesagt, fühlte ich mich gezwungen, ein Framework zu schreiben, weil ich bis zu diesem Zeitpunkt React mit Freude genutzt habe, aber zunehmend über die neuesten APIs frustriert war, die mir immer mehr die Möglichkeiten nahmen, über Komponenten nachzudenken. Ich wusste, dass ich weiterhin JSX verwenden wollte, und ich hatte viel mit Generators und Async Generators experimentiert. Da wurde mir plötzlich bewusst, dass ich Stateful Components mit Generators schreiben konnte. Dieser Idee folgte ich dann bis zu ihrem logischen Ende.

Entwickler: Welche Art von Projekten würden von Crank.js anstelle von React profitieren?

Kim: Neu gestartete Projekte! Wer etwas Neues beginnen und die Zukunft von Crank mitgestalten möchte, ist dazu herzlich eingeladen. Es gibt genug Unterschiede zu React, so dass ich nicht glaube, dass man eine in Produktion befindliche React-Anwendung einfach nach Crank konvertieren könnte. Aber ich bin gespannt ob es dafür in Zukunft Codemod-Lösungen gibt. Eine Sache, vor der ich die React-Entwickler allerdings warnen möchte: Ich habe bemerkt, dass die React-Entwickler immer mehr Logik in Hooks stecken. Dies ist eine extreme Form der Herstellerbindung in dem Sinne, dass Hooks außerhalb von React nicht aufgerufen werden können. Je mehr Hooks man verwendet, desto schwieriger wird es, in Zukunft zu migrieren.

Entwickler: Du sagst insbesondere, dass das Suspense API in React ein ausschlaggebender Punkt für dich war. Was war es, was dir daran nicht gefallen hat?

Kim: Es gab ein paar Dinge, die mir an Suspense nicht gefallen haben:

  1. Der Mechanismus: Suspense erfordert, dass Komponenten auf die gleiche Weise Promises werfen, wie sie Fehler werfen, um Asynchronität anzuzeigen. Ich weiß, dass sich das ändern könnte, aber das Team von React und die Library-Entwickler nehmen derzeit an, dass es so funktionieren wird. Ich glaube nicht, dass es sich um einen soliden Mechanismus handelt, denn es bedeutet, dass alle asynchronen Aufrufe Caching erfordern, was die Arbeit damit schwierig machen kann. Cache-Invalidierung ist eines der beiden großen Probleme der Informatik, und die Leute zu bitten, einen Cache für alle ihre Async-Calls zu haben, scheint mir eine große Bitte zu sein und eröffnet Entwicklern eine ganze Klasse von veralteten Cache-Fehlern.
  2. async/await-Syntax: Als ich endlich async-Komponenten zum Laufen bekam, war ich überrascht, wie natürlich sich das anfühlte, während die React-Entwickler ständig sagten, dass virtuelles DOM und Promises nicht zusammen passen. Jeden Tag, wenn Anfänger React lernen, ist eine ihrer großen Fragen: Wie verwende ich die async/await-Syntax? Es gibt keine gute Antwort, weil es fast so aussieht, als würde React sich die Verwendung von async/await schwer machen. Zum Beispiel erfordert der useEffect-Hook, dass der Callback eine Funktion zurückgibt, sodass man den Callback nicht asynchron machen kann.

Entwickler: Was hast du mit Crank hinsichtlich der Anwendungsfälle, die in React vom Suspense API abgedeckt werden, anders gemacht?

Kim: In Crank ist das Suspense API dank der asynchronen Generator Functions vollständig im Benutzerbereich implementierbar. Im Wesentlichen kann derselbe diffing-Algorithmus aus dem virtuellen DOM verwendet werden, um Komponenten gegeneinander laufen zu lassen, wodurch das Problem der Fallback States behoben wird. Hier sehen wir ein Beispiel, wie die Suspense-Komponente in Crank implementieren werden würden:

 async function Fallback({timeout = 1000, children}) {
  await new Promise((resolve) => setTimeout(resolve, timeout));
  return children;
}

async function *Suspense({timeout, fallback, children}) {
  for await ({timeout, fallback, children} of this) {
    yield <Fallback timeout={timeout}>{fallback}</Fallback>;
    yield <Fragment>{children}</Fragment>;
  }
}

(async () => {
  await renderer.render(
    <Suspense fallback={<Spinner />}>
      <ProfilePage />
    </Suspense>,
    document.body,
  );
})();

Entwickler: In der Einführung von Crank.js ist zu lesen, dass du denkst, eine neue Art der Entwicklung von Komponenten geschaffen zu haben. Wie unterscheiden sich deine Komponenten von anderen Konzepten?

Kim: Die große Idee ist, dass React nur synchrone Funktionen verwendet, um Komponenten zu modellieren. Javascript hat jedoch vier fundamentale Funktionssyntaxen (function, async-function, function * und async-funktion *), und Crank benutzt sie alle, um Benutzer in die Lage zu versetzen, stärker deklarativen Code zu schreiben. Ich glaube, einige Leute hatten diesen Dogmatismus im Kopf, dass React UIs pure Funktionen sein müsse. Ich glaube jedoch, was wir die ganze Zeit wirklich wollten, war, einfach die Funktionssyntax zu verwenden. Die Nutzung all der verschiedenen Funktionssyntaxen erweitert die Vorstellung davon, was eine Komponente sein kann.

Entwickler: Kannst du uns ein Beispiel dafür geben, wie eine Stateful-Komponente in Crank.js aussehen würde?

Kim: Der gesamte Zustand in Crank ist von Generator Components umgeben:

function *Timer() {
  let seconds = 0;
  const interval = setInterval(() => {
    seconds++;
    this.refresh();
  }, 1000);

  try {
    while (true) {
      yield (
        <div>Seconds elapsed: {seconds}</div>
      );
    }
  } finally {
    clearInterval(interval);
  }
} 

Anstatt JSX-Ausdrücke zurückzugeben, werden sie freigesetzt- Das bedeutet, dass der natürliche interne Zustand des Generators, der eigentlich nur sein variabler Scope ist, zwischen den Render-Durchläufen erhalten bleibt. Das heißt, dass der Zustand nur ein Variable Scope ist. Die Einfachheit dieser Idee kann nicht überbewertet werden. Alle separaten Konzepte von React wie Props, State und Refs können frei gemischt werden, was für einen Entwickler wirklich befreiend ist.

International JavaScript Conference

Effective Microservices Architecture In Node.js

by Tamar Stern (Palto Alto Networks)

React Components And How To Style Them

by Jemima Abu (Telesoftas)

Angular Camp 2020

Als Online- oder Präsenztraining!

Das 360°-Intensivtraining mit Angular-Koryphäe Manfred Steyer
Präsentiert von Entwickler Akademie

Entwickler: Welche Technologien hast du für die Erstellung des Frameworks verwendet? Gibt es irgendwelche Dependencies, die Entwickler für die Verwendung von Crank in ihren Projekten benötigen?

Kim: Crank besitzt eine Abhängigkeit von event-target-shim, die ich irgendwann überarbeiten möchte und bereits mit Rollup gebündelt habe. Das Einzige, was die Entwickler brauchen, ist eine moderne JavaScript-Umgebung mit Promises, Generators und Async Generators. Sobald man das hat, ist alles bereit.

Entwickler: Welches Feature würdest du Crank.js in Zukunft gerne hinzufügen?

Kim: Ich würde gerne sehen, wie man mit Web Components arbeiten kann! Es wäre schön, Crank irgendwie zu eigenständigen Web Components „kompilieren“ zu können, so dass man sie in Anwendungen integrieren kann, ohne Crank zu kennen oder sich um Crank kümmern zu müssen.

Doch neben der Einbeziehung von Community-Feedback und Leistungsverbesserungen möchte ich den Umfang des Kern-APIs wirklich einschränken. Mein Traum ist es, Crank so einfach und grundlegend zu machen, dass ein erfahrener JavaScript-Entwickler, der nur mit einem Laptop (und einer Stromquelle) auf einer einsamen Insel festsitzt, Crank von Grund auf neu erstellen kann, weil die Algorithmen, die Crank verwendet, so logisch für ihn sind.

Entwickler: Vielen Dank für das Interview.

Brian Kim ist der Entwickler von Crank und ein unabhängiger JavaScript-Entwickler mit Sitz in NJ, USA.
Crank.js kann im GitHub-Repository und auf der Website zum Framework gefunden werden.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -