Are there some nice real-time server side libraries leverage the latest advances of OCaml, such as Multicore Ocaml

The advent of Multicore OCaml is indeed an exciting development for our community. It stands to usher in a new era of parallel and concurrent processing, on par with, or possibly surpassing, what Erlang/Elixir offers. In particular, OCaml’s use of Ahead of Time (AOT) compilation, combined with runtime advancements such as the annotation of variables for stack allocation and the utilization of more efficient memory representations, opens up intriguing avenues for performance optimization.

Given these promising enhancements, the prospect of utilizing OCaml for web programming grows ever more enticing. On top of having convenient compile time checks, OCaml could power a highly performant server runtime, capable of handling millions of concurrent requests per second. This naturally brings to mind the potential for a robust library that enables real-time server-side rendering, wherein seamless and effortless communication between the client and server is facilitated. The Elixir’s LiveView library serves as an illuminating example of this concept.

The traditional request-response model of client-server architecture, while proven and widely used, does indeed present challenges and limitations, particularly for complex web applications. Here are some of the issues:

  1. Complex State Management: State management on the client-side can quickly become complex, especially for large-scale applications. Frontend frameworks often require additional libraries to handle state management, increasing the overall complexity and learning curve.

  2. Performance: Every time a client makes a request, the server has to process it, and send back a response. This round-trip, especially for large amounts of data, can result in latency. Caching and other optimization techniques are often necessary but add to the complexity and can still fall short of providing a seamless user experience.

  3. Resource Intensive: Traditional client-side applications can be resource-intensive on the client’s machine. This can negatively affect performance on lower-end devices and result in a poor user experience.

  4. Sync Issues: Keeping the client and server state in sync can be challenging. Any mismatch between client and server states can lead to inconsistent application behavior and hard-to-debug issues.

  5. Increased Network Traffic: Since the client frequently communicates with the server to update its view, this increases the network traffic, which can be particularly problematic for users with slow internet connections.

By contrast, real-time server-side rendering like the one Phoenix LiveView provides, while not a one-size-fits-all solution, offers several substantial advantages that can alleviate or even eliminate these issues:

  1. Simplified State Management: Because state is managed server-side, you avoid many of the complexities associated with client-side state management. The state is held in one place, on the server, reducing the chance of state mismatch.

  2. Efficiency: With server-side rendering, the server can do most of the heavy lifting, and the client is only responsible for displaying the HTML and minimal user interactions, making the application less resource-intensive for the client.

  3. Reduced Network Payloads: Server-side rendering frameworks typically only send the changes (diffs) to the HTML over the network rather than re-rendering entire pages or components. This approach can significantly reduce the amount of data sent over the network, improving performance.

  4. Real-Time Updates: Because the server keeps a persistent connection to the client, it can push updates to the client in real-time. This ability is especially valuable for applications that require real-time interactivity.

  5. Consistency and Reliability: Since the majority of the codebase resides on the server, this approach allows for more control and consistency, reduces the likelihood of client-side errors, and enhances application reliability.

Given these advantages, and drawing from my own experience with Elixir LiveView, I believe that the adoption of a real-time, server-side rendering approach can have considerable benefits for many types of web applications.

More specifically, an OCaml framework akin to LiveView could employ the following strategies to facilitate scalable and efficient communication between the server and its clients:

  1. WebSockets: These offer bi-directional, full-duplex communication channels over a single TCP connection, facilitating real-time updates between the client and server.
  2. Channels: Channels could be used to manage client connections to topics, broadcast messages to all clients expressing interest, and deal with incoming messages.
  3. PubSub: Leveraging OCaml’s built-in publish-subscribe system would allow for broadcasting messages to a vast number of clients.

With these strategies in place, clients of this proposed library could continuously update their views in response to changes. Diffs, outlining updates for the client view, could be transmitted via WebSockets.

I recognize that there is an existing platform, Eliom, which approximates the vision I am proposing. However, it appears development has slowed and it’s not achieving significant traction. Moreover, as far as I understand, it does not capitalize on Multicore OCaml’s benefits. It might be worthwhile to explore the implementation of a server-side rendering library that takes full advantage of Multicore OCaml’s capabilities.

I would be interested in hearing if anyone else in the community is currently working on, or considering such a project.


Imho you can get quite far along this direction today with the Dream framework on the backend and htmx on the frontend. Dream has not yet been ported to multicore, but it supports WebSockets today so there is nothing stopping using that. And htmx has a very similar server-driven philosophy to LiveView and even supports WebSockets on the client side i.e. it can get real-time streaming HTML fragments and swap them into the page.

It’s not a one-stop solution like LiveView but in the OCaml world things tend to be more modular anyway.


Ooo Dream seems to have a lot tools out of the box which is great! However, I don’t see a lot of tooling for the server side to make updates to the front end side for a certain session. Also, they don’t send updates as diff. It would be great to have these features for Dream.

That’s where htmx comes in, Dream on the server side renders HTML fragments + htmx on the client side swaps them in to the DOM. The server side fragments are not sent as diffs, but rather as pieces of valid HTML. But in practice the effect is the same.

It’s conceptually not the same as LiveView which is more ‘React on the server side’, but they do share some aspects conceptually.