CodeSync

Building Livebook Desktop by Wojtek Mach | ElixirConf EU 2023

Code Sync: Building Livebook Desktop by Wojtek Mach | ElixirConf EU 2023

Comments welcome! View the code-sync and elixirconf-eu tags for more Code Sync and ElixirConf EU talks!

5 comments

#code-sync #elixirconf-eu

5 747 5

2025-02-21 16:59:51 UTC

Most Liked

wojtekmach

Hex Core Team

Yeah, I’d say Burrito is focused on CLIs and ElixirKit on desktop apps. The idea behind ElixirKit is you write your native code yourself (AppKit on macOS, Windows.Forms on Windows, etc) and it ships with APIs for both frontend and backend to talk to each other (over a TCP connection). I believe Burrito compiles NIFs for you so it’s easy to talk from Elixir to C/Zig but my understanding is it doesn’t have higher level APIs to do that built-in.

Burrito creates a single (self-extracting) binary whereas e.g. on macOS an app is an .app bundle, a folder, with particular structure. Commonly you distribute these as .dmg files that you need to code sign and ideally notarise too. ElixirKit ships with some simple scripts to automate these steps.

One of the biggest benefits of Burrito is cross-compilation. If there’s a cross-platform GUI toolkit in C/Zig then I believe it would be super compelling. I’m personally pretty wary of these toolkits though.

I think it’s totally possible to build a desktop app with Burrito and if someone tries that, I’m very much looking forward to the results.

ElixirKit is still maintained within Livebook repo. I plan to eventually extract it out as a standalone library but no ETA yet.

Post #3

linusdm

Thanks for sharing those experiences @wojtekmach !

I see you had some PR’s in the burrito project. Would you mind pointing out if there is any overlap between what you described here regarding Livebook, and burrito?

At first glance the way Livebook is packaged requires maintaining some native code (which you show in the talk), while burrito handles this transparently.

Or are these two approaches for two different problems?

I don’t think the ElixirKit code has been extracted into it’s own reusable library yet?

Thanks in advance for sharing some insights.

Post #2

andyleclair

One of the biggest benefits of Burrito is cross-compilation. If there’s a cross-platform GUI toolkit in C/Zig then I believe it would be super compelling. I’m personally pretty wary of these toolkits though.

What about the cross-platform GUI toolkit that ships with Erlang?

Post #4

Last Post!

andyleclair

Ah yes, sorry, I realized that after I posted (and that I was posting on a year-old thread). What I meant was: should we put effort into improving what we have in OTP with wx and raw opengl, or do you think we should try to create something else from scratch?

I also find the idea of native desktop apps written in Elixir very compelling (especially with cross-compilation in the mix). I agree with your statements in the talk that wx is very large and complex, but seeing what Mitchell Hashimoto has done for cross-platform GUI in Zig and what the Zed people have done in GPUI makes me think that any cross-platform GUI solution is necessarily going to be pretty complex. That is, unless we go the way that Liveview Native and ElixirKit have gone with driving native UI implemented in the lingua franca of the platform?

Post #6