Der Default ist geschlossen

Ich baue keine unnötigen Türen.

Bei einem System, das ich auf Effizienz und Kontrolle ausgelegt habe, ist jede Schnittstelle nach außen ein potenzieller Angriffspunkt. Nicht hypothetisch, sondern grundsätzlich. Ein HTTP-Listener, der auf Port 8080 wartet, ist eine Einladung, die ich nicht mehr loswerden kann, sobald sie existiert. Firewall-Regeln, Auth-Tokens, TLS-Zertifikate sind dann Werkzeug, das ich nur brauche, weil ich die Tür überhaupt eingebaut habe.

Deshalb war meine erste Frage beim Interface-Design nicht: "Wie baue ich die Weboberfläche?" Sondern: "Brauche ich eine?"

Manchmal ja. Remote-Zugriff von einer anderen Maschine, Tooling-Integration, Debugging mit Browser-DevTools: das alles ist legitim und wird es geben. Aber als Ausnahme, nicht als Standard. Also habe ich das umgedreht: die HTTP-Schnittstelle ist implementiert, aber sie schläft. Wer sie will, übergibt beim Start ein Cargo-Feature-Flag . Wer das Flag nicht übergibt, hat keine offene Tür, weil es strukturell keine gibt. // Der Default ist nicht "gesichert". Der Default ist "geschlossen".

Das ist kein paranoider Reflex, sondern dieselbe Logik wie bei blinden Speicher-Nodes: eine Komponente, die eine Information nicht besitzt, kann sie nicht preisgeben. Ein Prozess, der keinen Port öffnet, kann über diesen Port nicht angegriffen werden. Der Unterschied zur abgesicherten Schnittstelle ist nicht graduell. Er ist strukturell.

Und dann die Folgefrage: wenn ich kein HTTP per default will, brauche ich trotzdem ein Interface. Rust war die naheliegende Antwort, weil ich Rust sowieso nehme, wo ich kann (auch für das HIRN darunter): die Effizienz ist messbar, der Umgang mit Speicher ist einer der wenigen Bereiche, wo ich das Verhalten der Laufzeit wirklich verstehe. Eine native Rust-GUI, direkt als Teil des Prozesses, ohne Umweg über einen lokalen HTTP-Server.

Das Ergebnis ist Dioxus mit dem Blitz-Renderer .

Blitz ist Alpha, und das ist spürbar. Nicht chaotisch, aber ich plane mit Einschränkungen, nicht gegen sie.

Das Autoscroll-Problem im Chat-Kontext, das mich eine Weile aufgehalten hat, ließ sich umschiffen. Nicht elegant, aber stabil: manuelles Scroll-Management über Signale statt auf einen nativen Autoscroll-Mechanismus zu warten, der noch nicht zuverlässig implementiert ist. Das Ergebnis ist funktional identisch mit dem, was ich erwartet hatte. Es war nur mehr Handarbeit.

CSS-Transitions funktionieren gut. transform und opacity-Fades verhalten sich so, wie ich es erwartet habe. Das ist nicht selbstverständlich bei einem Alpha-Renderer, und es hat direkten Einfluss auf die Qualität der Interaktion: weiche Übergänge, die sich nicht nach Prototyp anfühlen.

Und dann gibt es Schatten.

box-shadow ist mein Lieblingsdesign-Werkzeug für Tiefe und Fokus. Schichten mit unterschiedlichen Unschärfe-Radien, ein weicher Halo unter einem aktiven Element, die subtile Elevation-Sprache, mit der ich sonst arbeite. Blitz kann das nicht. Nicht schlecht, nicht langsam: schlicht nicht implementiert, jedenfalls nicht in der Form, die ich brauche.

Ich habe das eine Woche verdrängt und dann akzeptiert.

Das Interface nutzt keine Schatten. Tiefe und Fokus über andere Mittel: Hintergrundfarbe, Border, Opacity-Kontrast. Eine andere Designsprache als mein Reflex, aber keine schlechtere, jedenfalls nicht zwingend. Ich werde den Schatteneinsatz auf ein absolutes Minimum reduzieren und dort, wo er mir wirklich fehlen würde, nach Alternativen suchen. // Manchmal zwingt ein Werkzeug zu einem besseren Ergebnis, weil es die bequeme Lösung verweigert.

Am Ende bleibt ein Interface, das keine Schnittstelle öffnet, die es nicht öffnen muss, das sich nativ anfühlt, weil es nativ ist, und das das HTTP-Flag als bewusste Ausnahme kennt, nicht als heimlichen Standard. Das reicht. Für jetzt.