I’ve made a cjkv info app with eliom, the old demo version is here(most of its functions are turned off and hidden): https://cjkv.smaji.org/
It collects variation, source info, input method code of characters among China, Japan, Korea, Vietnam, Hongkong, Taiwan, ethnic minorities and ancient books. e.g.
https://cjkv.smaji.org/search/4ee4
https://cjkv.smaji.org/char_list?step=16&offset=184032&stop=191471&start=183984
Overall, eliom framework is fantastic. All the links are eliom_service, its parameters and itself are typed. Session manage is powerful and flexible. Components are reactive with each other, seamlessly between server and client. An app written in eliom is intrinsically an SSR SPA, an integral whole.
Writing an eliom app, all I want to say is: damn! it’s too good!
Cons:
- dune support
- merlin, ocaml-language-server
Your project is built by a manually managed Makefile and merln/lsp support is broken when you mix client/server code together in the same folder.
You only get these supports when you write standalone server and client separately.
But these flaws can be overcome. I wrote a custom code translator, which generates server code and client code from an eliom file into separate folders and make them still work together seamlessly. And in this case, I don’t need a Makefile, dune and ocaml-lsp works as normal projects.
- ocsigenserver
It’s good. But it updates infrequently and doesn’t keep pace with other libraries closely. Because eliom depends on it and its dependence constraint sometimes requires old libraries, better create a separate opam switch when working with an eliom project.
Wart
In fact, it’s not a wart of eliom. It’s lwt Memory leak under heavy load · Issue #545 · mirage/ocaml-cohttp · GitHub
That’s why I stop working on the old demo and now is rewriting it again with another tec stack.
…
If only eliom depended on lwt/async optionally and came with an official code translator to overcome the dune/lsp integration issue.