$mol, a reactive micro-modular web framework with lazy everything

The module idea and the claims in the feature list

$mol is described as a reactive micro-modular UI framework, with the subtitle claiming to be the fastest reactive micro-modular compact flexible lazy UI web framework, and the README's own line is that it is very simple but very powerful.

The module system is the defining idea. The features list says the modules are very small and that all of them are optional, and that modules are automatically included in the package at compile time, so you do not import or install them manually.

That last point is the unusual one and it is what the zero configuration claim rests on. Rather than a dependency graph you assemble, a module brings its own dependencies with it, and the build resolves them. The consequence is that the tree of what ends up in your bundle is a property of which modules you use rather than something you curate, which is both the convenience and the risk.

The features are arranged around three ideas. Laziness covers lazy rendering, lazy evaluating and lazy loading, and the framework's name carries the lazy prefix on each one. Reactivity is described as full reactivity in all application layers, not only between view and view model, with automatic dependency tracking between reactive containers, so there is no manual publish, subscribe, unsubscribe or stream routing. And there is effective state synchronisation, plus lifecycle management that automatically destroys unnecessary objects.

The debugging claims are the ones that sound most like a reaction to a specific frustration. Every object gets a user friendly id, all objects are quickly accessible from the console, and there is easy user friendly logging of all state changes. That is a direct answer to the usual complaint that reactive frameworks make it hard to see what state is and why something re-rendered.

The one architectural claim worth pulling out is the absence of asynchrony. The README describes pseudosynchronous code, with asynchrony abstracted by reactivity, and says no callbacks, promises or streams hell. Whether that is a fair description of a real codebase is a fair question, but the intent is clear: the framework wants to remove the async ceremony from application code, and you write as if everything is synchronous.

The ecosystem, the reviews and what MAM means

The framework is used through NPM under the $mol ecosystem, and the site is at mol.hyoo.ru. The repository name, mam_mol, points at the wider MAM project, and the topics list includes mam, oorp, bem, bundler, components and self-descriptive.

Several of those are worth explaining because they name the design rather than the features. The bem entry refers to BEM attributes, which the framework generates automatically for elements so that styling and tooling can target them. The oorp approach is the reactive library underneath, which handles the dependency tracking. Self-descriptive means that a component knows how to describe itself, which is what makes the lazy rendering and the tooling possible. The bundler entry refers to the build tooling that goes with the module system.

The README has a reviews section, which for a project like this is unusual and worth a mention. A framework with a distinctive design and a decade of history tends to attract people who write about it, and the reviews are linked from the README rather than hosted, which is a modest and sensible arrangement.

There is a contributors section and a donate link, and the table of contents lists a tutorials section, which is the mechanism by which most people meet the framework. The quick start and the tutorials are where a new user gets started, and for a project with this level of unconventional design, the tutorials do more work than the reference does.

The two listed releases are v1.0 in September 2016 with the message Really ready for production, and v2.0 in October 2016 described as a big refactoring. So the public release history of the framework itself is two releases, both in 2016, while the repository has been pushed to as recently as October 2026.

That gap between the release history and the commit history is the single most important fact for anyone evaluating the project, and the rest of this article returns to it.

The quick start in the README is deliberately small, because the zero configuration claim means there is no project to assemble:

git clone https://github.com/hyoo-ru/mam.git ./mam && cd mam
npm install && npm start

That clones a preconfigured MAM repository, installs and starts the dev server. There is no bundler configuration to write and no list of modules to declare, which is the point of the module system. The alternative the README offers is a Gitpod online dev workspace, so you can get a running environment without installing anything locally.

The debugging conveniences are worth trying before anything else, because they are what tell you whether the framework is earning its place. Every object has a user friendly id, all objects are reachable from the console, and state changes are logged in a readable form. In a framework where rendering is lazy and dependencies are tracked automatically, the question that always comes up is which change caused which update, and the answer here is that you can see it rather than infer it.

Why the releases stopped and what that means in practice

The release history is the weak point of this project and it deserves to be stated plainly rather than softened.

The framework's own two versions are from 2016. The last push to the repository is on 2026-10-18. The licence is MIT, the primary language is TypeScript, and the default branch is master.

There is a plausible explanation that does not require abandonment. $mol is a foundational layer rather than an application dependency, and the ecosystem that sits on top of it, the MAM family of tools, has its own release cadence. When your framework is consumed by other packages that are released frequently, the framework itself changes rarely, and a commit to master that is not part of a release is often a fix to the base that a downstream release will pick up.

The practical consequences for an adopter are real. There is no tagged version whose behaviour you can pin, which means you are tracking a moving branch or you are consuming a version somebody else published. There is no changelog telling you what broke. And the documentation has to be read against the current code rather than against a version, because there is no version to read against.

The counter-argument is that this is normal for infrastructure. A build tool or a reactive core that changes rarely can be a perfectly stable dependency, and the absence of releases can reflect good discipline rather than abandonment. The two are hard to tell apart from outside.

The way to tell is to look at what uses it. If the MAM ecosystem is alive and shipping, the framework is maintained in practice, and pinning to a snapshot of master is a defensible choice for a team that accepts that. If the ecosystem has also gone quiet, the risk is real.

The other thing to weigh is hiring and maintenance. A framework whose two public releases are a decade old, whose module resolution is unusual, and whose debugging story depends on a console integration you would have to learn, is a serious commitment for a team. That is not an argument against it, since the ideas are good, but it is an argument for going in with the expectation that you will own the parts you depend on.

Where this fits against the mainstream options

The comparisons that matter are with Solid, Svelte and Vue's reactivity model, because $mol belongs to the same family of ideas.

Solid is the closest in spirit. It compiles reactivity away rather than using a virtual DOM, it has fine-grained signals, and it pushes the same argument that the framework should not re-render what did not change. The difference is that Solid is a mainstream project with a large ecosystem, regular releases and a conventional build integration, while $mol is a decade-old design with a self-contained module system.

Svelte is the same argument from the other direction. It compiles a declarative component into imperative code at build time, which produces very little runtime work and very small bundles. Where Svelte hides the mechanism behind a template syntax, $mol exposes it through a component model where you write the update logic yourself.

Vue's reactivity is the mainstream version of the same idea, with a proxy-based system that tracks dependencies automatically. It is the least similar of the four in implementation but the most similar in ambition, and its ecosystem is by far the largest.

What $mol offers that none of them do is the combination of laziness at every level with automatic module inclusion and a self-describing object model. Rendering is lazy, so a component that is not visible does not run. Evaluation is lazy, so a value is not computed until something reads it. Loading is lazy, so a module is not fetched until it is used. And the modules arrive at compile time by themselves, so you get the benefit of a fine-grained dependency system without maintaining a manifest of every transitive dependency.

The cost of that combination is that you are adopting a whole way of working. The module resolution in particular is not a drop-in replacement for a standard bundler setup, and the debugging conveniences, which are among the best arguments for the framework, only work if you adopt its conventions.

So the honest summary is that $mol is a well-designed framework whose ideas have largely been validated by the mainstream, offered in a form that has not kept pace with the ecosystem. It is a good thing to read, a reasonable thing to build a small internal tool on, and a risky thing to bet a product's frontend on.

Editorial conclusion

Adopt $mol if you are building an isomorphic TypeScript application and value lazy evaluation and automatic reactivity enough to accept an unconventional module system. Skip it if you want a mainstream framework with a large hiring pool, since this one has been largely unchanged in its public releases since 2016. Verify first by running the quick start and checking that the module resolution works in your build, since the automatic inclusion of modules at compile time depends on the bundler.

Frequently asked questions

Official sources

1. hyoo-ru/mam_mol on GitHub
2. License: MIT
3. Project website
4. README
5. Releases