This is more of an HTMX native

Yeah, the moment I read "Serve your app as XML" my brain instinctively began to move on but it's really just HTML-like semantic snippets that remind me of WebComponents. Example:

https://github.com/Instawork/hyperview/blob/master/demo/back...

However, this warning statement should be in bold at the top: "If your app relies on offline data or local computations, Hyperview won't be the right choice."

For that reason, I lean toward https://volt.build/

A key distinction here is that Hyperview is free, which makes the offline capabilities or lack thereof a more than reasonable tradeoff IMO.

Volt looks great, but $15/mo. for the basic plan, $37/mo. for the pro plan that you likely need for the ad hoc builds alone (unless you test in prod).

If it doesn't do offline data or local computations what is the point?

It’s frustrating that this is necessary but it definitely makes sense, and I will probably add it to several projects soon.

Thanks for your hard work!

Thank you! Please raise any issues if you encounter any, or have any feature suggestions!

You can connect and run SQL, but there’s no built in support for versioning, testing, and rolling back DDL.

Very excited about this and it’s future!

We always have been

You can do this with Materialize or Feldera. The keyword to look for is “incremental view maintenance”

What happened with PostgresML?

If they don’t have firing / hiring power, they aren’t management according to US labor law.

Most tech “* manager” roles where the object of management is not a person or team likely qualify.

It’s not in core, but there are multiple extensions that provide this functionality

As someone who: - would love to self host, and would much prefer keeping it to Postgres / Redis for which there is widespread knowledge on how to host - would like you to keep your development velocity up

I'd encourage you not to switch databases, or at least to defer this for a while. I can't imagine you'll have issues with the amount of WAL written for quite a while, and by that time, the world could be quite different (OrioleDB might be mature! https://github.com/orioledb/orioledb)

I should have been more explicit.

I do not intend to change the Postgres database or introduce a new one. I’m sure this won’t be an issue for the majority use-case.

However, I am open to learning more about alternate ways to efficiently handle Yjs state updates, which may be useful for a cloud version that would run at scale. If I were to go that way, it would not affect self-hosted users and would probably be via a reference pointer and not a database switch.

This is absolutely not an issue at the moment. Nothing to worry about.

MyRocks speaks MySQL. It’s just a different storage engine behind MySQL, replacing InnoDB. The major change I can think of would be replacing the `uuid` type with `bin(16)`, and needing to do the encoding and decoding in the app.

Re: development velocity, IMO there’s a solid base product now. I feel like it’s a great time to make a solid change to help future velocity, but I’m not OP.