The point is not to focus on the desktop or not – a localhost webapp may actually do the trick.
The point is to bring the right tool and experience to your user and for that I’m afraid to say, your developer comfort or wishes matter very very little (and if you are not comfortable with what it entails to do the best just don’t take the gig, I did more than once).
I don’t really understand the economics of the clients that you are working for. Let’s say an average engineers salary is $100k, to be conservative, I don’t see how one or a few users of some custom built software can sustain that engineer or engineer(s). I have only seen sustainable, maintained software when there are 100s or 1000s of users. Once you hit 100s of users, you need to think about efficiency of delivery and updates. I think the reason most software is delivered through the web, remotely, is simply to accommodate this reality. I guess slack and other companies have managed to deliver desktop applications to windows which aggressively update themselves, but I imagine it was hard to reach that level of update automation.
There’s a world outside SaaS, finance, blockchains, the startup scene or other businesses based on screwing your users by sucking out their data with their misinformed consent.
A world where you don’t need to scale but where small custom tools can significantly improve the life of your users or make new projects possible for them (and if you write them right you won’t need to update or maintain them every 5 min ;–). That’s the way I think about computers: a device to help humans, not a device to make programmers rich.
But that was not the point… The point was while I’m personally not enthusiastic about Windows as a platform I still have interest, case arising, on being able to deploy OCaml binaries to it.
I am regularly developing desktops apps (including a GUI with lablgtk) on Windows mainly because that’s the target the user has. So, in many cases Linux (or WSL) is not an option, as there is no (mature?) cross-compiling toolchain. Anyway, I would better put development effort in improving Windows support (as mentioned in this and other threads) than going for the cross-compiling path, which won’t be beginner-friendly anyway. My personal feeling is that Windows support is already quite good with OCaml for Windows, but I have quite some experience with Unix, which the mediocre Windows user probably does not have. I think the Linux/Unix „feeling“ of the current OCaml toolchain on Windows („Cygwin“) is what many newcomers distracts and causes frustration.
Given the limited resources, e.g., compared to the Rust community, I think the OCaml devs & community did a really good job on the Windows side and is pretty aware of the weak points and tries to address them (I am thinking of the recently release docker images for instance).
(Sorry for going off topic here. I’ll start a new thread if I really feel the need to keep discussing these topics after this post.)
I think we are much more similar in our goals and histories than this thread might lead you to conclude. I would hesitate to paint all SaaS and startups existing purely to enrich themselves. I have spent considerable energy trying to find exceptions to this overall direction. Here are some interesting ones:
The point was while I’m personally not enthusiastic about Windows as a platform I still have interest, case arising, on being able to deploy OCaml binaries to it.
I can agree with this.
I on occations uses jupyter-notebook(1) with Ocaml to test things, when utop(1) doesn’t make it. I am looking into useing Org-mode with Babel to avoid jupyter.
Thanks for the words of encouragement. I can tell you that even without smashing everything into one binary, we are working hard towards better integration between these tools. Yes, tools like cargo are inspiring and offer us many important lessons in usability. But it’s important to note that other communities (Scala, C++) have come up with tooling that is both powerful and modular. In my opinion, we should strive to follow their model and offer a graceful path for the evolution of tooling that maintains long term compatibility.
I’m surprised, @rgrinberg, you’re the first person I hear give any praise to C++ build systems :-). On the other hand, a lot of people profess their love for cargo. I certainly hope dune could grow and fill more of the use cases of cargo.
I also wonder what you mean when you talk about Scala 
the only mainstream build tool there is sbt, which is much closer to cargo in design than to dune+opam. You could make the argument that there’s also Coursier which is like a lower-level opam, but users are mostly not exposed to that directly, and almost always use sbt.
I’d be curious what you meant by such tooling for C++ ? I personally think Make is great stuff, and bazel is even better, but … surely you didn’t mean those tools ?
Re: C++
Certainly not make. I know very little about bazel unfortunately.
Last time I used cmake it was quite good. There’s a ton of features that work across a multitude of compilers and IDE’s. I quite like how it’s able to source package sources from the internet using git or http urls. I’d like to steal that feature in dune someday. The only downside is that the DSL itself is nothing less than a disaster. I hear the alternatives to cmake such as meson are pretty good and libraries as a rule are usable no matter what build system is used.
Re: Scala
Last time I checked, mill and gradle were credible alternatives to sbt. More importantly, scala libraries remain fully usable no matter the build systems. Not to mention the java compatibility is quite as well.
Mill/gradle/bazel/Fury/etc. are certainly alternatives, but sbt remains the only mainstream build tool, the lingua franca, so to speak. And believe me, I wish there was a faster, less bloated tool. I sorely miss the speed and efficiency of opam+dune in Scala. But I don’t miss having to assemble the project piecemeal from multiple config files each with its own format