[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.

[sesm]

From what I see, it vaguely claims to create so-called ‘edit maps’ at compile time, similar to Svelte and million.js. It doesn’t say anything about the algorithm it uses to generate them and what limitations their algorithm puts on application code. I’m planning to do a little research and a blog post on ‘edit maps’, I’ll probably include Imba there too.