Der Descriptor überlebte, const nicht — Full-Stack-Rust

Begleitbeitrag zu Topcoat und die schrumpfenden Kosten von Full-Stack-Rust. Jener Beitrag war aus der Ankündigung geschrieben und versprach einen Folgebeitrag darüber, wo die rauen Kanten tatsächlich sichtbar werden. Hier ist er, vier Wochen später: ein kleines Admin-Panel auf Topcoat 0.6.2 und Toasty 0.10.0 und die vier Fragen, zu deren Beantwortung sich jener Beitrag verpflichtet hat. Der Pilotversuch ist Open Source — ein frischer Clone startet beide Screens und den Test, der die Frage entscheidet.

Ein Skelett, viele Screens argumentierte, dass Admin-Screens als typisierte Daten deklariert und nicht ausprogrammiert werden sollten, und schloss mit der Behauptung, die Idee sei unabhängig vom Stack:

Ziehen Sie die Grenze als Einweg-Abhängigkeit — Domänen hängen nach innen von einem Framework ab, das nichts über sie weiß — und validieren Sie sie mit einem Zero-Diff-Refactor eines Screens, dem Sie bereits vertrauen.

Das war React und TypeScript. Hier läuft dieselbe Behauptung noch einmal in Rust, wo ein Descriptor eine Compile-Zeit-Konstante sein kann und ein Template ein Makro ist. Weil das erste Ergebnis bereits veröffentlicht ist, ist der zweite Stack eine Replikation mit Kontrollgruppe und keine frische Meinung — selten genug, um es ordentlich zu machen.

Diese Formulierung, Compile-Zeit-Konstante, ist der Ursprung des Titels, deshalb sei jetzt gesagt, was sie einbringt und warum ich sie wollte. Ein TypeScript-Descriptor ist ein Array von Objekten, das beim Laden des Moduls entsteht. Ein Rust-Descriptor kann mehr sein: &'static, Copy, niemals alloziert, vollständig geprüft, bevor das Programm startet. Beim Einstieg sah das für mich nach derselben Idee in strengerer Form aus — wenn es gut ist, einen Screen als Daten zu deklarieren, dann muss es noch besser sein, ihn als Daten zu deklarieren, die der Compiler durchschauen und prüfen kann. Ich habe diese Eigenschaft als das Schützenswerte behandelt, und der Pilotversuch war zum Teil ein Test, ob sie es sein kann.

Der Stack ist bewusst ein junger. Topcoat ist sechs Wochen alt: Das Tokio-Team hat es am 22. Juli 2026 angekündigt, der Pilotversuch pinnt 0.6.2, und das Projekt erwartet weiterhin Breaking Changes. Es ist nicht das einzige Full-Stack-Rust-Framework — Leptos und Dioxus machen das seit Jahren —, aber es ist das einzige unter ihnen, das die Frage ohne WebAssembly beantwortet: serverseitig gerendert als Standard, mit einer reaktiven Schicht außerhalb eines Wasm-Bundles. Genau damit hat niemand jahrelange Erfahrung, und genau das ist einen Test wert.

Es kam anders heraus, und nicht in der Richtung, die ich erwartet hatte.

Die einzigen Daten in diesem Beitrag sind Metadaten

Hier gibt es kein Warehouse und keine Pipeline. Es gibt eine Rechnungstabelle mit einem Dutzend erfundener Zeilen, und diese Zeilen sind nicht die Daten, auf die es ankommt. Worauf es ankommt, ist der Descriptor — die kleine typisierte Deklaration, die sagt, dass ein Rechnungs-Screen diese Spalten hat, aus diesen Feldern gelesen und auf diese Weise dargestellt. Das sind Metadaten im schlichtesten Sinn: Sie beschreiben etwas anderes, sie werden getrennt von dem versioniert, was sie beschreiben, und sie werden für sich genommen reviewt.

Und das ist die Form der übrigen Arbeit von Cordata. Eine Pipeline ist ein Descriptor, kein Programm führt eine Domäne weiter dasselbe Argument — packt man Quelle, Schritte, Ziel, Contract und Policy in eine versionierte Deklaration, wird das Anbinden einer neuen Quelle zur Konfigurationsänderung statt zum Release. Ein Lineage-Event, ein Data Contract, eine Aufbewahrungsregel: immer dieselbe Bewegung, bei der etwas über den Code Verschmiertes zu einem Dokument wird, das man diffen, reviewen und ablehnen kann.

Metadaten lohnen den Aufwand aus einem Grund, der nicht Dokumentation heißt. Sie sind eine Einschränkung. Ein Descriptor ist das wert, was er einer Domäne verbietet — die Pipeline, die ohne deklarierten Contract nicht schreiben kann, der Screen, der keine Spalte rendern kann, die er nie deklariert hat. In diesem Pilotversuch ist diese Einschränkung ein Typ, was sie zu etwas anderem als einer Empfehlung macht: Der Descriptor ist das gesamte Vokabular, das einem Screen erlaubt ist, und eine Domäne, die etwas braucht, das dieses Vokabular nicht hat, kann sich nicht still daran vorbeimogeln. Sie bekommt einen Compile-Fehler, und jemand muss entscheiden, was das Vokabular stattdessen sagen soll. Alles, was unten berichtet wird, entstand daraus, gegen diese Grenze zu drücken, bis sie antwortete.

Jede Metadaten-Schicht trifft irgendwann auf denselben Test, ganz gleich, was sie beschreibt. Die Deklaration deckt die gewöhnlichen Fälle bequem ab. Dann taucht ein Fall auf, für den sie kein Vokabular hat, und es gibt zwei Auswege.

Der erste ist ein Notausgang: ein einzelnes Feld, das beliebigen Code oder Text annimmt — ein raw_sql-String an einem Pipeline-Schritt, ein render-Callback an einer Spalte, ein Freitext-notes-Blob an einem Contract. Das geht schnell und löst nicht nur den heutigen Fall, sondern auch jeden künftigen, und genau das ist das Problem. Nichts außerhalb der Domäne kann lesen, was in diesem Feld landet, also beschreibt die Deklaration von dem Tag an, an dem es existiert, nicht mehr das System, sondern nur noch die Teile, für die niemand eine Ausnahme brauchte. Die Schicht sieht in der Typsignatur weiterhin nach einer Einschränkung aus, wirkt aber nicht mehr als eine.

Der zweite Ausweg ist langsamer: den neuen Fall benennen und ins Vokabular aufnehmen. Ein deklarierter Link-Zellentyp statt eines Render-Callbacks. Ein deklarierter Join-Schritt statt eines SQL-Strings. Die Kosten sind real — das Framework muss sich jedes Mal ändern, wenn eine Domäne etwas wirklich Neues braucht, und diese Änderung reviewt, wem das Framework gehört, nicht wer das Feature wollte. Erkauft wird damit, dass die Deklaration weiterhin sagt, was das System tut, und weiterhin ablehnt, was es nicht tun soll.

Wonach eine Schicht greift, ist die einzige Frage zu ihr, auf die es wirklich ankommt, und sie wird normalerweise erst nach Jahren beantwortet, an einem System, das viel zu groß ist, um es zu beobachten.

Zwei Admin-Screens sind klein genug, um sie zu beobachten. Dies ist also an der Oberfläche ein Beitrag über ein Rust-Web-Framework und darunter ein Beitrag über Metadaten — und wenn Sie nie eine Zeile Rust schreiben, ist die zweite Hälfte diejenige, die trotzdem für Sie gilt, weil dieselbe Frage in jeder Deklarationsschicht wartet, die Ihnen gehört.

Das Experiment

Der Pilotversuch hat zwei Screens, ausgewählt so, dass sie beiderseits der Grenze liegen. Jeder ist ein eigenes Modul — users.rs und invoices.rs —, und diese beiden Module sind das, was dieser Beitrag mit den Domänen meint: der Code, der weiß, was ein Benutzer oder eine Rechnung ist. Ihnen gegenüber steht das Framework: descriptor.rs, das festlegt, was eine Beschreibung sagen darf, und table.rs, das eine solche rendert. Das Framework weiß weder von Benutzern noch von Rechnungen, und im gesamten Experiment geht es darum, was von einer Domäne dorthin gelangen kann.

Der erste Screen, users, listet Name, E-Mail, Sitze, Beitritt und Status — alles schlichte Werte, jeder davon abgedeckt von den Zellentypen, die das Framework bereits mitbringt. Der zweite, invoices, wurde zuerst von Hand geschrieben und bewusst schwerer gemacht; er trägt drei Dinge, die der Descriptor nicht ausdrücken konnte:

1. Umgebungskontext — ein Geldbetrag, formatiert für eine Locale, die aus dem Request kommt und nicht aus der Zeile: 4.850,00 € auf Deutsch, $4,850.00 auf Englisch
2. ein abgeleiteter Wert — eine Spalte, die aus zwei Feldern berechnet statt aus einem gelesen wird
3. Struktur — eine Zelle, die als Link statt als Text gerendert wird

Diese drei Bezeichnungen werden im weiteren Beitrag verwendet, und die dritte lohnt jetzt eine genaue Festlegung, weil das Ergebnis an ihr hängt. Ein Descriptor dieser Bauart beantwortet pro Spalte eine Frage: Welchen String zeigt diese Zelle, wenn man ihr eine Zeile gibt? Ein abgeleiteter Wert ist immer noch eine Antwort darauf — berechnen Sie, was Sie wollen, geben Sie einen String zurück. Ein Link ist überhaupt keine Antwort darauf, denn ein Link ist eine andere Form der Ausgabe: ein <a>-Element, das den Text umschließt und einen zweiten Wert trägt, das Ziel, für das es in einer Beschreibung, die nur "String" sagen kann, keinen Platz gibt. Struktur bedeutet hier also nicht, was eine Zelle enthält, sondern welcher Art die Zelle ist.

Screen eins existiert, damit man ihm vertraut und Screen zwei gegen ihn refactored werden kann — und dieses Wort, refactored, trägt die gesamte Methode, deshalb lohnt Genauigkeit darüber, was es hier heißt.

invoices wurde zuerst auf gewöhnlichem Weg geschrieben: eigenes Markup, eigene Schleife über die Zeilen, eigene Formatierung, niemandem verpflichtet außer sich selbst. Refactoring heißt hier, all das zu löschen und den Screen als Descriptor neu zu bauen, der derselben geteilten Tabellen-Komponente übergeben wird, die users bereits nutzt — dieselbe generische Komponente, ohne einen rechnungsförmigen Sonderfall darin. Der Code des Screens ändert sich vollständig, während sich das, was der Browser bekommt, überhaupt nicht ändern darf.

Die Reihenfolge ist wichtiger, als sie aussieht. Werden beide Screens von Anfang an durch die Abstraktion geschrieben, darf die Abstraktion entscheiden, wie richtig aussieht, und der Test kann nur sich selbst zustimmen. invoices zuerst von Hand zu schreiben erzeugt eine Kontrollgruppe: ein Screen, gebaut von jemandem, der das echte Problem löst und alles tun darf, was dieses Problem verlangt — einschließlich der drei Dinge oben, für die der Descriptor kein Vokabular hatte. Ihn danach zu refactoren stellt eine Frage, die wirklich mit Nein beantwortet werden kann. Kann die Abstraktion Byte für Byte einen Screen reproduzieren, der nie dafür entworfen wurde, zu ihr zu passen?

Das Diagramm in Worten: Beide Domänen reichen Beschreibungen nach innen an eine Tabellen-Komponente, die keinen Domänentyp benennt, und nichts zeigt zurück nach außen. Von den drei gegen diese Grenze getesteten Dingen kamen Werte unverändert durch, Struktur verlangte eine Änderung auf der Framework-Seite, und Umgebungskontext kam überhaupt nicht durch, solange der Accessor ein einfacher Funktionszeiger blieb.

Weil Topcoat auf dem Server rendert, hört die Zero-Diff-Behauptung auf, ein visuelles Urteil zu sein, und wird zu einem Textvergleich. Das Prüfskript nimmt vor einem Refactoring das HTML jeder Route auf und diffed es danach, was die ganze Frage auf bestanden oder durchgefallen reduziert: Entweder diff gibt nichts aus, oder die Abstraktion hat verändert, was der Nutzer sieht, und ist damit falsch.

Das Prüfskript lieferte einen Fehlalarm, bevor ich ihm vertraute. Eine Spaltenüberschrift zu verfälschen erzeugte den Fehler, den sie erzeugen sollte. Diese Änderung mit mv zurückzunehmen erzeugte den Fehler erneut — weil mv die ursprüngliche Änderungszeit wiederherstellt und die Quelle damit älter als das kompilierte Binary bleibt, sodass cargo den Rebuild übersprang und der Server weiter den vorherigen Build auslieferte. Nirgendwo meldete etwas einen übersprungenen Schritt. Das Skript erzwingt nun bei jedem Lauf aktuelle Quellen, was 1,4 Sekunden kostet und die ganze Fehlerkategorie beseitigt.

Das ist dieselbe Form wie die fünf Fallen im trace_id-Beitrag: eine Prüfung, die zuversichtlich falsch liegt, weil weiter oben still etwas nicht passiert ist. Weisen Sie nach, dass Ihr Test unterscheidet, bevor Sie ihm glauben.

Ergebnis eins: Die Grenze hielt für Werte und brach bei Struktur

Erstes Refactoring, ohne etwas am Framework zu ändern:

ZERO DIFF  users
CHANGED    invoices   — eine Spalte

Fünf der sechs Spalten wurden Byte für Byte reproduziert, darunter beide, von denen ich einen Bruch erwartet hatte. Die berechnete Spalte überstand es glatt. Der lokalisierte Geldbetrag überstand es ebenfalls, wobei der nächste Abschnitt erklärt, warum das ein Zufall der Testdaten war und kein Ergebnis.

Genau eine Spalte fiel durch:

- <td class="cell cell-text"><a href="/invoices/2026-0041">2026-0041</a></td>
+ <td class="cell cell-text">&lt;a href="/invoices/2026-0041"&gt;2026-0041&lt;/a&gt;</td>

Der Typ des Accessors war fn(&T) -> String, und view! escaped einen interpolierten String. Das ist korrektes Verhalten — es ist der Schutz gegen Cross-Site-Scripting — und kein Bug, um den man herumbauen sollte.

Also: Ein Accessor, der einen String zurückgibt, kann jede Zelle ausdrücken, die ein Wert ist, und keine Zelle, die Struktur ist. Er kann alles Beliebige aus der Zeile berechnen, und er kann nichts in die Zelle verschachteln, die er zurückgibt.

Jede Spalte in einem Descriptor trägt zwei Dinge: einen Accessor, der sagt, was gezeigt wird, und eine Zellenart, die sagt, wie gerendert wird. Die Zellenart ist ein Enum, und dieses Enum ist das gesamte Vokabular des Frameworks an Zellenformen — eine Domäne darf daraus wählen und es nicht erweitern, was der Einschränkung von weiter oben entspricht, ausgedrückt als Typ:

pub enum CellKind<T: 'static> {
    Text,
    Number,
    Date,
    Badge,
    Link { href: Accessor<T> }, // aus diesem Ergebnis
}

Die Link-Spalte zu reparieren hieß also, diese Link-Variante hinzuzufügen, dazu ein if let im Template der Tabellen-Komponente — die einzige Stelle, die entscheidet, ob der Text einer Zelle blank ins <td> geht oder in einen Anker gewickelt:

if let CellKind::Link { href } = &col.kind {
    <a href=(href(row))>((col.get)(row))</a>
} else {
    ((col.get)(row))
}

Beide Änderungen liegen auf der Framework-Seite, und die Variante trägt etwas Bemerkenswertes: einen zweiten Accessor für das Ziel, also genau den Wert, für den es keinen Platz gab, solange eine Spalte nur einen String erzeugen konnte. Die Domänen änderten sich nicht, und die Tabellen-Komponente benennt weiterhin keinen Domänentyp — sie hat eine Form gelernt, kein Thema.

Das kehrt das React-Ergebnis um, und das ist das Erste, was zu übernehmen lohnt. Dort hielt eine Spaltendefinition eine Render-Funktion, sodass jede Domäne beliebiges Markup zurückgeben konnte, was flexibler ist und überhaupt keine Grenze. Die Rust-Variante hat die strengere Grenze, und der Preis ist, dass eine wirklich neue Darstellung eine bewusste, einzelne, frameworkweite Entscheidung kostet.

Ergebnis zwei: Die Locale brach das, was ich für den Kern hielt

Die Geldspalte überstand das erste Refactoring nur, weil im Währungsformatierer die Locale fest verdrahtet war, wodurch die Closure nichts einfangen musste und sich zu einem einfachen Funktionszeiger verflachen ließ. In dem Moment, in dem die Locale eine echte wurde, musste der Accessor sie einfangen, und ein Funktionszeiger kann das nicht.

Wo die Locale gespeichert wird, stellt sich als unerheblich heraus, was erwähnenswert ist, weil der naheliegende Einwand lautet, eine Locale sei Daten wie alles andere. Auf dieser Website ist sie ein Routen-Segment, /en/… und /de/…. Sie könnte ebenso gut ein Cookie sein, ein Accept-Language-Header oder eine Spalte in einer Benutzereinstellungstabelle, die beim Login gelesen wird — und ist es häufig auch. All das erreicht das Rendering auf demselben Weg: einmal pro Request aufgelöst und dann nach unten durchgereicht bis zu dem, was eine Zahl formatiert. Nichts davon legt die Locale in die Rechnungszeile, die der Accessor bekommt, und genau das macht sie zu Umgebung statt zu Daten.

Diese Unterscheidung lohnt Schärfe, denn ein Teil davon ist tatsächlich Zeilendaten. Eine Rechnung kann sehr wohl ihren eigenen Währungscode tragen, und ein einfacher Funktionszeiger liest den ohne Weiteres — eine React-Codebasis, an der ich letztes Jahr gearbeitet habe, reicht die Locale als Parameter durch und nimmt die Währung aus dem Datensatz, was genau die richtige Trennung ist. Was nicht in der Zeile stehen kann, ist, welcher Mensch gerade daraufschaut.

Das Kleinste, was kompilierte, war eine globale Variable: Locale pro Request setzen, pro Zelle lesen. Sie hielt den Descriptor als Compile-Zeit-Konstante und ist schlimmer als das Problem, das sie löst. Zwei Descriptoren, die sich nur in der Locale unterscheiden, können nicht gleichzeitig existieren, und was eine Zelle rendert, hängt davon ab, wann sie gelesen wird. Ich habe sie mit einem Kommentar committet, der genau das sagt, damit die Kosten im Code standen und nicht in Prosa.

Alle drei Routen meldeten daraufhin Zero Diff — die zwei Screens, wobei invoices doppelt zählt, weil neben der englischen für genau diesen Test eine deutsche Route hinzugekommen war. Die Ausgabe war identisch und das Programm schlechter, was genau die Grenze dessen ist, was dieser Test aussagen kann: Er vergleicht, was der Leser sieht, nie, was es gekostet hat, das zu erzeugen. Ein grüner Lauf war hier kein Beleg dafür, dass die globale Variable akzeptabel ist. Er war ein Beleg dafür, dass das Prüfskript eine globale Variable überhaupt nicht sehen kann.

Die Lösung ist, den Accessor doch einfangen zu lassen, was heißt, ihn zu boxen:

pub type Accessor<T> =
    Box<dyn Fn(&T) -> String + Send + Sync>;

Das ist der Moment, in dem der Descriptor aufhört, eine Compile-Zeit-Konstante zu sein. Er ist nicht mehr Copy, nicht mehr static, und er alloziert einmal pro Spalte pro Request. An Tag eins des Pilotversuchs hatte ich genau das als das notiert, was die These am ehesten kippen würde.

Was das tatsächlich kostete, gemessen

wc -l, vor und nach genau diesem Refactoring. Spätere Arbeit hat diese Dateien wachsen lassen, die Zahlen stammen also aus der Änderung selbst und nicht aus dem Repository in seinem heutigen Stand.

Die teure Variante ist kleiner. Das Framework wuchs um zweiundzwanzig Zeilen — ein dokumentierter Typ-Alias und eine Konstruktorfunktion —, und die Domänen schrumpften um neunundvierzig, weil den Descriptor konstant zu halten ein Makro erfordert hatte, das pro Locale zwei statische Spalten-Arrays erzeugt, plus die globale Variable, um die Locale hineinzuschmuggeln. All das fiel weg.

Was verloren ging, ist real: Copy, const, &'static, keine Allokation. Was gewonnen wurde, ist ebenfalls real: Die Locale wird eingefangen statt geschmuggelt, zwei Locales koexistieren, und der Wert einer Zelle hängt nicht mehr davon ab, wann sie gelesen wird.

Und die Aufrufstelle liest sich weiterhin wie Daten:

col(
    if de { "Betrag" } else { "Amount" },
    CellKind::Number,
    move |i: &Invoice| money(l, i.amount_cents),
),

Das ist nicht nennenswert weiter von einem Struct-Literal entfernt als das Original, und das ist der Befund in einer Zeile: Die deklarative Form überstand die Änderung, const nicht.

Die vier Fragen, die der erste Beitrag versprochen hat

Entwickler-Erlebnis. Größtenteils unauffällig, was das Kompliment ist. Zwei Dinge kosteten echte Zeit:

• Eine Page-Funktion darf nicht denselben Namen tragen wie ein Modul im Scope, und die daraus folgende Kaskade von fünf Fehlern beschreibt die Makro-Expansion statt der Ursache.
• Eine generische Komponente braucht Send + Sync-Bounds, die die React-Variante nie hatte — wobei der Compiler genau die richtige Korrektur vorschlug, was man nicht von allen sagen kann.

Fehlermeldungen. Die Spans sind durchgängig gut, das Vokabular ist es nicht:

• Jede Probe zeigte auf die Quellzeile, nie in expandierten Code hinein.
• Fehlerhaftes Markup bekommt eine eigens formulierte Diagnose — closing tag div does not match opening tag p, mit exakter Spalte und ohne jede Trait-Bound darin.
• Beim Vokabular wird es dünn. Gibt man $() etwas, das nicht nach JavaScript hinüberkann, entsteht eine unerfüllte Bound auf einem Trait namens Surrogated, ein Wort, das in der Dokumentation nirgends vorkommt, gefolgt von einer Liste von Implementierern, die mit "and 25 others" endet.

Die Grenze wird also korrekt bewacht und schlecht erklärt, was heißt: Ein Junior landet jedes Mal in der richtigen Datei und muss einmal erklärt bekommen, was diese Namen bedeuten.

Die Rebuild-Schleife. Sie hält, mit einem warmen inkrementellen Rebuild von 0,47 Sekunden. Um herauszufinden, ob die Makro-Expansion dominiert, wenn eine App wächst, habe ich Komponenten mit Template-Blöcken generiert und die Steigung gemessen:

Ungefähr linear bei etwa 1,6 Millisekunden pro Block, sodass fünfhundert Komponenten immer noch bei rund 1,3 Sekunden lägen, was heißt: Die Expansion ist nicht das, was Ihnen auffallen wird. Die Browser-Reload-Hälfte der Schleife bleibt ungetestet.

Wo die Trade-offs landen. Die Testdaten gegen ein echtes Toasty-Modell über SQLite zu tauschen änderte die Feldtypen von String-Slices zu owned Strings, verbreiterte ein Integer und machte die Zeilenabfrage asynchron — und kein einziger Accessor änderte sich. Die Abfrage ist abgeschlossen, bevor das Rendering beginnt, der Descriptor sieht die Asynchronität also nie. Das hielt, weil jede Spalte ein Skalar ist, der bereits in der Zeile liegt; eine verzögert geladene Relation würde verlangen, dass der Accessor die Datenbank erreicht, und seine Signatur ist synchron. Dieser Fall ist ungetestet, und ich werde nicht so tun, als wäre er es nicht.

Das Fazit

Ich bin mit der Überzeugung eingestiegen, dass der Descriptor Daten sein sollte und dass Rusts Funktionszeiger eine strengere, reinere Version derselben Idee sind. Sie sind strenger, aber jenseits der ersten Zelle, die Kontext von außerhalb der Zeile braucht, sind sie nicht reiner, und billiger sind sie auch nicht — sie zu behalten kostete ein Makro, zwei duplizierte Arrays und eine globale Variable, was mehr Maschinerie ist als die geboxte Closure, die damit vermieden werden sollte.

Der Befund lautet also: const-Sein war nie die Eigenschaft, auf die es ankam. Was die ursprüngliche Abstraktion funktionieren ließ, ist die Einweg-Abhängigkeit: Domänen reichen dem Framework Beschreibungen, das Framework weiß nichts über Domänen. Das hielt über alle drei Versuche hinweg unverändert — durch eine neue Zellenform, durch eine neue Quelle von Umgebungskontext und durch den Austausch der gesamten Datenschicht. Was brach, war enger, als es sich damals anfühlte: der Typ des Accessors, ein einfacher Funktionszeiger, und mit ihm der Status des Descriptors als Compile-Zeit-Konstante. Beides sind Entscheidungen darüber, wie eine Beschreibung repräsentiert wird, nicht darüber, was sie sagen darf. Der React-Beitrag hielt das Daten-Sein des Descriptors für die Idee, und ich hielt sein Konstant-Sein für eine strengere Version derselben Idee, während die Idee in beiden Fällen die Abhängigkeitsrichtung darunter war.

Das verallgemeinert sich über Admin-Screens hinaus und zurück zum Metadaten-Argument, mit dem das hier anfing. Eine Deklaration ist das wert, was sie einer Domäne verweigert, nicht, wo sie gespeichert oder wann sie ausgewertet wird. Fragen Sie sich bei jedem Descriptor — Pipeline, Screen, Policy — welche seiner Eigenschaften die Grenze sind und welche nur die Art, wie er heute zufällig gebaut ist. Sie sind leicht zu verwechseln, und nur eine von beiden ist es wert, verteidigt zu werden.

Der Pilotversuch liegt unter github.com/cordata-tech/topcoat-descriptor-pilot. Ein frischer Clone baut und serviert beide Screens, und scripts/zero-diff.sh check startet den Test, der die Frage entscheidet. NOTES.md enthält die Befunde so, wie sie notiert wurden, einschließlich derer, die anders ausgingen, und einer Probe, die ich falsch entworfen hatte.

Entstanden mit einem KI-Partner, was in einem Beitrag über das Entwickler-Erlebnis erwähnenswert ist: Topcoats erstes Release war im April 2026, es gibt also wenig Trainingsdaten, und die README ist der größte Teil des Korpus. Das Ausloten der Fehlermeldungen war meins, das Gerüst nicht. Wenn Sie Topcoat pilotiert und die rauen Kanten woanders gefunden haben — oder finden, dass ein Descriptor aus Closures mehr aufgibt, als ich zugebe —, würde ich das gern hören. Die Tür steht offen unter cordata.tech/contact. Weiterführend: Ein Skelett, viele Screens ist das React-Original, das hier repliziert wird, und Eine Pipeline ist ein Descriptor, kein Programm führt dasselbe Argument eine Domäne weiter über Metadaten.