mam_mol VS tree.d

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.

Tree: Accept: application/x-harp.tree (most obvious)

As you can see, the js.tree representation is already much cleaner. And does not require any ASTExplorer. Although I made a tree support patch for it , which has been ignored by the maintainer for the second year. It's open source, baby!

Download sample files.