I've been working on a framework in Ruby for a few months. It's kinda like React but server side, it streams DOM-patches to the browser, and it uses Haml templa

I've been working on a framework in Ruby for a few months. It's kinda like React but server side, it streams DOM-patches to the browser, and it uses Haml templates. It's super easy to work with and I don't know what to do with it. It's also full of minor bugs but I think the architecture isn't too bad, because it's been easy to rewrite different parts in isolation and replace them (I think I've rewritten the server 5 times by now). I'm running it on Fly's hobby plan and it's been working really well, I really like using their stuff. I feel like server rendering is something that will become very common. It's becoming easier to deploy apps near user, and it's easier to keep state on the server (and you can talk to your database directly instead of having an API between, which is probably the greatest win). Here are some examples from what I've been working on... Simplest component possible: %div Hello world With CSS: :css .hello { color: fuchsia; } .hello Hello world With state: :ruby def self.get_initial_state(initial_count: 0, **) { count: initial_count } end def handle_click(e) update do |state| { count: state[:count] + 1 } end end :css .counter { border: 1px solid fuchsia; } .counter %p Count: #{state[:count]} %button(onclick=handle_click) Increment Since latency is so low, you barely notice that the app is running on a server instead of in the browser. CSS class names are scoped to the component and the stylesheets are loaded lazily when the components render, and with HTTP/2 everything loads in parallel. Asset filenames are based on their content hash so they can be cached easily. That HEEx syntax looks really interesting though. What I didn't like about LiveView and HotWire was that it didn't feel like React. Now maybe LiveView will feel more like React.