- Eine UI-Sprache mit Fokus auf den Webstandards HTML, CSS und JavaScript, die im Vergleich zu bestehenden Frameworks eine schlankere und besser skalierbare Zusammenstellung von Interfaces anstrebt
- Anders als React trennt sie Logik und Styles und setzt statt CSS-in-JS auf externe Design-System-Dateien, was die Wartbarkeit verbessert
- Auch bei komplexen Komponenten bleibt der Code einfach und das JS-Bundle klein, z. B. hat eine Tabelle mit Sortier-/Filterfunktionen 3,9 KB
- Auch ein Wechsel des Design-Themas ist mit nur 32 geänderten Zeilen CSS möglich, ohne Komponenten anzupassen
- Läuft auf Basis von Bun und ist ein zukunftsorientiertes Framework mit schnellem Bundling, Standardkompatibilität und einer Grundlage für UI-Erzeugung durch AI-Modelle
Introducing Hyper
- Hyper ist eine neue Markup-Sprache zur Erstellung von UIs auf Basis der Webstandards HTML/CSS/JS
- Auch komplexe UIs lassen sich mit einer sauberen und einfachen Syntax ausdrücken
- Anders als React trennt es Darstellung, Logik und Styles
Projektziele
- Standards first: Aufbau auf HTML-, CSS- und JS-Standards
- Simplicity: Einfache Kompositionsstruktur ohne komplexe Abstraktionen
- Design Systems: Eine getrennte Design-Ebene für Designer und Entwickler
- Scalability: Einfachheit auch bei wachsenden Anwendungen bewahren
Vergleich React vs. Hyper
- React hat eine monolithische Struktur, in der Logik, Struktur und Styles vermischt sind, während Hyper sich auf die reine View-Ebene konzentriert
- Einfache Komponenten
- Es werden Beispiele gezeigt, in denen dieselbe Tabellenkomponente jeweils mit Modern React, Old-school React und Hyper umgesetzt wird
- Modernes React: Aufbau der UI mit Komponentenbibliotheken wie ShadCN, Material UI oder Tailwind Catalyst; eine Stärke ist die Unterstützung durch AI-Tools
- Altes React: Ein früherer Ansatz, bei dem Styles und Komponentencode getrennt waren
- Hyper: Ein kompaktes Beispiel, das Webstandards einhält und Struktur und Styles klar trennt
- Hyper beschreibt dies nur mit einer auf reinem HTML basierenden Struktur und einfachen Methoden, ohne unnötige Klassen oder State-Hooks
- Bei einfachen Beispielen ist der Unterschied gering, doch mit wachsender Komplexität wird der Ansatzunterschied zwischen Hyper und React größer
- Komplexe Komponenten
- React auf ShadCN-Basis: JS-Bundle 91,3 KB
- Hyper: 3,9 KB (1,2 KB + 2,7 KB)
- Hyper arbeitet mit minimalem JS und ist leicht zu warten
- Design Systems
- Wenn der Dashboard-Stil mit Hyper geändert wird, lässt sich das gesamte Theme ohne Änderungen am Komponentencode durch nur 32 zusätzliche Zeilen CSS austauschen
- Bei React-basiertem ShadCN werden dagegen tausende Zeilen TSX-Code je Theme dupliziert
- Die Design-System-Philosophie von Hyper
- Jede Kopplung zwischen Design und Komponenten wird vollständig vermieden, etwa durch CSS-in-JS, Tailwind oder Inline-Styles
- Sämtliche Typografie- und Stilregeln werden in externen CSS-Dateien gebündelt
- Vollständige Wiederverwendbarkeit, ein zentralisiertes Design System und Zero Boilerplate werden angestrebt
- Scalability
- Beim Hyper-Ansatz bleibt die Einfachheit auch bei wachsenden Projekten erhalten
- Die Struktur ist einfach, der Codeumfang klein
Häufig gestellte Fragen
- Was ist der Unterschied zu Svelte und Vue?
- Beide sind leichter als React, fördern aber weiterhin die Kopplung von Design und Komponenten, etwa über Scoped CSS oder Tailwind
- Hyper erzwingt ein vollständig getrenntes Design System
- What is Nue?
- Nue ist ein Generator für Websites/Web-Apps auf Basis von Nue JS Templates
- Hyper ist die nächste Evolutionsstufe von Nue JS und wird im selben Monorepo verwaltet
- Hyperlink (geplant) ist eine Router-Lösung und steht für eine enge Anbindung an Webstandards
- Worin liegt der Unterschied zu bestehenden Frameworks?
- Bei Hyper geht es nicht darum, neue Abstraktionswerkzeuge hinzuzufügen, sondern um die Rückkehr zu Standards und die Wiederherstellung von Einfachheit
- Mit Kenntnissen in CSS, HTML und JS lassen sich professionelle Apps erstellen
- Warum sind Webstandards wichtig?
- Zeitlose Technologie: eine technische Grundlage, die über Jahrzehnte gültig bleibt
- Nachhaltige Produkte: langfristige Wartbarkeit ohne Framework-Wechsel
Ausblick
- Full-stack-Anwendungen (innerhalb von 3 Monaten)
- Geplant sind Routing, Kommunikation zwischen Komponenten, DB-Anbindung, Cloud-Deployment und der Austausch von Design-Themes
- Generative UIs (innerhalb von 4–5 Monaten)
- Ein von AI generierbares UI-Framework auf Basis von HTML/CSS-Kombinationen
- Inklusive automatischer Barrierefreiheit, Responsivität und Dokumentation
- Wie kann React überholt werden?
- Ziel ist eine schrittweise Vergrößerung des Marktanteils
- Den Wahrnehmungswandel bei Entwicklern schrittweise fördern
- Eine einfache und wartbare Struktur bereitstellen
- Wachstum durch den Nachweis der Stärke grundlegender Technologien
- Namensüberschneidungen?
- Es gibt bereits Rust- und Electron-Projekte mit demselben Namen, aber in anderem Kontext, daher sei das kein Problem
Langfristiges Ziel
- Das Endziel ist der Aufbau eines radikal einfachen Web-Stacks
7 Kommentare
Typischerweise wurde die Geschichte ignoriert und ein altes Rad wieder hervorgeholt.
Einige Ideen scheinen nicht schlecht zu sein (die Art, Markdown zu nutzen), aber im Vergleich zu anderen Tools gibt es wohl keinen großen Vorteil.
Wenn man sich die Diskussionen auf Hacker News ansieht,
zunächst einmal ist das Verständnis des Entwicklers für React viel zu gering.
Ich habe das Gefühl, dass der Name in naher Zukunft geändert werden dürfte ... Wie im Artikel steht, gibt es bereits ein überschneidendes Electron-Projekt ... Musste man wirklich unbedingt diesen Namen verwenden?
Beim Vergleich des Codes scheint es, als ließen sich ziemlich viele Tokens einsparen.
Svelte ist das Beste
Svelte ist das Beste
Das ist wahrscheinlich Geschmackssache, aber ich persönlich mag bei Angular, Vue usw. (einschließlich dieser Libraries? des Markups?) JSX mit
.map((item) => <li>), das in Vanilla JS verarbeitet wird, lieber als<li for>.Dem stimme ich ebenfalls teilweise zu. Wenn die Logik, die zu HTML hinzugefügt wird, nicht Vanilla ist, sondern eine eigene Syntax verwendet, ist das eine große Hürde. Für die einfache UI-Umsetzung ist das kein Problem, aber wenn die Logik komplex wird, gibt es Unterschiede bei der Entwicklungsflexibilität, und auch die Lernkurve lässt sich nicht ignorieren.