$mol Adds Node.js Storage Support and New UI Tools

On October 5, 2026, Habr published a roundup of August and September updates to $mol and Giper Dev. $mol_storage gained Node.js support, work continued on the WYSIWYG editor and UI tools, and security was strengthened in $mol_link. If you work with $mol, it’s worth testing the storage methods and editor against your own use cases. For now, the GTK module is best treated as an early-stage project.

Storage, keyboard shortcuts, and text editing

$mol_storage now supports Node.js and lets you retrieve file system statistics through $mol_storage methods. used(), free(), and total() return used, free, and total space in bytes. portion() returns the proportion used, while level() returns its logarithmic level. If your app needs these figures, you can test the methods on their own before building them into the UI.

For keyboard shortcuts, there’s now $mol_hotkey2. You bind a key combination to an action declaratively in the component structure, without handling events manually elsewhere. The roundup also mentions a plugin for Ctrl + A and Ctrl + C, but doesn’t explain exactly how it works. I wouldn’t give it a place in a project based on its name alone.

The WYSIWYG editor first gained basic inline formatting, then block editing. You can now change a paragraph’s type by selecting a block; text-formatting commands have moved to a separate menu. Keyboard shortcuts control nesting: Tab moves the current block one level deeper, and Shift + Tab moves it back up.

The editor is worth trying, but its capabilities are still evolving. Block formatting doesn’t mean every way of working with structured text is covered yet. Especially when users like to paste, move, and rework content in an order nobody drew in the mockup.

GTK, feedback, and security

A separate GTK module lets projects in the $mol ecosystem use GTK to build native interfaces without WebView. It’s an attempt to take the $mol approach beyond the browser, including experiments with desktop apps. The project is still at an early stage: it would be premature to treat it as a ready-made solution for every desktop app.

b-on-g now has a feedback2 component for collecting feedback and viewing submitted messages. You provide an identifier when setting it up; before adding it to a project, you can explore the form demo. For a small service or documentation site, it’s a way to avoid building a feedback interface from scratch.

The roundup also mentions jack.tree, a smalljs documentation update, and the release of music v1.**. For jack.tree, the author links to a separate article and discussion but doesn’t describe the tool in the roundup itself. The changes to music aren’t detailed either; a separate piece is promised. So it’s too early to draw conclusions about what they can do from this list.

The security changes include filtering script protocols in $mol_link and a resolved issue in Giper Baza. The roundup gives no details about the Baza issue; anyone who needs them to assess the update should open the issue in the repository. It’s also worth comparing this news with the Next.js security updates: in both cases, it’s more useful to check your project’s specific dependencies than to go by the word “security” in a headline.

What to check in your project

Developers using $mol should start with the tasks their app already has. Need file system statistics in Node.js? Test the $mol_storage methods. Have lots of keyboard actions? See whether $mol_hotkey2 makes it convenient to define them alongside component actions. A short API example helps explain the idea, but it’s no substitute for testing it in your own UI.

If users write structured text, test the editor by turning paragraphs into blocks and changing nesting with the keyboard. Test the feedback form against how your team plans to receive and review messages. For site owners and marketers, the more important question is whether people need that feedback channel, not whether they can add another component to the list.

For now, GTK is worth considering separately from current website tasks: it concerns native interfaces and is still at an early stage. And following the news about $mol_link and Giper Baza, the team should check whether the changes affect the projects it uses. The roundup flags the fixes but doesn’t provide enough detail for broader conclusions.

My take: the use case matters more than the list of new features

The editor interests me most: it changes not just the set of buttons, but how people manage the structure of their text. You can draw a menu quickly; making nested blocks understandable after several edits is another matter. I’d open the demo and test odd edge cases before discussing how neat the toolbar looks.

I wouldn’t put every item in the roundup into a “let’s implement this” bucket. GTK is explicitly at an early stage, the editor is evolving, and some projects lack detail. Better to choose one use case you need and test it with a prototype. “Let’s move everything higher up” was never an interface strategy; “let’s add everything new” isn’t a product strategy either.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

1. Новости $mol и Giper Dev habr.com

About the author

Ania Młynarek

UX/UI designer

I design interfaces for services and sometimes explain to teams why “just move everything higher” isn’t a strategy. I love prototypes that let us test not only the look and feel, but also unusual edge cases.

All posts by the author