[rlander]

I feel like you missed the point of Imba. It's not solely focused on code compression (although that does appear to be a secondary objective). Instead, Imba is all about empowering developers to create declarative user interfaces without the typical complexities that often accompany such tasks, like dealing with reactivity, signals, custom directives, v-dom, and so on.

[sesm]

IMO there is inherent complexity in the task of creating dynamic user interfaces and reactivity/signals/directives are different tools to deal with this complexity by imposing different mental model on top.

In any case, if Imba offers a new approach it fails to communicate this on the landing page and focuses on code compression instead. To me it reads like Imba is a re-pack of status quo approach (React + Next.js) that focuses on compressed syntax. This is actually a good thing, I just wonder, whether a new language is necessary to achieve this.

[rlander]

> if Imba offers a new approach it fails to communicate this on the landing page and focuses on code compression instead.

Fair enough. While it does touch upon `memoized DOM`, you're correct; it might not be sufficient for readers to grasp the full implications unless they're well-versed in these kinds of libraries. For a deeper dive, you can check out this subpage: https://imba.io/guides/rendering. BTW, I don't have any affiliation with this library whatsoever.

> I just wonder, whether a new language is necessary to achieve this.

To achieve compression, no. But to achieve DOM reconciliation without a v-dom, yes.