- Un langage d’interface centré sur les standards du Web HTML, CSS et JavaScript, qui vise une conception d’interfaces plus concise et extensible que les frameworks existants
- Contrairement à React, il sépare la logique et les styles et facilite la maintenance en s’appuyant sur des fichiers externes de design system plutôt que sur le CSS-in-JS
- Même pour des composants complexes, le code reste simple et le bundle JS léger, par exemple un tableau avec tri/filtrage ne pèse que 3.9KB
- Le changement de thème de design est aussi possible avec seulement 32 lignes de CSS modifiées, sans toucher aux composants et en remplaçant simplement le design system
- Basé sur Bun, il se présente comme un framework tourné vers l’avenir, avec bundling rapide, compatibilité avec les standards et base de génération d’UI pour les modèles d’IA
Introducing Hyper
- Hyper est un nouveau langage de balisage permettant de construire des UI à partir des standards du Web HTML/CSS/JS
- Même des UI complexes peuvent être exprimées avec une syntaxe propre et simple
- Contrairement à React, il sépare la présentation, la logique et les styles
Objectifs du projet
- Standards first : construction fondée sur les standards HTML, CSS et JS
- Simplicity : une structure de composition simple, sans abstractions complexes
- Design Systems : une couche de design séparée pour les designers comme pour les développeurs
- Scalability : préserver la simplicité même quand l’application grandit
Comparaison entre React et Hyper
- Là où React adopte une structure monolithique mêlant logique, structure et styles, Hyper se concentre sur une pure couche de vue
- Composants simples
- Présentation d’exemples implémentant le même composant de tableau en Modern React, Old-school React et Hyper
- React moderne : UI construite avec des bibliothèques de composants comme ShadCN, Material UI ou Tailwind Catalyst, avec comme point fort la compatibilité avec les outils d’IA
- React à l’ancienne : approche des débuts, où styles et code des composants étaient séparés
- Hyper : exemple concis respectant les standards du Web, avec séparation nette entre structure et styles
- Hyper s’exprime avec une structure purement HTML et des méthodes simples, sans classes superflues ni hooks d’état
- Sur des exemples simples, l’écart est faible, mais plus la complexité augmente, plus la différence d’approche entre Hyper et React devient nette
- Composants complexes
- React basé sur ShadCN : bundle JS de 91.3KB
- Hyper : 3.9KB (1.2KB + 2.7KB)
- Hyper fonctionne avec un minimum de JS et se montre plus facile à maintenir
- Design systems
- Avec Hyper, pour modifier le style d’un dashboard, il suffit d’ajouter 32 lignes de CSS sans changer le code des composants pour remplacer tout le thème
- À l’inverse, avec ShadCN basé sur React, des milliers de lignes de code TSX sont dupliquées selon les thèmes
- Philosophie du design system de Hyper
- Exclusion totale du couplage entre design et composants, qu’il s’agisse de CSS-in-JS, Tailwind ou de styles inline
- Centralisation de toute la typographie et des règles de style dans des fichiers CSS externes
- Mise en œuvre d’une réutilisabilité complète, d’un design system centralisé et d’un zéro boilerplate
- Scalability
- L’approche Hyper préserve la simplicité même quand le projet grossit
- La structure reste simple et le volume de code réduit
Questions fréquentes
- Quelle différence avec Svelte ou Vue ?
- Les deux sont plus légers que React, mais continuent à encourager le couplage entre design et composants via le scoped CSS, Tailwind, etc.
- Hyper, lui, impose un design system complètement séparé
- What is Nue?
- Nue est un générateur de sites web et de web apps basé sur les templates Nue JS
- Hyper est le produit d’évolution de nouvelle génération de Nue JS, et les deux sont gérés dans le même monorepo
- Hyperlink (à venir) sera une solution de routage, pensée pour un lien étroit avec les standards du Web
- Quelle différence avec les frameworks existants ?
- Hyper ne cherche pas à ajouter une nouvelle couche d’abstraction, mais à revenir aux standards et à restaurer la simplicité
- Il est possible de construire des applications professionnelles avec les seules connaissances en CSS, HTML et JS
- Pourquoi les standards du Web sont-ils importants ?
- Une technologie intemporelle : une base technique valable pendant des décennies
- Un produit durable : maintenance possible sur le long terme sans changer de framework
Feuille de route
- Applications full-stack (d’ici 3 mois)
- Sont prévus : routage, communication entre composants, connexion à la base de données, déploiement cloud et changement de thème de design
- Generative UIs (d’ici 4 à 5 mois)
- Un framework d’UI générables par l’IA fondé sur des combinaisons HTML/CSS
- Avec accessibilité, responsive design et documentation intégrés automatiquement
- Comment battre React ?
- L’objectif est de gagner progressivement des parts d’usage
- En faisant évoluer pas à pas la perception des développeurs
- En proposant une structure simple et maintenable
- Et en démontrant la force des technologies fondamentales comme moteur de croissance
- Problème de doublon de nom ?
- Des projets Rust et Electron portent déjà ce nom, mais dans des contextes différents, donc cela ne pose pas de problème
Objectif ultime
- Construire une stack Web d’une simplicité radicale
7 commentaires
En ignorant comme d’habitude l’histoire, ils ont ressorti une vieille roue.
Certaines idées ne semblent pas mauvaises (la façon d’utiliser le Markdown), mais par rapport aux autres outils, cela ne semble pas offrir d’avantages particulièrement importants.
À voir les discussions sur Hacker News,
pour commencer, le développeur a une compréhension bien trop faible de React.
J’ai l’impression que le nom va changer dans un avenir proche... Comme c’est aussi écrit dans l’article, il y a déjà un projet Electron qui porte un nom similaire... Était-ce vraiment nécessaire d’utiliser ce nom ?
À en juger par la comparaison du code, on dirait que cela permettra d’économiser pas mal de tokens.
Svelte est le meilleur
Svelte, c’est le top.
Les goûts varient sans doute selon les personnes, mais moi, je préfère le
.map((item) => <li>)de JSX, géré en vanilla JS, au<li for>d’Angular, Vue, etc. (bibliothèque ? markup ? inclus).Je suis également d’accord sur ce point. Quand la logique ajoutée à HTML utilise une syntaxe propriétaire plutôt que du vanilla, cela constitue un obstacle important. Pour des interfaces simples, ce n’est pas un problème, mais lorsque la logique devient complexe, il y a une vraie différence en matière de flexibilité de développement, et la courbe d’apprentissage ne peut pas être ignorée.