framework VS yjs-sqlite-test

I'm working on a framework inspired by React/Next.js which turns Haml into Ruby. It's 100% server side, but it runs pretty fast. I'm currently working on a rewrite, I just wish I had more time to work on it.

https://github.com/mayu-live/framework

https://mayu.live/

Mayu, a server side web framework written in Ruby, inspired by React. Been working on it for over a year, and I'm currently doing a complete rewrite now that I have a better idea of how it should work.

https://github.com/mayu-live/framework

Mayu Live[1] has components, it works kinda like React. I have been thinking about making rdom[2] work with Rails but I got a memory leak to fix first. It's possible to do all this in Ruby though.

1. https://github.com/mayu-live/framework

2. https://github.com/aalin/rdom

Thanks, yes mayu.live is a close thing, but I looked at its examples, it's overcomplicated, if done a bit differently, the counter code it shows as example would be 3 times shorter. Nice experiment, same principle as LiveView, but not quite there.

I've been working on a React-inspired framework in Ruby [1,2]. It only requires a few kilobytes of JavaScript, and only includes the relevant stylesheets for each page. Works pretty well and I guess I'm in a rural area (about 90 minutes down the river from Iquitos, Peru) on a 4G connection.

I recently did another experiment [3] where each static DOM tree becomes a custom element, which also reduces the amount of data that needs to be transferred.

I should probably make a Show HN post soon...

1. https://github.com/mayu-live/framework

2. https://mayu.live/

3. https://github.com/aalin/rdom

I agree that full stack support is the missing pice that's need to make use explode. But I do think the current implementations will get there.

CRDTs are fairly unique in that you need them to be exposed very close to the front of your stack in order to capture user intent, but you also need support further back in your stack for merging, replication, and querying.

We have good front end support and there are multiple exciting projects building collaboration servers for them. What I think is missing is support in database, that's what I've been experimenting with (below). If you are building an offline enabled app, having the ability to generate diffs and merge in database enables easy multi document sync.

Also most general purpose CRDTs are a combination of JSON and XML like data structures, it's useful to be able to query the structures in your database. For example if you build a notes app that supports inline tags, if useful to be able to query and index those from within the XML like structure without having to dump the whole thing out at another layer of your stack.

Yjs Postgres: https://github.com/samwillis/yjs-pg-test

Yjs SQLite: https://github.com/samwillis/yjs-sqlite-test

(These are just early experiments, I'm working on a cleaner shared implementation with support for various SQLite bindings, and better querying)

Day job (contract): Massive overhaul of an antibody workbench for drug discovery.

Evenings: Building out a concept for a "YSQL" bringing CRDTs (Yjs) to SQLite and Postgres. CRDTs are great for real-time, but also awesome for offline for async collaboration. Using the same CRDT for both front end data structures and backend database merging seems to me to be a good combination. The plan is to build out some simple primitives first, then layer a SQLite (WASM in browser) <-> Postgres sync system on top for local copying and modification of datasets.

Proof of concepts:

https://github.com/samwillis/yjs-sqlite-test

https://github.com/samwillis/yjs-pg-test