mol VS mam_mol

A good example is the JSON validation module family /mol/data. If you use the $mol_data_integer function anywhere in your code, the bundle will include the /mol/data/integer and /mol/data/number modules, on which $mol_data_integer depends. But, for example, the bundler will not even read /mol/data/email from the disk, since no one depends on it.

And for those who, for some reason, are not yet ready to completely switch to the $mol framework, we have prepared several independent micro-libraries:

Do you want to try ReactiveDOM in action right now? I published a prototype of the polyfill $mol_wire_dom.

To do this, we will first take $mol_jsx, which is the same as E4X creates real DOM nodes, not virtual ones:

Well, let's cure the patient, and at the same time show the ease of integration of the reactive library $mol_wire into a completely foreign architecture.

We have omitted some methods here. The complete set can be found in the sources $mol_wire_set.

As you can see, proceduralism is more popular here, which is also not the most practical approach. And the most practical thing here is Vue. Only $mol is cooler than it, but there is no point in considering it separately as a framework, because it simply uses the $mol_wire library as a circulatory system, and we have already analyzed it earlier.

$mol_wire_sync makes any API synchronous.