search

pkamenarsky / concur-replica

Server-side VDOM UI framework for Concur
BSD 3-Clause "New" or "Revised" License
139 stars 20 forks source link

JS FFI #7

Closed seagreen closed 4 years ago

seagreen commented 4 years ago

I mentioned concur-replica to the Unison folks, who thinking about alternatives to their current terminal-based codebase manager program.

It has some characteristics that make it a good fit for their problem, mainly that since it would be run locally latency to the "server" wouldn't be an issue.

The other alternative would be something like TypeScript or GHCJS. I think concur-replica has huge advantages over those for this use case, but one thing it's missing is JS interop. Tools like D3 in the JS world are so far ahead of anything we have in Haskell that it would be really useful to be able to integrate them with a concur-replica program.

Do you think it's worth brainstorming how this might work?

seagreen commented 4 years ago

Related to https://github.com/pkamenarsky/concur-replica/issues/6, since it's a possible solution for that issue too.

pkamenarsky commented 4 years ago

Definitely, a general purpose JS FFI is the first step towards better integration with the rest of the JS ecosystem, especially since many things are harder to fit into the declarative VDOM paradigm, i.e. access to IndexedDB etc.

Something like:

eval :: String -> Concur Value

which would just send a JS string over to the client for it to eval() and send back the result.

For integrating JS components though there might be a better way: exposing a simple JS API for registering components on the client. Such registered components will then receive attribute updates from the server (for example D3 chart data), similar to how the VDOM gets updated now. The custom JS code must take care of translating those attributes into imperative statements which will bring the component into the desired state.

Also, JS components can send a selected set of events to the server (i.e. no need to send a D3 mousemove event, but clicking on a bar might trigger an app-specific action, so send that over), again, similar to how replica works now.

This would require writing "bindings" for JS components, but still, that's a one time thing and is still much more general than building specific client-server communication protocols for every app.

seagreen commented 4 years ago

Awesome, that makes a lot of sense to me. I'll chime back in here when I either have new thoughts (I'm certainly a noob at this frontend stuff) or if I start on a prototype.

pkamenarsky commented 4 years ago

Added a prototype implementation in 4bac1002a9127ba605901014798f1d2f8af34eb5.

seagreen commented 4 years ago

Awesome. Feel free to close this! We can open new issues as we think of new improvements.