I’m planning to write an app for macOS and choosing from several functional programming languages:
Elm (no experience at all)
Reason (experience with other ML languages)
Haskell (very fluent)
I ruled out Haskell/Gtk+ almost immediately because of Gtk+ unnatural look on macOS and right now considering Electron UI or similar technologies. After googling a bit it seems that there’s no up-to-date bindings/frameworks in Elm-land for native apps, while there’s a very strong competitor in Reason ecosystem. Maybe I’m missing something crucial and there’s no bindings required to befriend Elm and Electron UI? Or there are better alternatives to Electron UI? Does anyone have this experience at all?
Sorry if it is a dumb question - I did not write anything for browsers for ages and maybe misunderstand how Electron UI works.
Elm currently only targets web, and has no bindings for native UIs. If there’s something that lets you write native UIs in react, you may be able to wire that up.
Just to be clear: I’m not planning to write something that uses Cocoa, libc or something of that kind. I fully understand that Elm compiles down to JS and one would need a browser environment to run it.
Have you considered a PWA? It seems you can install them as desktop apps these days. So things like Electron are a bit out of date, i.e. there’s no need to ship a separate browser with your app.
I don’t think I’d say electron is out of date as PWAs don’t have any way of native file access or other similar APIs.
In that regard, I find Elm + Electron to be a really great combination. Particularly because you already use IPC to communicate between the front and back ends of an electron app so you’re already doing a lot of unidirectional messaging, similar to Elm ports.
There are some electron specific APIs that do not have an Elm equivalent BUT, those APIs are usually used at the edges of the app (interaction with the host system). I think you can use Elm’s port system in order to interact with those APIs without much trouble.
There is no Electron UI to my understanding. The UI is rendered using just regular HTML that you can implement in Elm.
You can take a look at elm-electron-todomvc for an example of how to do an app in Elm and wrap it in an Electron Shell.
If you could implement the app as a webapp, this solution should be sufficient. If the app has some kind of special needs in terms of performance, you might need something else.
I would also consider Elm + Electron to be a good choice.
For Macs, does anyone know the current status of this issue?
As I understand it, the plan is for Electron to make a new build that does not use private APIs and that should resolve it, but I do not really follow Mac things so perhaps someone here knows better where this is going.
I think that, in the long run, going native and using Reason/OCaml is more sustainable. The Revery library is being tested as the new way to write OniVim, a VSCode like text editor without the performance hits of Electron. I think that’s a great goal. Alternatively, you could try Brisk, which is developed by the same team I think. Also, I think going Reason/OCaml will satisfy you more as a programmer when coming from Haskell.
That’s a very interesting point of view, thank you. Could you elaborate on why you think Reason would be more satisfying when coming from Haskell? I’m asking because I had exactly the opposite reasoning when creating my list of options. IMO purity and syntax are two major things that make Elm much more similar to Haskell.
I think the purity and syntax of Elm are great! Not to forget the community! Especially when compared to something JS like as Reason.
However, my personal experience shows that, when coming from Haskell/Idris and being used to all bells and whistles, Elm can feel a bit limited sometimes. It requires you to rewrite code Haskell gives you for free by using type classes, especially in the case of Traversable/Applicative pairs for your own data types. I’m not sure how Reason/OCaml stacks up against this, so maybe I weighed in the wish for native to much…
If only PureScript had a good native option! Maybe by leveraging React Native or this other attempt? But that’s only for mobile I think…
Apps use native widgets on each of the supported platforms; you can use a JIT setup or do AOT; F# has a (for you) familiar syntax which is cleaner than OCaml’s and has support for all functional programming concepts you love, as hoger-order functions, pattern matching and immutability; you can use Elm’s model-view-update model; and it is more mature than the Reason/Brisk combi, which helps the developer experience al lot.
The only thing I’m still wondering about F# is, if there is a linter somewhere, that will warn me, as soon as I call a native c# api (as in mutations/not functional)
As F# itself is not a pure functional language (it allows mutation though mutable record fields and of course some object orientation to fit in the dotnet eco system) I don’t think such a linter would fit the language.
Btw: F# itself is as “native” as C#. They both compile to the same IL. It only happens to be that dotnet’s base libraries (Core, Framework) are written in C#.
So, I decided to start with a very simple plain webapp to learn about Elm ecosystem first. And then if I run across any problems I’ll likely do the main desktop app with Revery UI.
My primary reason to give Elm a try is because I think (or expect) that I won’t have to learn for too long, i.e. framework is tightly coupled with language and its promise about flat learning curve (especially with FP background) is very appealing because its a small side-project and I’m primarly a backend developer (with frontend background from early 2010s).
But I decided to keep an eye on Revery UI just because as a “native app framework” it ls super well documented and if at some point I’ll have any troubles with Elm+ReactNative coupling - I’m sure such issue won’t exist for Revery UI.
The planned project will open source so if by any chance I’ll accomplish both web app and native app - I’ll try to do a comparison as well.
I’m writing an Elm desktop app using Electron. In terms of getting these two started together - no special stuff needed! Remember, Elm is just JavaScript You give it a <div> and let it do its thing. Ports for all the interesting stuff like file chooser dialogs etc.
You give it a