If you have built UIs with React, Vue, or Svelte, you already understand most of what $mol does — the names are just different. Those frameworks are excellent and popular for good reason; this page is a translation table, not a competition, to help you feel at home quickly.
IdeaReactVueSvelte$molComponentfunction / classSFC (.vue).svelte file.view.tree + .view.tsLocal stateuseStateref / reactivelet x@ $mol_memDerived valueuseMemocomputed$:y= …@ $mol_mem (reads other cells)Side effectuseEffectwatchEffect$:{ … }@ $mol_action (explicit, never automatic)Load data on mountuseEffect(fetch)onMounted(fetch)onMount(fetch)no hook: read the data in a property, the view requests it when it rendersPropspropspropsexport letbindings in view.treeEventonClick@clickon:clickclick?<=>handler?Two-way inputcontrolled inputv-modelbind:valuevalue?<=>field?Listitems.map()v-for{#each}keyed Row*Conditionalcond&& …v-if{#if}assign null to removeShared stateRedux / ContextPinia / providestoresany object with @ $mol_memRoutingReact RouterVue RouterSvelteKit$mol_state_argStylingCSS-in-JSscoped <style><style>typed .view.css.ts
The deeper difference is not the vocabulary above — it is who solves the recurring problems. In React, Vue, or Svelte most of them are patterns you re-implement in every component and break in your own way. In $mol they are properties of one mechanism, so the whole class of work disappears rather than getting a nicer API.Where the table above renames things, this is where $mol actually removes them.
