Vous venez de React ou de Vue et rien n'a de sens ? Lisez d'abord Modèle mental : cinq minutes sur ce que sont devenus computed, watch, les hooks de cycle de vie et le chargement des données.
$mol est un framework d'interface réactif : vous décrivez ce qu'est l'interface, et le framework détermine comment et quand la mettre à jour. Pas de DOM virtuel, pas d'abonnements manuels, pas de useEffect. Vous écrivez les composants sous forme d'arbre ; $mol ne rend que ce qui est visible et ne recalcule que ce qui a réellement changé.Un composant se compose de trois fichiers :name.view.tree — la mise en page déclarative (un langage arborescent compact)name.view.ts — le comportement (de simples classes TypeScript)name.view.css.ts — les styles typés (vérifiés par le compilateur)Cette séparation est toute l'idée : la mise en page reste lisible, la logique reste testable, les styles restent sûrs au niveau des types.Aucun des trois n'est obligatoire à lui seul. L'arbre est un raccourci pour une structure que vous pouvez aussi écrire à la main : De TypeScript à view.tree construit un même composant des deux façons et montre le code vers lequel l'arbre compile.
Vous voulez une petite application qui le reste en grandissant — le runtime est compact et le rendu est virtualisé par défaut.Vous aimez les types partout — même les styles sont vérifiés par TypeScript.Vous êtes fatigué de câbler la réactivité à la main — l'état dans $mol est automatiquement réactif, comme un tableur.
Un compteur, en entier :1$my_counter$mol_view2 sub /3<= Count $mol_view4 sub /<= count \5<= Increment $mol_button6 click?<=> increment?7 sub /<= label \+1namespace $.$${2export class $my_counterextends$.$my_counter{3@ $mol_memcount(){return 0}4@ $mol_actionincrement(){this.count(this.count()+1)}5}6}count est réactif : tout ce qui le lit se rerend automatiquement lorsqu'il change. Pas de setState, pas de tableau de dépendances, aucun store à enregistrer.
