mam_mol VS react-18

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.

If you aren't sure why state tearing was a hot topic a few years ago, when React's concurrent mode was first discussed, this github discussion should help: https://github.com/reactwg/react-18/discussions/69.

Tanner Linsley had a great post on twitter that suggested that concurrent rendering was fundamentally at odds with fine-grained reactivity, so to better understand what he was talking about I decided to write this demo.

Image Source: https://github.com/reactwg/react-18/discussions/37

But it does since React 18.

See this post for more details and an example of an actual memory leak.

From the React WG:

The React working group is officially advising against using runtime CSS-in-JS.