This sounds like a great effort! As Drab is approaching 1.0 it makes sense to start looking at the abstractions and building blocks that could be extracted. However, I caution working to strip things down too early. For the LiveView case, it’s definitely too early for us to start drawing the abstraction lines, since a lot of those abstractions we are still working to fully figure out Extraction is good where it makes sense, but going too early or too granular can slow you down or be a big maintenance burden, so I wouldn’t be too quick start stripping Drab down prior to 1.0. As things progress on the LiveView side, I’ll be happy to revisit common abstractions, but it’s too early on my side at the moment

Well, this would be more the side project, rather than stripping down Drab, but they should meet at the some point in the future. What I want to do is a kind of Plug for a server-side frontend processing, which anyone can use to do something like Drab, on any Plug or Raxx based framework.

I realize this is a big effort, as there are many things which Phoenix does for free, like PubSub. But wait, we can use PubSub as it is already extracted from Pheonix

The future of Drab itself is still unchanged, I will release 1.0 soon.

Things like Drab.Live, LiveView or Texas are Phoenix-based and obviously need to stay in the Phoenix world.

True, you don’t need Drut for Texas, as Channels are enough to push the changes back to the client. And because how it is done (operating over the template), Texas (and LiveView, and Drab.Live) with stay in the Phoenix world, no doubt.

This proposition is way more low-level, and thats why I wrote before started writhing. Maybe it is too early for such project? Maybe it is too much to re-write the great Phoenix Channels? Maybe it is too much to give developers exec_js instead of traditional websocket messaging? (did I just call websocket messaging traditional?)

Yes, Drab.Live only sends the small patches, but it is not doing the diff, but identifies where to change the page by marks which are done during the compilation process. The idea of diffing on the server is a way better I believe, and do not need a special engine. I just didn’t think about it, as Drab.Live evolved in time (for example, at the first step, it did not re-render the whole template, but rather executed small chunks of AST stored during the compilation).

Anyway, under the hood, Drab.Live sends the patches using exec_js. This is the part I want to isolate.

Absolutely true. But now, when I am reaching to graal of 1.0, it is a time to think about the future, this is why this post exist

I imagine one could write a framework (something like what @raza described above), based on Drut, but with the different approach to communicate back to the browser - from “sending messages to the browser” to “executing code in the browser”.