1. Origine
Lumos est un projet de Timothy Ricks, développeur et créateur de contenu Webflow reconnu dans la communauté internationale. Le framework est né d'une frustration partagée par de nombreux builders : les projets Webflow grossissent, les composants se multiplient, et sans structure commune, la base de code devient difficile à maintenir et à transmettre. Client-First avait posé des bases solides, mais son modèle de nommage très verbeux ne tirait pas parti des fonctionnalités natives de Webflow, notamment les variables et les composants introduits ces dernières années. Lumos a été conçu pour combler ce gap : une architecture pensée dès le départ avec les nouvelles primitives de Webflow, orientée réutilisabilité et lisibilité. La V2 a marqué un tournant net, en réduisant significativement le code custom de démarrage et en plaçant les composants au centre du workflow.
2. Utilité
Sur les projets Webflow où le nombre de composants est élevé, l'absence de framework se paie rapidement : classes redondantes, comportements incohérents entre pages, temps de transmission élevé entre développeurs. Lumos résout ça en imposant une structure commune à tout le projet. Chaque élément a un rôle défini : les modules de grille et de flexbox gèrent la mise en page de façon prévisible, le système Trigger & State permet de piloter des interactions CSS complexes sans toucher au JavaScript. Le résultat, c'est un projet où chaque collaborateur retrouve ses repères rapidement, et où les mises à jour globales se propagent via les variables sans tout reconstruire.
3. Fonctionnalités
Ce qui distingue Lumos des autres frameworks Webflow, c'est la combinaison d'une architecture modulaire avec les variables et composants natifs de Webflow, sans couche d'abstraction supplémentaire.
- Système de grille (Grid) : module de mise en page basé sur CSS Grid, configuré par attributs pour une cohérence responsive sur tout le projet
- Système de flexbox (Flexbox) : module de layout aligné sur les conventions Webflow, avec classes utilitaires prévisibles et documentées
- Trigger & State Machine : système d'interactions CSS avancées sans JavaScript, des attributs déclenchent des états sur les éléments cibles, permettant des menus, modales, onglets et transitions pilotés uniquement par CSS
- Intégration native des variables Webflow : Lumos est conçu pour fonctionner avec les variables de couleur, de typographie et de spacing de Webflow, les changements globaux se propagent sans intervention manuelle
- Architecture component-first : chaque section est un composant autonome et réutilisable, pensé pour être clonable et maintenable par un collaborateur ou un client
- Convention de nommage légère : moins de classes utilitaires à mémoriser qu'avec Client-First, grâce à l'utilisation des primitives Webflow natives
- Cloneable officiel : projet starter disponible sur Webflow Made-in-Webflow (plus de 12 500 clones), avec documentation intégrée
- Compatible avec GSAP, Finsweet Attributes et les autres librairies de l'écosystème Webflow
4. Cas concrets
→ Pour un studio qui livre des sites à des clients amenés à les gérer en autonomie, l'architecture Lumos apporte une vraie lisibilité. Les composants sont construits de façon isolée : le client peut modifier le contenu d'un bloc sans risquer de casser les autres sections. Couplé aux variables Webflow, un changement de couleur de marque se propage sur l'ensemble du site en quelques secondes, sans intervention du développeur.
→ Pour les projets avec des interactions riches (menus avec états d'ouverture, accordéons, panneaux glissants), le système Trigger & State évite d'intégrer du JavaScript pour gérer chaque état. On pose des attributs sur les éléments déclencheurs et cibles, et Lumos orchestre les transitions CSS. Résultat : moins de code custom à maintenir, moins de risque de régression lors des mises à jour Webflow.
5. Prix
Lumos est entièrement gratuit. Le projet starter est disponible en cloneable sur Webflow, la documentation est publique, et il n'existe aucun plan payant. Timothy Ricks monétise son travail via sa communauté Webflow Wizards et ses formations : Lumos lui-même reste en accès libre.
6. Questions fréquentes
Lumos ou Client-First ?
Les deux sont des frameworks sérieux et documentés. Client-First est le plus répandu et le mieux documenté pour les projets classiques. Lumos est plus moderne, tire mieux parti des variables et composants natifs de Webflow, et convient mieux aux projets enterprise ou avec beaucoup d'interactions. Si tu pars d'un projet existant sous Client-First, migrer n'a pas de sens : le choix se fait au démarrage.
Lumos nécessite-t-il du JavaScript ?
Non pour les fonctionnalités de base. Le système Trigger & State repose entièrement sur CSS. Pour des interactions plus complexes (GSAP, transitions de page avec Swup, logique conditionnelle), du JavaScript peut s'ajouter, mais Lumos ne l'impose pas.
Peut-on utiliser Lumos avec Finsweet Attributes ?
Oui, les deux coexistent bien. Finsweet gère les comportements CMS et le filtrage, Lumos gère la structure et les interactions d'interface. Les conflits de classes sont rares à condition de respecter les conventions de chaque outil.
La courbe d'apprentissage est-elle longue ?
La V2 a réduit significativement le code de démarrage et simplifié l'entrée dans le framework. Un développeur Webflow habitué à Client-First peut être productif avec Lumos en quelques heures de pratique sur le cloneable officiel.
