Desktop GUI app with Elixir?

There is this little comment in the documentation (on the very bottom, the last code snippet) JavaScript interoperability — Phoenix LiveView v1.2.5 that explains how to interface with existing JS (in that case AlpineJS). I found that bit of code somehow cryptic but I used it as is and it’s working..
If someone has more links about that dom: and window.___.clone part I definitely want to learn more about that..

@ityonemo @elcritch I don’t have much experience with Front-end frameworks but I played a little with Vue and more recently with Svelte.
But I guess that it might be easier to do this (attaching liveview with some front end code) with Svelte.. Because there is no VDOM or complex runtime code.
Also, Svelte for example has some option to do server-side hydration, so I guess that it could be possible to use liveview to update not only some data but even the views of Svelte components.

Again I’m not that expert in Front-ends but I’ll definitely try some experience soon..
Already tried SS hydration with regular SSR Phoenix..

Anyway, I’m interested in that topic and waiting to read more from you guys!

Lot of work to be done but you can give this a try:

https://github.com/crqra/webview

I can work on it if there’s interest.

haha, alas no. I should’ve been clearer. I use LiveView with a browser in kiosk mode. Though, I do think it would be awesome to use react-native with LiveView. I think it may be possible to hook up, but not sure… it depends if the JSX calls are translated to a vdom that LiveView’s mdom library could modify.

According to this SO answer it looks like react-native does create a vdom. However that vdom has a bunch of shadow nodes specific to react-native. It wouldn’t be impossible to use, but it may require a lot of effort copying react-native JSX functions. Though someone could write a macro that’d parse a JSX view into a LiveView template (it’d probably not be too hard to convert 90% of JS expressions into Elixir equivalents probably, then hand tuning to fix the rest). That post links to https://www.youtube.com/watch?v=8va9prUqjnA as a more detailed source on the internals of react-native.

So if one were to do it it’d probably require:

• Get Nodejs setup with websocket to phoenix
• Configure mdom to work on the vdom instead of a real DOM (might have to override some document.querySelector(…) calls)
• Setup LiveView templates to create the appropriate vdom to match react-native outputs from JSX
• Ensure react-native starts but doesn’t actually modify the vdom, so get the reference to it’s root vdom (somehow)

Then who knows if it’d break on every react-native update or not.

wait, you’ve attached liveview to react native? That’s kind of amazing. Do you have a reference to how one does that?

I’ve been tempted to do exactly that. It’s what I use for IoT devices essentially. LiveView makes it much saner, but it’d be way cooler if you could use react-native somehow. As in LiveView modding vdom and re-using react native bindings.

You will probably find this Proof of Concept relevant to your interests: GitHub - fazibear/elixir_desktop_application: Code for story: https://puddleofcode.com/story/how-to-create-desktop-application-with-elixir · GitHub (the startup instructions, although default are correct)

Which is powered by GitHub - nerves-web-kiosk/webengine_kiosk: Qt WebEngine-based kiosk · GitHub which runs with qt webengine. Of course that is different than electron, and may be more difficult to install. But on a machine that has qt installed, running mix phx.server will bring up a desktop window that loads http://localhost:4000

It would be interesting to see if someone could create a new Proof of Concept by adding bakeware to the above.

As much as I hate electron, I think if someone figured out how to bundle electron with elixir (possibly via bakeware) it would be really cool, even if it’s not much more than a proof of principle.

That process reminded me of the old Yehuda Katz project, Tokaido:

I can’t believe that was 8 years ago now!

I think for most use cases you can consider spawnfest/bakeware which packs a single executable which contains a launcher and an embedded archive.

I’ve indeed been toying with the idea of building an entirely independent Mac app bundle that is compatible with Sandboxing etc and around the existing Elixir releases concept. Since I don’t know how to write applications well for Linux / Windows I’ve focused on Macs. A particular concern that came up pretty quickly was handling of dynamically linked libraries, which I have had to manually relocate and then rewrite the entries in shared libraries within the release via a build script. So far the solution works for OpenSSL and I am sure will work with most libraries, but it has been quite an ugly experience so more thinking and studying is required to simplify it.

I have tried this approach with a Phoenix app and a Scenic app and more or less things work and I could put the app bundle on another machine and it works properly. (Usually Erlang is installed on top of OpenSSL installed via Homebrew on Macs so a simple Elixir release won’t work on other Macs without Homebrew / OpenSSL.)

For Windows, the same technique which was used to build portable apps could probably be used. I’ve not studied how though.

@evadne teased this cool project recently: Evadne W. on X: "Nice https://t.co/bXXNP8ejsY" / X (mac only I assume)

@ConnorRigby has also been doing some stuff to get native/cross platform flutter going coner @PressY4Pie@fosstodon.org on X: "Another late #NogginDay. Spent the afternoon working on @elixirlang + @FlutterDev #myelixirstatus https://t.co/CwdRA0PByM" / X