Library for GUI?

Language-built GUIs also tend not to look very good. GUIs need to integrate into a given OS (or in the case of Linux, a desktop environment), and thus need to have special case handling for every OS in order to look like native applications. This is one of the reasons Electron has taken off – the web is now ‘native’ to every OS, and thus applications made using the same ‘GUI’ elements as the browser tend to look like they belong on every OS.

What is your evaluation of only-web-based GUI? (security, usability, etc. )
See other discussions about web vs. desktop GUI.

In which specific cases would you make the choice of a desktop GUI instead? (possibly not looking like the OS GUI)

And it is awful scenario if user has more than one program to run. Good luck running Slack, Nylus, Chrome/Firefox, Visual Studio Code and whatever Electron-based simultaneously on middle-range laptop. Especially if you have more than one site/project opened. Using Qt-based bindings is a way to go (in some cases GTK+ too). Electron is a curse for humanity and it works only in the imagination of developers who think that user going to run only their program and not a hundreds others.


Electron is an amazing way to make an IRC client take gigabytes of RAM. It’s a cool stunt that it works, but it isn’t exactly a boon to mankind.


@jamie I want to do it. I’m wrapping up a new version of Logarion and then starting it.

(I’ve also promised to tidy up some OCaml-QML bindings I’ve worked on)

I’d not be sharing this until there was something tangible, but I don’t want the hope to die :slight_smile:

1 Like

It worth noting that OniVim (Electron-based GUI for Neovim) recently decided to switch to the native GUI, creating Oni2 project

They use Revery UI platform for Reason language.

1 Like

I always thought that Electron is heavy because it has HTML engine inside it. Looking to the Revery README it seems that it will have the same issue too. Why Revery will be better?

1 Like

Revery doesn’t have any HTML rendering engine. Everything is compiled with ocamlopt and render with OpenGL/WebGL


Ah, thanks! I have seem react-like core in the readme, so I decided that HTML is somehow used there too.

P.S. Can somebody explain why the folks are inventing the wheel with new OpenGL GUI library instead of using Qt/Qml?

P.P.S. I got a crazy idea. It would be great to transpile ReasonML syntax to Qt/Qml to reuse existing components. Reactive programming will work out of box, we will get rid of untyped javascript in Qt/Qml. Obviously it will be adopted only if folks afraid only about untyped nature of javascript in Qt|Qml

With lablgtk and lwt_glib, i can do asynchronous applications. Is it possible with Qt/Qml or revery?

1 Like

Integrating with an async framework (Lwt/Async) is being worked on. But from the architecture point of view, nothing prevent you from doing so. This model have been proven in React.js framework.

At the heart, there is a reconciler called brisk-reconciler. It takes the JSX which is desugars into a bunch of nested function calls + the current state of the world and returns a set of updates to a tree.

The renderer (revery) would render this into OpenGL scenes. Or brisk would render this into native components.

The asynchronous problem is totally separated from the framework. It just needs proper integration


As @thangngoc89 said, nothing prevent you doing that from architecture point of view. I tried some demos where GUI in QtQml and OCaml are separated to different threads, they are able to communicate. To be more precise you can implement any concurrency API in any language and expose it to Qt/QML side as your functions.
But for simple things the XMLHttpRequest is built in.

The more I think about Revery, the more I like it. What’s a good path for an OCaml programmer to get started on this?


I’m pretty excited by it, too. I haven’t been able to get it building on my Mac so far, not sure why. One problem I’ve had is that currently you need to use esy to build, not just opam.

Maybe it would be good to have a new thread for Revery so it doesn’t get buried in a general GUI thread?

1 Like

Currently, esy is a requirement because the libraries to built it wasn’t published anywhere (not npm, not opam)

In the last few years I have been developing a GUI for (and in) ocaml, as a hobby project.
Finally, I have made the current state of this thing (called “bogue”) available on github, see

Just in case some of you are interested in having a look.
Comments welcome, of course.


Is “bogue” in opam? It would be interesting to try it…

not yet, but this is the plan. I still have to figure out how to do this. It should be easy, since locally, I already have an opam package on my computer.
Yesterday I tried the ‘opam publish’ script, but it fails with
[ERROR] Uncaught exception: “/usr/bin/git fetch --multiple origin user” exited with code 128
I guess I’ll have to do it manually. Any help welcome.

You might want to ask for help with the packaging in a distinct discuss thread.

1 Like

I just made a video to show some of bogue’s features: