DEV Community: Kirill Novgorodtsev

Why $mol?

Kirill Novgorodtsev — Sun, 07 Jun 2026 23:27:53 +0000

TLDR — $mol comes with reactivity, local storage, offline, and themes all in one bundle. There are downsides, but they're almost all about community and tooling, not the code itself. You can live with them.

Let me start with those — feels more honest. No particular order.

There's no CDN build of $mol, the kind where you drop a single <script src=...> into HTML and start writing UI like you would with Vue. The class name in $mol is tied to its filesystem path ($mol_button lives in mol/button/), and the bundler builds the bundle from those paths. A CDN variant is theoretically possible, but someone would have to rewrite the bundler, and no enthusiast has stepped up.

Not enough "serious" public cases. Corporate apps exist but are hidden behind NDAs, leaving mostly demos and pet projects in public. From what I can show:

web.giper.dev — a product ecosystem ( Google-style ) by $mol's author.
b-on-g.github.io/blitz — my real-time quiz built on $mol + Giper Baza. Took a long time, polished it a lot.

Not much built-in tooling. Working in $mol is pleasant, but only once you're already "in the know" — it's rough for newcomers, the IDE support is thin. VS Code has official extensions but no go-to-definition or syntax hints.

Error stack traces look genuinely awful)

An error stack trace in $mol

I don't know if this can be fixed, we need a volunteer) Attempts have been made, but it needs more time — basically the noise and duplication just need to be cleaned up. That said, debugging in the browser is pretty straightforward thanks to human-readable class names.

Some of the tooling I built myself:

LSP — npm i -g view-tree-lsp@latest, plus app scaffolding in one command: npm create view-tree-lsp@latest bog/myapp -- --no-docker --no-tauri.
tree-sitter grammar for view.tree.
Zed extension built on top of them, with working go-to-definition, highlighting, and other niceties. 30k downloads there — probably bots indexing everything for tests)

The great and dreadful view.tree ( the format for declaratively describing components ) I don't count as a drawback. Compare it with your first time seeing JSX, for example. view.tree just describes regular JS classes — in a way that makes the relationships between components easier to see and avoids boilerplate.

Plus — a nice separation of layers: view.tree is the abstraction over HTML, ts is the logic, css.ts is the styles. Less to get confused about. Here's a quick example:

mol.hyoo.ru — tree playground

You can see a base component ( a div by default, but it can be anything ) and its compiled JS form. You can override class methods in your .ts, or add new methods in either file.

Basically, all the problems described above come down to a small community and weak marketing. Well — volunteers needed!)

A more serious problem is npm integration. There are three ways to pull in a library right now:

through a CDN — painless, but no types,
download the lib into your repo and commit it,
use the community tool for reproducible builds ( I haven't tried it myself, ask in @mam_mol_development ).

It just isn't native, it grates a bit. But the community keeps at it — there's ongoing work on the bundler.

People also write to me with this one a lot:

"There are no $mol jobs, and if there were, you couldn't find specialists."

Jobs, yes, almost none. But you can start a new project at your company or in a startup. And you don't need a "$mol specialist" — you need a TS developer who understands components and reactivity. The onboarding is 2–4 weeks, which is less than figuring out a stranger's React codebase with its Redux/Zustand/RTK/Tanstack zoo.

There's also plenty of design work you'll do from scratch, even though $mol has plenty of ready-made components. But once you build it, you can reuse those components across apps like a unified UI kit. Designer disputes guaranteed — beauty requires sacrifice :)

If design isn't a concern, you can throw together an interface very quickly from the available primitives — for an admin panel, for example.

What really needs serious work is the documentation and getting started. I think ( and many people write the same ) this is the main entry barrier right now. Good docs are hard to write, but necessary so people can pick things up faster and don't leave disappointed. I took a shot at this myself — wrote a Getting Started, from cloning mam to a working app with offline and sync. How well it turned out, you can judge)

About the toxic halo around $mol. A lot of people have run into hostile reactions under $mol posts — sometimes fair, sometimes not. The community itself is actually warm and friendly. Drop into @giper_dev (Russian-speaking), or better, come hang out in person at @piterjs. In person it's hard to stay toxic anyway :) I also run free intro sessions on $mol — DM me.

That's about it for the drawbacks. On to the upsides.

I'll start from a tangent. I was listening to a React-focused podcast recently and remembered how much manual tuning modern React needs. For every component with a heavy render you reach for useTransition or useDeferredValue to keep the UI from lagging on thousands of rows. And even if you add virtualization, it's virtualization only for that one component. In $mol all rendering is fully virtual: components outside the viewport physically don't exist, that "tuning" is hidden under the hood.

Compare the live Sierpinski Triangle demos by Karlovsky:

React — chokes during animation,
$mol — no stutter.

Same scenario, same hardware. Sources for both demos.

And here's the standard js-framework-benchmark, where Karlovsky added $mol — virtual rendering tears everything else apart, because components outside the viewport simply don't exist.

I had a burst of inspiration recently, wrote an earlier post about web components and put together a benchmark that counts lines of code:

Now about reactivity. Most reactive systems have the same edge case: one invalid value in the computation graph can drag along its neighbors, even ones that formally don't depend on it. I'll show it on Svelte because their own tutorial lets you try it hands-on.

We break {a}, and {b} falls over:

{b} doesn't depend on {a} in the code, but the effect cascades. You can catch the same thing in most top frameworks — it's usually fixed with manual try/catch or by splitting things across components. When {a} comes back, the sum is recomputed.

Tell me in the comments: if you split this across components, is the behavior the same? And how do other frameworks deal with it? I took the case from this video.

Now the same thing in $mol:

{b} is recomputed independently.

When {a} comes back, the sum is recomputed too.

In $mol this problem is solved architecturally. Every getter is an isolated atom: if one fails, the others don't recompute and don't even know about it. No need to write try-catch, everything fixes itself without a reload. A deeper look at reactivity.

OOP, but every method is an extension point

In $mol, reactivity isn't at the variable level — it's at the class method level. A getter automatically becomes a computed reactive cell: it reads data → records dependencies → recomputes when they change. No useState, useMemo, useEffect, or $derived — that's hidden under the hood.

Reusing a component means writing its name in view.tree. No copy-paste, no npm install, even across repos:

$my_dashboard $mol_page
    body /
        <= Chart $hyoo_crus_chart_pie
        <= Edit $bog_some_editor

This works because $mol modules are addressed by class name, and the mam bundler pulls in what it needs. The line between "your" code and "someone else's" code disappears.

CSS in TS

I'm not great at CSS — that's my personal pain, I don't want to memorize a pile of rules. In $mol, styles are just a TS object with typed properties. Don't know a property? Just tab through autocomplete and it works) An AI assistant handles it well too — it can self-correct, which is genuinely convenient.

Offline in one line

In app.meta.tree you write:

include \/mol/offline/install

That's it — the app installs as a PWA and runs offline. The manifest is assembled by the bundler.

Localization

In view.tree you put @ before a string:

$my_page $mol_page
    title @ \Hello, World!

view.tree is transpiled to JS, and this string becomes a method:

/** title @ \Hello, World! */
title() {
    return $mol_locale.text( "$my_page_title" )
}

The en locale is extracted from default values automatically, and the key is built from the component name + property name. That part is important — the identifier is human-readable and immediately points to where it's used, both in the filesystem and in the component. Drop a page.locale=ru.json next to it with translations:

{
    "$my_page_title": "Привет, мир!"
}

That's it.

This works because view.tree is a strict DSL. The React default is i18next: you write t('greeting.title'), you maintain the keys and dictionary yourself. To automate extraction, you add i18next-parser, which greps the source with regexes and breaks on anything dynamic.

No config files

A $mol project has no vite.config.ts, no per-app tsconfig. The mam bundler knows everything from conventions: filename — type, path from root — class name. No config wrangling.

A new module = a folder with a pair of .ts/.view.tree files. mam generates package.json itself if it doesn't exist.

Strict architecture

In $mol, the class name is firmly tied to its filesystem path. The class $my_app_button lives in /my/app/button/button.ts — no other option. Want to name a class Button and put it in src/components/ui/button/index.ts? Not happening.

It sounds like a constraint, but $mol just doesn't let you write spaghetti. The name is short and tells you where to look. From a class name in code, in git log, in a GitHub comment — you immediately know the file.

On top of that is MVF (ModelView Fractal), the decomposition pattern behind $mol_view. Each component is both a view for its parent and a model/controller for its children. Domain model lives separately: $hyoo_talks_domain lives in talks/domain/domain.ts, the view works with its objects, not raw data:

// talks/talk.view.ts
domain() {
    return this.$.$hyoo_talks_domain
}
chat( id ) {
    return this.domain().Chat( id )
}

Also, MAM itself isn't tied to the web. A module is a directory with sources in whatever — view.tree, GLSL shaders, CSS, JSON, files for other languages. You can teach the bundler any language; MAM only knows about the directory structure and inter-module dependencies.

The renderer isolates failures

Every $mol component is its own error boundary. An exception in a getter, a timeout while loading, anything at all — a placeholder is shown for that one component, the rest of the UI stays alive.

In React you'd wrap things in <ErrorBoundary> and remember to do it. In $mol it's the default.

Plus reactivity: when the value becomes valid again, the component re-renders on its own with no page reload. We already saw that in the Svelte example above.

One codebase, every platform

The same $mol project builds for:

Web
Tauri (desktop on macOS/Windows/Linux, also iOS/Android)
Chrome/Firefox extension (MV3)
Telegram Mini App

The Tauri wrapper and extension manifest are already in the scaffold; you don't configure anything separately. My own VK Music (bog/vk) ships both as an MV3 extension and as a gh-pages mirror — literally the same module.

By the way, if you need a backend — there's Giper Baza: CRDT sync, tuned for $mol. That's a separate story, I'll write a dedicated post comparing it to other local-first solutions.

Why give it a try

Not because of age — $mol is younger than React and Vue, same age as Angular. The point is elsewhere: in 10 years $mol has had one major release. React has had 19, Angular has had 21.

	$mol	React	Angular	Vue
First release	2016	2013	2016	2014
Major versions by 2026	1	19	21	3
Tree-shaking without setup	✅ from day one	⭕ removes unused	⭕ inhibited, standalone since 2022	⭕ removes unused
Atoms / signals out of the box	✅ from day one	❌ only via MobX and friends	⭕ added 2023	✅ from day one
One failure doesn't kill the app	✅ automatic	⭕ ErrorBoundary since 2017	❌ none	⭕ errorCaptured manually since 2017
Async suspension	✅ automatic, any level	⭕ Suspense, render-time only	❌ via third-party RxLet, manual	❌ mount-time only
Static typing	✅ behavior + composition + styles (since 2020)	❌ third-party typings	✅ behavior only	⭕ behavior only since 2020
Inversion of control	✅ typed contexts	⭕ manual / renderProps	✅ injections / contexts	⭕ untyped contexts since 2017
Behavior / composition / styling split	✅ from day one	❌ doesn't exist by design	❌ partial	❌ partial
Behavior customization	✅ inheritance or in-place	⭕ manual extension points	⭕ inheritance	⭕ extension points since 2020
Composition customization	✅ inheritance or in-place	⭕ manual extension points	⭕ manual slots	⭕ manual slots
Styling customization	✅ cascade via auto-generated attributes	❌ manual extension points or classes	❌ manual extension points or classes	❌ manual extension points or classes
Visible-area-only rendering	✅ lazy by default, fully virtual since 2020	⭕ via third-party component	⭕ via third-party component	⭕ via third-party component
Same code on client and server	✅ from day one	❌ different API, data prep required	❓	❓

There are no versions because there's no reason to keep copies around. Break an API — rename the module, and you can reuse up to 99% of the old code. Sounds wild but it works: no lockfile zoo, no "works on my machine", no weekly dependabot PR.

If you recognized some of your own pain in there, drop by @giper_dev (Russian-speaking) and we'll sort it out. Or just poke around the playground — view.tree online, no install.

$mol Getting Started

Kirill Novgorodtsev — Sun, 07 Jun 2026 15:26:33 +0000

Apps that work offline, sync without a backend, and weigh ~140 KB brotli with everything bundled. Reactivity, storage, and UI come from a single stack — you focus on the app, not on wiring libraries together.

By the end of this guide you'll have a real $mol app with offline support, themes, and local storage — running locally and built with one command. About ten minutes if a terminal and editor are already at hand.

What you'll get

A running app that already includes the things you usually bolt on later:

installable as a PWA, works offline,
local storage with conflict-free sync (no backend code on your side),
light and dark themes with a toggle,
client-side routing,
a GitHub Action for deploying to Pages.

All of this comes from the scaffolder. After that, change one line and watch it recompute itself.

What you'll need

Node.js 24+ and git.

That's the whole list. The bundle only includes modules your code references. No one maintains dependencies by hand.

Step 1. Bring up the workspace and dev server

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

In the same terminal and process, start the Hyper Base:

+ giper/baza/app/run port=9090

mam works as a monorepo workspace of independent modules. Your app lives in it as a couple of files in its own namespace, and the bundle only contains modules your code actually reached. The dev server at http://localhost:9080 builds each bundle on demand.

Step 2. Generate the app (one command)

From the mam folder, create the project. Pick your namespace and app name, for example my/hello:

npm create view-tree-lsp@latest my/hello -- --no-docker --no-tauri

The command creates a working app in ./my/hello/:

my/hello/
├── app/
│   ├── index.html        # web entry point
│   ├── app.view.tree     # declarative component description
│   ├── app.view.ts       # behavior
│   ├── app.view.css.ts   # styles (typed CSS-in-TS)
│   ├── app.test.ts       # test
│   ├── app.meta.tree     # offline install
│   └── app.locale=en.json
├── store/
│   └── store.ts          # local storage
├── assets/logo.svg
└── .github/workflows/deploy.yml

The app is ready to run.

Step 3. Open it

Go to http://localhost:9080/my/hello/app/. The first load takes a few seconds — the dev server builds JS and CSS for this module on the fly. After that, everything is incremental. You'll see an app with themes, a few screens, and working navigation, ready to live locally without a server.

The scaffolder also prints a test runner URL (…/app/-/test.html) where you can watch the built-in test pass.

What you got (and why it matters)

The scaffolder lays out a minimal real $mol app, and that's on purpose. It already has:

Local storage out of the box. store/store.ts is built on a CRDT: state persists locally and merges cleanly between devices. No sync code on your side, no backend.
The line include \/mol/offline/install in app.meta.tree wires in the PWA module. The app installs to a phone and keeps working without a network. Offline is just another module.
A light/dark theme toggle and URL-driven navigation ($mol_state_arg) are already in place. Don't need them? Remove Theme_toggle from view.tree — it's gone from both the DOM and the bundle.
Styles are typed: app.view.css.ts is CSS-in-TS, a typo fails at compile time.

Make it reactive

Open app/app.view.tree, find the welcome text. Add an input bound to a property, and a line that depends on it:

home <= Home $mol_page
    title \Home
    body /
        <= Name $mol_string
            hint \Name
            value? <=> name? \
        <= Greeting $mol_text
            text <= greeting \

Then in app/app.view.ts, describe greeting as a function of name:

greeting() {
    const name = this.name()
    return name ? `Hi, ${name}!` : ''
}

Try typing. The greeting updates by itself. You didn't subscribe to the field, you didn't schedule a rerender: greeting reads this.name(), so $mol records the dependency and recomputes just that value when name changes. The same reactive model runs through every layer, including data loading: a value that isn't ready yet "suspends" and slots in once it arrives. That's why async code reads like ordinary sync code.

Set up the editor (a minute)

view.tree is indentation-sensitive, so editor support helps a lot:

VS Code: install the view.tree language plugin; use the .editorconfig plugin to get tabs for indentation and LF line endings.
Zed: the view.tree extension adds highlighting, go-to-definition, and autocomplete.
The Zed extension is built on the view.tree LSP and a tree-sitter grammar — you can plug them into other editors too.

Deploy

The scaffold already includes a GitHub Actions workflow: push to main, it builds and publishes to GitHub Pages. Feature branches get their own preview URL.

Try it

Generate the app, turn the welcome screen into something you'd actually use, and put that into the generated store so it survives a page reload and runs offline. When you need the full set of building blocks (inputs, lists, charts, pickers), check the module catalog — every one with examples.

If you get stuck, there's a skill for AI coding agents that knows view.tree and can suggest how to do a specific thing:

npx skills add b-on-g/mol_skill --all -g

What's Actually Wrong with Web Components

Kirill Novgorodtsev — Sun, 05 Apr 2026 12:59:54 +0000

Ladies and gentlemen, we continue digging into the intricacies of web components. I made a bench here — comparing frameworks ($mol/Lit/Symbiote) on TodoMVC. Seems like we're talking about one thing, but the bench is about something else, right? Nope — to understand web components you need frameworks that put them front and center, the ones that "bet on them."

Here's what I managed to figure out:

First. Memory: 124 bytes per web component, and 16 bytes per JS object. An order of magnitude difference — that's a lot, and without virtualization the interface will most likely lag.

// Lit: each todo-item is an HTMLElement (C++ heap, ~124 bytes minimum)
@customElement("todo-item")
export class TodoItem extends LitElement { ... }
// <todo-item> immediately allocates a DOM node on createElement

// Symbiote: same deal, each <todo-item> = HTMLElement
class TodoItem extends Symbiote { ... }
TodoItem.reg('todo-item');

// $mol: component is a JS object. DOM is created ONLY on render.
// 1000 tasks in the model ≠ 1000 DOM elements
// $mol renders only visible components (virtualization)
task_rows() {
    return this.task_ids_filtered().map(id => this.Task_row(id))
}

Custom Element	js/mol_view
1,000 tasks: ~124 KB just for nodes	~16 KB for objects
10,000 tasks: ~1.2 MB	~160 KB

And that's just the base nodes — without text nodes, attributes, styles, and event listeners, which also get allocated in the C++ heap. The Custom Elements spec requires class MyEl extends HTMLElement. You can't create a CE without a DOM node.

This same argument is explored here by the author of SolidJS. Below is the response from the article's author:

"If your goal is to build the absolute fastest framework you can, then you want to minimize DOM nodes wherever possible. This means that web components are off the table."

Put simply — want performance? Don't use web components.

Second, besides increased memory consumption, we lose JIT optimization.

Operation	Time	How much worse
obj.title = x (JS object)	~1–2 ns	baseline — 1x
element.textContent = x (DOM)	~30–60 ns	30x worse
element.setAttribute('class', x)	~50–100 ns	50x
element.style.color = x	~80–150 ns	80x

Task: select all (relevant for email, for example, which just can't delete all messages at once if they don't fit on one page). Here's how it degrades:

Tasks	Lit	$mol	Difference
100	60 µs (microseconds)	3 µs	20x
1,000	600 µs	8 µs	75x
10,000	8 ms	12 µs	650x
100,000	120 ms (lag — if a frame takes more than 16 ms)	15 µs	8,000x

And a question for readers. Should we even orient ourselves around js-framework-benchmark in this case? I think not. You shouldn't render what isn't visible. They're fighting over pennies there, and everyone knows you don't penny-pinch. And let's recall the perf quote above.

And a code example. Here we're also parsing HTML... (that's bad)

// Lit: update through DOM property
// element.textContent = newValue  ← C++ binding, slow path
render() {
    return html`<label> ${this.text} </label>`;
    // Under the hood, Lit does: node.textContent = value
}

// $mol: update through JS property
// this.title() — reads from memo cache (JS heap)
// DOM updates in a batch via requestAnimationFrame
task_title(id, next?) {
    return this.task(id, ...)!.title ?? ''
}

Moving on. WC (Web Components) use push semantics for reactivity. Pull — I doubt they'll ever support it. What does this affect? The number of lines of code written by you. And all people make mistakes — there's a saying for a reason: "The best code is code that was never written." Let's look at the bench.

Respectable.

And a code example, for clarity.

// Lit: Push via EventTarget + requestUpdate
export class Todos extends EventTarget {
    #notifyChange() {
        this.dispatchEvent(new Event("change")); // push!
    }
    add(text) {
        this.#todos.push({ ... });
        this.#notifyChange(); // ← manual push
    }
}
// Each component subscribes via @updateOnEvent("change")
// On ANY change ALL subscribers get notified

// Symbiote: Push via EventTarget similarly
store.addEventListener('change', () => this.#render());

// $mol: Pull — automatic dependency graph
@$mol_mem
groups_completed() {
    // Automatically tracks dependencies:
    // task_ids() → task() → groups
    // Recalculates ONLY when dependencies change
    for (let id of this.task_ids()) {
        var task = this.task(id)!;
        groups[String(task.completed)].push(id);
    }
    return groups;
}
// No EventTarget needed, no manual subscriptions

Not for nothing did Vue.js choose pull reactivity.

Let's touch on testability. To test a web component — you need to render it. Maximally inefficient. I think we all hate it when tests take forever.

Let's look at an example:

// $mol: tests WITHOUT DOM. Component is just an object.
'task add'($) {
    const app = $hyoo_todomvc.make({ $ })
    app.Add().value('test')
    app.Add().submit()
    $mol_assert_equal(app.task_rows().at(-1)!.title(), 'test')
}
// No document.createElement, no connectedCallback
// Just method calls and state checks

// Lit: testing requires DOM
const el = document.createElement('todo-app');
document.body.appendChild(el); // connectedCallback!
await el.updateComplete; // wait for render!
el.shadowRoot.querySelector('.new-todo')... // access through Shadow DOM!

// hyoo_todomvc has 140 lines of tests.
// Lit and Symbiote implementations — 0. (and they have even more code)

About inheritance.

How it works in Lit with those "convenient little web components":

class TodoApp extends LitElement {
     render() {
         // The entire template — a monolithic block. 40+ lines of HTML.
         return html`
             <header>...</header>
             <section>
                 <ul>${this.todos.map(t => html`...`)}</ul>
             </section>
             <footer>
                 <span>...</span>
                 <ul>...</ul>
                 <button>...</button>
             </footer>
         `;
     }
 }

 // Want to change just the footer?
 class MyTodoApp extends TodoApp {
     render() {
         // Can't say "take parent's render(), replace footer."
         // The only option — copy ALL 40 lines
         // and change the piece you need.
         return html`
             <header>...</header>         // copy
             <section>...</section>        // copy
             <footer>MY FOOTER</footer>   // all for this
         `;
     }
 }

How it works in $mol:

// Base component: scrollable area
$mol_scroll
    sub /           ← content
    scroll_top 0    ← scroll position
    event_scroll     ← handler

// TodoMVC INHERITS $mol_scroll and replaces only sub (child elements):
$hyoo_todomvc $mol_scroll
    sub /
        <= Page $mol_list ...

// Scroll, position, handler — all inherited for free.
// We only overrode the CONTENT.

// You can go deeper — inherit $hyoo_todomvc itself and replace, say, just the footer:
$my_custom_todo $hyoo_todomvc
    foot <= My_footer $mol_view
// Everything else (list, input, filters) — inherited as is.

Same goes for inheriting logic and styles (uniquely cascading). Zero copy-paste and boilerplate.

And to wrap up, I'd like to argue with one statement. Below is my loose quote from @i360u's text (first link in the article):

"Any engineering decision is a compromise. The existence of 'cons' doesn't outweigh all possible 'pros' by default."

To some extent you can agree with that. If not for one "BUT." We all have the same task — build the most convenient, fast, beautiful application, without legacy, with clean code that's easy to maintain, and all that jazz. Once more — the task is the same for everyone. And you need to look at who solves it best across the entirety of the frontend world. I know one such solution.

It's $mol — everything else is worse. That's a fact.

The whole "vendor lock-in," "scary and confusing to learn something new" — those are childish excuses to avoid facing facts. Everywhere in programming you have to learn new things. And there's no vendor lock at all. Think about it. Kirill. Subscribe.

FAQ (from the comments)

"But if you use virtualization, you won't render those CE nodes either — same thing, no?"

Not quite. With virtualization the complexity shifts to the container above. And it's not that straightforward in practice — $mol has built-in virtualization by default, while in WC-based frameworks you have to architect it yourself. Every extra architectural decision you have to make is another chance to mess up.

"For composition — just split render into renderHeader / renderBody / renderFooter and override one in the subclass. This pattern is 40 years old."

Absolutely agree. The point here is more that $mol enforces this as an architectural constraint — the developer physically can't produce that monolithic-template anti-pattern I showed. The fewer mistakes a programmer can make, and the more the compiler can catch — the better. Again, it's about not having to think about or write "extra" code.

"You're generalizing too radically. The problem isn't web components themselves — it's how people use them. Naively rendering thousands of elements through DOM will hit limits regardless of approach."

I think so too. But many people actually look at js-framework-benchmark and believe it reflects real-world performance. That causes frustration — it feels like the benchmark is misleading. If the benchmark is bad, why does it exist? I think we should use every trick available and show the real maximum performance of JS. It's not infinite either, but how far can it go? Nobody knows — everyone's stuck on HTML. By my estimates, you could write an entire OS on $mol, and it would be faster and more stable than many existing ones. (And notifications would arrive instantly with the bell icon updating too.)

"What about Ctrl+F page search? You can't find what's not rendered."

Fair point. But funnily enough, in $mol search actually works — it overrides the standard browser search by default and searches through the full data, not just the visible DOM.

"Isn't $mol just for SPAs? For sites with interactive elements — take SSG + web components."

A matter of priorities. For SSG I'd still pick $mol — theming, localization, and responsive layout come out of the box. As for WC — if you need to shove a component into an existing project, sure, why not. I'd even try plugging one into my own $mol app.

"Where are the hidden benchmark results that were bad for $mol?"

The initial benchmark was set up incorrectly — there were junk files in the root that got pulled into all bundles locally. The real size turned out to be ~185 KB. Honestly noted it in the bench. You can verify by building it yourself. I'd welcome a real comparison from an independent author — that's how truth is born, the scientific way.