For now, I'm suspending new releases until I figure a new data-modeling strategy and util I'm generally satisfied with the quality of the library. The new releases will definitely be resumed in the new year 2026! 🎉😁
github.com/pinely-inter...

That's why now I will be focusing on providing more appealing and familiar way for data-modeling and state-management through React hooks and maybe something else. Only then I will switch back to "cosmetics", "ergonomics" and polishing.

I adopted Tama in different projects to see how well it solves problems where React fails and how it feels to use Tama. My conclusion: it's great, feels much better than React in terms of Freedom, but all-around reactivity is tedious at complex data structures, the state-management overall is nice.

With this, I made a decision to support both approaches, both signals and plain JS scoped updates.
For you, this just means React hooks will work in Tama (potentially any React components will work too). Though for me it means more work 🥲

I was questioning signals approach generally (which I like) and by watching React Dev Conference 2025, I understood that React gives (at least) familiar and nice data-modelling approach, which I like too.
I can't just ignore the fact that React nails it, whereas Tama focuses on different aspects.

Some planned issues were not completed because there was 3 weeks pause on this project due to other projects I'm engaged in.

Despite of this delay, I was constantly considering evolution options for Denshya and Tama, now I see clearly that mere renaming and documentation polishing is not enough.

Recently I joined Hactoberfest with this library and it was Very Generative, but still got some fun from it 🥹

The library is being renamed still, but here's a website
tama.denshya.dev

Not even mentioning React, it's not even comparable, it's very slow (~8x)

I think comparing English and TypeScript a bit awkward, no? 😆

Imaging losing count and shooting in the wrong time 😬

You may say, but it should MUST BE slower than others - NO! According to my performance measurements, it scores something between SolidJs and VueJs.

Did I miss something? Maybe I read internet incorrectly and everyone has already implemented all that (I found only Lit does a bit of DOM)?

I implemented 2 little plugins in Vite and Bun, so that SSR can resolve assets imports of the client app directly to the static build.

At this point I realized - it's Plug & Play SSR, it doesn't require dedicated SSR build (but a bundle map generated by plugin) and fully support browser environment