> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2026/w12-d2-observation-frontend-vitality-in-the-ai-wave/2026-d2-key-takeaways-review.md). # 2026-D2: Rückblick auf die wichtigsten Punkte Konferenzprogramm: Die Veranstalter stellen die Folien normalerweise nach etwa einem Monat bereit. Livestreams und Aufzeichnungen gibt es nicht. An einem einzigen Tag finden Dutzende Vorträge parallel statt. Man verpasst zwangsläufig vieles. Ich habe einige Vortragende mit fundierter fachlicher Erfahrung ausgewählt. Die folgenden Notizen beziehen sich nur auf die Veranstaltungen, die ich besucht habe und die mir im Rückblick besonders lohnend erscheinen. Zunächst ein Überblick über das heutige JavaScript-Ökosystem. Mir fällt auf, dass selbst viele professionelle Frontend-Entwickler ihr eigenes Sprachökosystem nicht gut kennen oder noch das Bild aus ihrer Einstiegszeit vor Augen haben. Zu den wichtigsten Akteuren gehören heute Vercel, VoidZero, Bun und Biome. Ich habe ChatGPT eine ASCII-Grafik erstellen lassen. Sie vermittelt die Zusammenhänge gut und dient hier zur Orientierung. ``` ┌──────────────────────────────────────────────────────────────────────┐ │ JavaScript Ecosystem │ └──────────────────────────────────────────────────────────────────────┘ ┌──────────────┐ │ Developers │ └──────┬───────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ ① AI / Coding Entry Layer │ │----------------------------------------------------------------------│ │ Cursor / Claude Code / Copilot / Windsurf / Zod │ │ │ │ 作用： │ │ - 代码生成 │ │ - agent 工作流 │ │ - IDE 内交互 │ └──────────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ ② Framework / Application Layer │ │----------------------------------------------------------------------│ │ React / Vue / Svelte / Solid │ │ Next.js / Nuxt / Remix / Astro │ │ │ │ 代表公司 / 项目： │ │ - Vercel → Next.js │ │ - NuxtLabs → Nuxt │ │ - Vue / Evan You ecosystem │ └──────────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ ③ Toolchain Layer ← 现在竞争最激烈 │ │----------------------------------------------------------------------│ │ Bundler / Dev Server / Compiler / Linter / Formatter / Test │ │ │ │ 主要玩家： │ │ - Vite / Rollup / Rolldown → VoidZero 阵营 │ │ - Turbopack → Vercel │ │ - Rspack → ByteDance │ │ - Webpack → 旧时代核心基础设施 │ │ - Biome → lint / format │ │ - esbuild → 高性能构建基础件 │ │ - SWC / OXC → 编译基础设施 │ │ │ │ 这里决定： │ │ - 本地开发体验 │ │ - 构建速度 │ │ - 配置模型 │ │ - AI 能否直接操作工程系统 │ └──────────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ ④ Runtime Layer │ │----------------------------------------------------------------------│ │ Node.js / Bun / Deno / Browser / Edge Runtime │ │ │ │ 主要玩家： │ │ - Node.js Foundation / OpenJS │ │ - Bun │ │ - Deno │ │ - Vercel Edge Runtime │ │ - Cloudflare Workers │ └──────────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ ⑤ Deploy / Cloud / Delivery Layer │ │----------------------------------------------------------------------│ │ Vercel / Netlify / Cloudflare / AWS / Azure / GCP │ │ │ │ 作用： │ │ - 部署 │ │ - 托管 │ │ - 边缘分发 │ │ - Serverless / AI App Runtime │ └──────────────────────────────────────────────────────────────────────┘ ``` #### I. **Vite+: Eine integrierte JavaScript-Werkzeugkette — Evan You** Evan You wirbt weiter dafür, Frontend-Werkzeuge in Rust neu zu schreiben. Rust für Frontend-Infrastruktur einzusetzen, ist inzwischen weitgehend Konsens in der Branche. Mit Ausnahme von TSC. | **Werkzeugtyp** | **Ältere Generation (JavaScript)** | **Neue Generation (Rust)** | | ---------------- | --------------------------------------------- | -------------------------- | | Projektgerüste | Vue Cli / Create React App | Vite 8 | | Bundler | Webpack (Kompilierung mit ts-loader) / Rollup | Rolldown | | TypeScript-Build | tsup (auf Basis von esbuild) | tsdown | | Codeprüfung | ESLint | Oxlint | | Codeformatierung | Prettier | Oxfmt | | Testframework | Jest | Vitest | ![image.png](https://km.sankuai.com/api/file/cdn/2752980249/228125441867?contentType=1\&isNewContent=false) Vite+ führt die verschiedenen Konfigurationsdateien der Werkzeugkette in einer Datei zusammen und vereinfacht damit die Konfiguration. ![image.png](https://km.sankuai.com/api/file/cdn/2752980249/228143018714?contentType=1\&isNewContent=false) Warum ist diese Arbeit wichtig? Weshalb braucht es im KI-Zeitalter eine einheitliche und effiziente Werkzeugkette? **Die Kernaussage: Code zu schreiben ist nicht mehr der Engpass. KI muss ihren eigenen Code ständig prüfen und verifizieren. Wenn man ihr keine saubere, effiziente Werkzeugkette bereitstellt, wird das künftig große Produktivitätsgewinne verhindern.** ![image.png](https://km.sankuai.com/api/file/cdn/2752980249/228145264077?contentType=1\&isNewContent=false) Zum Schluss erwähnte er kurz ein Produkt, das VoidZero intern testet. Es konzentriert sich auf automatische Bereitstellung und durchgängige Typsicherheit über den gesamten Stack. Das sieht ein wenig nach einem Einstieg in Cloud-Dienste aus und weist in dieselbe Richtung wie Vercel. ![image.png](https://km.sankuai.com/api/file/cdn/2752980249/228143392739?contentType=1\&isNewContent=false) #### II. **Google A2UI: LLM-generierte Oberflächen für Agents und A2A —** Jennie Ein Eindruck von Googles Anziehungskraft: ![image.png](https://km.sankuai.com/api/file/cdn/2752980249/228154026954?contentType=1) ![image.png](https://km.sankuai.com/api/file/cdn/2752980249/228178285513?contentType=1\&isNewContent=false) Dieser Vortrag stellte A2UI vor. Es geht darum, Benutzeroberflächen dynamisch für Nutzer zu erzeugen. Neben A2UI gibt es dafür viele weitere Ansätze. | **Dimension** | **AG-UI** | **ChatKit** | **MCP UI** | **Vercel AI UI** | **Google A2UI** | | ---------------------------------- | ---------------------------------------------- | --------------------------------- | ------------------------------------------------------- | ----------------------------------- | ---------------------------------------------- | | **Ausrichtung** | Vom Frontend-Zustand gesteuert | Speziell für OpenAI | Remote-Rendering durch Agents | Integration eines vertikalen Stacks | **Allgemeines deklaratives Protokoll** | | **Kernmechanismus** | Gemeinsamer Client-Zustand | Proprietäre Komponentenbibliothek | iframe in einer Sandbox | Shadcn + SDK | **Rendering-Beschreibung in JSON** | | **Signal-Rausch-Verhältnis** | Sehr hoch (native Leistung) | Mittel | Mittel (Aufwand für domänenübergreifende Kommunikation) | Hoch (Entwicklungseffizienz) | **Sehr hoch (einheitliches Erscheinungsbild)** | | **Sicherheit** | Hoch (Kontrolle im Frontend) | Hoch | Sehr hoch (isolierte Umgebung) | Hoch | **Sehr hoch (keine Codeausführung)** | | **Plattformübergreifende Nutzung** | Schwach (Frontend muss neu geschrieben werden) | Schwach | Stark (Web zuerst) | Schwach (Web zuerst) | **Sehr stark (native Anwendungen und Web)** | **Das Merkmal von Google A2UI: UI als strukturierte Daten** Anders als Vercel, das React-Komponentenfragmente, also Code, direkt vom Server sendet, besteht A2UI darauf, dass der Agent keinen Code sendet, sondern nur JSON-Beschreibungen. * Der Agent gibt einen flachen JSON-Datenstrom aus, der die beabsichtigte Oberfläche beschreibt, etwa `{type: "chart", data: [...]}`. Der Client empfängt ihn und rendert die Oberfläche mit lokal vorgegebenen, vertrauenswürdigen Komponenten, beispielsweise aus Angular, Flutter oder Lit. * Diese Trennung von Daten und Darstellung beseitigt das Risiko vollständig, dass ein LLM bösartige Skripte für XSS erzeugt. Zugleich können die Antworten des Agents in nativen Smartphone-Apps und auf Webseiten genau denselben visuellen Stil haben. Die Grundidee von AG-UI lautet: „Der Agent denkt und entscheidet. Die UI-Logik muss im Frontend bleiben.“ * Zustandssynchronisierung, Shared State: Zwischen Agent und Frontend entsteht ein Zustandsobjekt, das in Echtzeit in beide Richtungen synchronisiert wird. Der Agent kann den Zustand direkt per Anweisung ändern, etwa mit `state.selectedItems = [...]`. Das Frontend-Framework, beispielsweise React oder Vue, erkennt die Änderung und aktualisiert die lokalen Komponenten innerhalb von Millisekunden. * Auslösen von Aktionen, Action System: Frontend-Entwickler stellen dem Agent eine Reihe von Funktionen als „Fähigkeiten“, den Actions, bereit. Der Agent entscheidet, wann er sie aufruft. Wie sie ausgeführt werden, legt vollständig der Frontend-Code fest. Das gewährleistet die Sicherheit der Geschäftslogik. Die Grundidee von MCP UI lautet: „UI sollte wie eine API standardisiert werden. Wohin der Agent geht, dorthin folgt ihm die UI.“ * UI als Ressource, UI as Resource: Im MCP-Protokoll ist UI nicht länger vorab geschriebener Frontend-Code, sondern eine vom Agent dynamisch bereitgestellte „Ressource“. Der Agent gibt über das `ui://`-Protokoll eine URI zurück, beispielsweise `ui://analytics-dashboard/v1`. * Unabhängigkeit vom Host, Host Agnostic: Man schreibt einen MCP-Server, dessen UI direkt in Claude Desktop, ChatGPT, Cursor oder sogar der eigenen App gerendert werden kann. Das Frontend muss nicht für jede Plattform neu geschrieben werden. (iframe) #### **III. Agentic Coding aufbauen: Vom Modell zum Framework —** Cui Zeyu (Mayou), Luo Changwei (Shanguo) Innerhalb von Alibaba gibt es viele KI-Programmierwerkzeuge. Verschiedene Abteilungen entwickeln ihre eigenen Lösungen. Das erinnert wirklich an das Frontend vor zehn Jahren. Ich habe nur zwei Vorträge dazu gehört, über Qoder und Qwen-Code. Qwen-Code fand ich interessanter. Es ist ein Fork von Gemini CLI: . Ich habe mir nur zwei Gedanken notiert. Der Rest war eine Produktvorstellung. Wer sich dafür interessiert, kann das Repository lesen oder das Werkzeug herunterladen und ausprobieren. Programmierung ist deshalb so wichtig, weil ihre Ergebnisse in hohem Maß überprüfbar sind. Bei vielen Aufgaben ist es leicht, Inhalte zu erzeugen, aber schwer, ihre Richtigkeit zu prüfen, etwa beim Schreiben von Texten oder bei subjektiven Urteilen. Beim Programmieren ist es umgekehrt: Die Erzeugung ist zwar schwierig, doch das Ergebnis lässt sich durch Kompilieren, Testfälle und Evaluationssysteme rasch überprüfen. Diese Eigenschaft, „schwer zu erzeugen, aber leicht zu prüfen“, macht Programmierung zum idealen Optimierungsgegenstand für KI. Sie erklärt auch, warum der Wert einer Aufgabe eng mit ihrer Überprüfbarkeit zusammenhängt. ![image.png](https://km.sankuai.com/api/file/cdn/2752980249/228183240565?contentType=1) Der wichtigste Weg zu besseren Programmierfähigkeiten eines Modells besteht aus „drei Formen der Skalierung“: erstens der Datenmenge, mit großen Datenbeständen und hohem Codeanteil; zweitens dem Kontextumfang, der das Verständnis ganzer Repositories und langer Zusammenhänge ermöglicht, etwa mit 256K Kontext; drittens hochwertigen Daten, deren Trainingsqualität durch synthetische Daten laufend verbessert wird. Zusammen erlauben sie dem Modell, sich in einem geschlossenen Kreislauf überprüfbarer Rückmeldungen weiterzuentwickeln und bei komplexen technischen Aufgaben qualitative Sprünge zu erreichen. ![image.png](https://km.sankuai.com/api/file/cdn/2752980249/228162627358?contentType=1\&isNewContent=false) #### IV. **Von Context Engineering zu Harness Engineering —** Zhou Xiao Zhou Xiao gehörte zu den Vortragenden mit besonders guten technischen Einsichten. Er analysiert nüchtern anhand grundlegender Prinzipien. Der WeChat-Account von ByteDances Web Infra hat ein Transkript veröffentlicht: . Zusammenfassung: KI-gestütztes Programmieren hat das Schreiben von Code um eine Größenordnung beschleunigt. Die Auslieferung ist dadurch aber nicht schneller geworden, denn auf das Programmieren entfallen nur 30 Prozent. Die übrigen 70 Prozent sind Tests, Fehlersuche, Veröffentlichung und Kommunikation. Nur das Schreiben zu optimieren, ist ein typisches lokales Optimum: Es entsteht mehr Code, der Prüfaufwand wächst, und Menschen werden noch stärker belastet. Zhou Xiao setzt bei den „physikalischen Realitäten“ von autoregressiven Transformern, KV-Cache, Prompt-Cache und ReAct an. Je länger der Kontext, desto teurer der Prefill, desto stärker verteilt sich die Aufmerksamkeit und desto mehr Halluzinationen entstehen. Anhängen ist billig, Änderungen in der Mitte sind teuer. Der Kern von Context Engineering besteht deshalb darin, den Präfix stabil zu halten und die Prompt-Struktur sorgfältig zu gestalten, statt wahllos Informationen anzuhäufen. Lange Gesprächsverläufe werden zu einem Snapshot oder einer AGENTS.md verdichtet und im Dateisystem abgelegt, statt alles in den Kontext zu stopfen. Unter dieser Voraussetzung muss sich die Rolle von Ingenieuren verändern: vom „Menschen, der Code schreibt“ zum „Menschen, der Umgebungen und Werkzeuge entwirft“. Für Agents braucht es eine Werkzeugkette, die für sie lesbar ist, geringe Latenz hat, strukturierte Ausgaben liefert und Fehler spürbar zurückmeldet. Herkömmliche, für Menschen gedachte GUIs, Logs und Diagramme sind für Agents meist Rauschen. Gute Werkzeuge sollten APIs für Agents sein. MCP stellt elementare Aktionen bereit. Skills halten bewährte Vorgehensweisen als Arbeitsanweisungen fest und werden bei Bedarf geladen. Sub-Agents zerlegen lange Aufgaben in mehrere unabhängige Sandboxes und kommunizieren über strukturierte Zusammenfassungen. So wächst die Entropie in einem einzelnen Kontext nicht unkontrolliert. Der geschlossene Arbeitskreislauf darf nicht bei „Die KI schreibt, ich prüfe den Code“ enden. Der Agent sollte LSP, Tests und Sandbox-CLIs nutzen, die Korrektheit selbst nachweisen und anschließend Änderungsumfang, Screenshots und Testplan zu einem Bericht bündeln. Menschen prüfen das gelieferte Ergebnis, statt jeden einzelnen Arbeitsschritt zu verfolgen. Spezifikation und Plan, Zusammenarbeit zwischen Mensch und Maschine und die Entscheidung, wann AskUser nötig ist, sollen unnötiges Ausprobieren verringern. Die menschliche Aufmerksamkeit bleibt so für die Definition des Ziels und die Prüfung des Ergebnisses verfügbar. Die zentrale Schlussfolgerung des gesamten Vortrags lautet: Ein Modell ist eine Funktion, die physikalischen Beschränkungen folgt, keine Magie. Wer diese Beschränkungen versteht, erkennt den eigentlichen Schutz vor Konkurrenz im Engineering. Er liegt nicht darin, mehr Codezeilen zu schreiben, sondern bessere Harnesses zu entwerfen: Systeme, in denen eine Gruppe von Agents und wenige Menschen mit begrenztem Kontext und begrenzten Werkzeugen kontrollierbar, überprüfbar und skalierbar zusammenarbeiten.