The Holy Grail of Isomorphism: Packaging Elixir for Desktop Apps

Transcript

1. The Holy Grail of Isomorphism: Packaging Elixir for Desktop Apps Evadne Wu Elixir Enthusiast ev@radi.ws twitter.com/evadne
2. Myself Aspiring Bodgemaster Elixir Programmer (etso, packmatic, shun, etc.) Cocoa/Touch Programmer (DayFlow, LiveFrost, etc.) Inquiries: ev@radi.ws Arguments: twitter.com/evadne
3. 1 The Problem
5. The number of technologies we have to learn is too damn high.
7. 2 The Environment
11. 3 The Accident
17. y
22. 4 The Stuffing
23. Electron (Simplified) Chrome Mac App Node.js Server
24. How about this? Web View Mac App Erlang Server
25. Prior Art: Nerves WebEngine Kiosk https://github.com/nerves-web-kiosk/webengine_kiosk
27. Prior Art: iErl
28. Prior Art: iErl iErl https://github.com/couchbase/iErl An embeddable, statically-linked BEAM No NIFs No JIT
29. Optimisations & Tradeoffs Non-Native, Web-Based UI, but normalised after a decade of Web 2.0 development Non-Standard Tooling, but with a much smaller conceptual space and customisability Non-Specialised BEAM VM, but with rock-solid, predictable performance and stability
30. Today’s Approach Create an Elixir Project with Phoenix, in the normal way, with some Endpoint customisation for port-finding and self- termination Create an Xcode Project for macOS, with a WKWebView and a Task that starts the Server Create an Elixir Release and have Xcode copy it into the Application Bundle
31. Miscellaneous Storing data locally: Either use sqlite3 / sqlitex from Elixir side or use Local Storage from JavaScript side. Synchronising with the server: Use whatever existing APIs you have — as you are running a full BEAM node.