I have started a series of OCaml Web tutorials. The idea is to try multiple libraries and see how they fit together. (But the Dream framework document and example set is quite good enough, I will not paraphrase it).
For the moment, I have only tried a Server Side Rendering, but I plan to try a Client Side Rendering where Ocsigen (and Vdom ?…) could be welcomed.
The idea is to propose a dummy application that use what most people would expect from a Web Framework (form handling, database accesses, …)
See OCam web tutorials
You can take an inspiration from the tutorial we made about vif, it shows you websocket stuffs at the end and include caqti and tyxml 
Another templating option is Mustache, which receives variables bindings as JSON, which could simplify debugging. In the end these differences are syntactic. The choice is mostly do you prefer to treat HTML as code (Dream, TyXML) or as HTML with some variables.
Yes with different templating library (even is TyXML, all is code, Dream templating, we have OCaml code interlaced with static HTML… and with Jingoo, no OCaml… All is a mix HTML/Jingoo code).
However, there is an huge different between Server Side Rendering (I have done) and Client Side Rendering (I plan to do).
I guess that pointers to other approaches can be interesting.
With dream-html there is another helpful structuring technique: route paths. You can define all your route paths in a single module and use them for both route handlers and for generating paths in templates.
The benefit of this is that you don’t have to hard-code strings like /orders, /orders/:id etc. in your routes and then again duplicate hard-code strings like <a href="/orders/<%Ld id %>" in your templates, you can use the same path variables to do both. This makes refactoring and changing routes really easy.
Here’s an example: GitHub - yawaramin/dream-html: Type-safe markup rendering, form validation, and routing for OCaml Dream web framework · GitHub
Excellent idea. But a good comparison will make sense only if it covers a large set of features.
Feel free to take inspiration from Ocsigen tutorials (there are plenty, server side, client-side, and client-server). For example, this one is probably the most interesting. It would be interesting to write it with other frameworks and make a comparison. The full code is here.
A server-side only comparison would also be very interesting, especially with session data and several steps forms.
And indeed interoperability is key. Reinventing the wheel with a small library is easy. Integrate well with the existing ecosystem is much harder. Let’s stop writing new frameworks every 6 months and start working together.
My example covers a sort of greatest common divisor, the set of functions we are sure to find in every project:
- Static files,
- Form,
- Templating,
- Database,
- Access right (the use of custom middleware bound to a dictionary is practical for it with Dream).
With all of these, we can consider ourself able to do many things… but sure, there will be some missing feature that can be required (Websocket…)