The ultimate goal is to incorporate processes and supervision on the client side as well. Remember, Rome wasn’t built in a day, and we have to start somewhere 
Even if processes turn out not to be feasible on the client, I still see significant value in this approach: the development team doesn’t have to use JavaScript, and there’s no need for hooks or something like the JS module in LiveView (or Alpine JS, for that matter). Even if Hologram was only a subset of Elixir (which it won’t be, since the entire syntax will work, except for “receive”), this opens up new frontiers. See what NX could achieve with a similar approach. Not to mention all the advantages related to managing the state on the client instead of the server (check it out here: Hologram - full stack isomorphic Elixir web framework - #17 by bartblast).
Besides, I don’t believe that processes will be particularly helpful with this client/server component architecture (except for background file processing). This is because the client will only be used for managing the UI (with JavaScript/DOM being inherently single-threaded). Hologram will intelligently know which code runs on the client and which on the server, so you won’t have to create separate modules for each of them—it’ll be kind of seamless. I know it might sound a bit abstract, but I hope this will be clearer once I create a demo app.
