[recursive]

I was also influenced quite a bit by knockout. SSR was explicitly not a goal of mine. To me, SSR as a feature in a framework like this is mostly interesting in the context of server/client continuity like rehydration. But I have a feeling the constraints imposed by anything like this aren't going to be worth it. If I was doing pure server rendering, flat text templates seem like the sweet spot, since it's fundamentally not interactive. Render to html string and ship it. And if I was doing that, I probably would not choose to use javascript or observables/signals.

[WorldMaker]

Knockout was designed in the heyday of the "progressive enhancement" era so it seems hard for me to claim a Knockout influence/inspiration if I'm not at least contemplating "progressive enhancement" of some sort. SSR isn't really my goal on that front but progressive enhancement/SSG (static site generation) certainly is a side goal for me (that's what I would like to have to self-host my own documentation site in something resembling the framework itself, rather than Jekyll or Docusaurus or whatever), but again not a main priority. It feels like the case for me where there is a lot of bleedover between SSR, SSG, and progressive enhancement and solving one basically solves all of them.

> I probably would not choose to use javascript or observables/signals.

This seems to be a case where we differ. In one obvious part because I don't tend to like signals and think they are very different from observables (because they are harder to encapsulate and offer fewer operators and tend to bleed too many accidental imperative escape hatches). Observables, to me, are just as useful to describe "open this file, read its contents, convert it from Markdown to HTML, then bind it to innerHTML here" on the server side as "fetch this URL, read its contents, convert it from Markdown to HTML, then bind it to innerHTML here" on the client side. Very different forms of interactivity, but there is still an interactivity there that a good observable pipeline can describe. Especially when you start to get into the idea that the difference between "open this file" and "fetch this URL" is tiny and can be dependency injected. Same component, slightly different inputs, slightly different expected outputs (you expect the server side binding to complete, whereas you expect the client side one to live for some time and continue to respond to different URLs from input).

[recursive]

I don't know much about the state of the art SSR/SSG, but in my mind, a whole document can be built synchronously, with a depth-first traversal of the templates/components. From that perspective the power and the constraints of reactive UI seem like overkill and limiting at the same time.

But anyway, the more UI frameworks, the more ideas get out there, the better. I'm hoping that some day in my lifetime, web UI gets "solved" and I'm not willing to believe that React is the answer. Does your project have a name yet? I'll keep an eye out.

[WorldMaker]

Just because on most modern hardware file I/O has millisecond latency and feels synchronous doesn't mean it is synchronous. It might feel like overkill to use Observables instead of Promises and I/O event loops or even thread-blocking faux synchronous file system calls, but there is still an asynchronous world there where it can be nice to have the full power of Observables. To be fair, my love affair with Observables started in C# in "backend" applications, so that's always been the natural fit for me and frontend and UI work has been the "side hustle" of taking stuff that I love in the backend side of the house and putting it to even more use.

I'm calling my view engine Butterfloat, and I only just finished the first documentation pass, so be gentle, but feedback is very welcome: https://github.com/WorldMaker/butterfloat