A demo project using Popcorn (Elixir in the browser)

I did a fun/experimental project using Popcorn, a library that lets you run Elixir in the browser!
It bundles your Elixir app with AtomVM, a minimal BEAM implementation, and runs it on a WASM runtime.

It’s a portfolio page (that will perhaps help me getting a job in Elixir which is not gambling or user tracking tech :sleepy_face:): https://marcin-koziej.cahoots.pl/
Source on Github

Thanks @mat-hek and the SoftwareMansion team for this impressive work!

Some thoughts and learnings:

  1. Early stage tooling: Popcorn is in active development, which meant I had to do some debugging, trial and error, as well as reading the Popcorn source code. The documentation could use contributions, but the examples provided with the source code are a great starting point.

  2. WASM vs non-WASM context: The bundled Elixir app runs on the WASM runtime, but running IEx or tests runs on a standard BEAM VM. In the BEAM, the NIF module required by JS interop isn’t available, so your code will raise :nif_not_loaded when using Popcorn.Wasm APIs. This means the interop code is best isolated, making it easy to mock out/disable for testing Elixir code or for interactive exploration in the IEx REPL (I do this a lot).

    Perhaps I could run tests and IEx on a WASM runtime in the shell? I didn’t explore this direction.

  3. Elegant JS interop: You can do GenServer.call and GenServer.cast from the JavaScript side to the Elixir side, and you can execute JS functions with arguments from the Elixir side. Popcorn provides an object proxy called Popcorn.TrackedValue, which is a reference to a value on the JS side (DOM node, object, string, etc.). When it’s garbage collected on the Elixir side (e.g., when the process holding it in its state stops), it will be released on the JS side. There’s a special cleanup callback you can use if cleanup is more complex. Basic Elixir types are converted to JS and vice versa (atoms are one-way converted to strings). Some types (like Pid or Reference) don’t work.

  4. Use cases: I have a feeling that for UI-heavy apps, there’s a lot of JS interop, which results in lots of small JS snippets scattered around your codebase (which is a liability because of #2). It probably makes more sense to put a “backend” Elixir app in the browser and use a more typical JS frontend framework to drive the UI. Migrating a web app into an offline-first desktop app comes to mind.

  5. AtomVM limitations: AtomVM doesn’t implement all BEAM modules, which generates non-obvious errors. For example, the timer_manager module doesn’t work, which means Process.send_after will crash your app. Same for Logger, which has a timestamp in its default formatting, which in turn breaks DynamicSupervisor (which does some logging by default).

    Generally, this work required a lot of printf-style debugging and trying out what works versus what will silently crash the app.

  6. Deployment: You can deploy to any static hosting which allows you to set COOP and COEP headers (latest security requirement to run WASM). These are not supported in Github Pages, so I am deploying to Netlify. The WASM assets sizes:
    31K static/wasm/AtomVM.mjs.gz
    190K static/wasm/AtomVM.wasm.gz
    3.4M static/wasm/bundle.avm.gz
    1.5K static/wasm/popcorn_iframe.js.gz
    2.9K static/wasm/popcorn.js.gz

Related:

Popcorn announcement thread

12 Likes

Hi @marcin, thanks for this write-up and the shout-out!

the BEAM, the NIF module required by JS interop isn’t available, so your code will raise :nif_not_loaded when using Popcorn.Wasm APIs.

I suppose you could mock Popcorn.Wasm with any mocking tool :thinking: We could also make it so Popcorn.Wasm isn’t available when compiling for the Beam so you can just provide an alternative implementation, if that would help. We use Playwright to run tests, and it works quite well. I think you could create an interactive shell backed with Popcorn running via Playwright too.

Perhaps I could run tests and IEx on a WASM runtime in the shell?

Using Popcorn.Wasm usually involves interacting with browser APIs, so I’m not sure how that would work in a pure WASM runtime :thinking: Anyway, AtomVM WASM only works with Emscripten currently. You can compile and run it for Unix though, if that helps.

It probably makes more sense to put a “backend” Elixir app in the browser and use a more typical JS frontend framework to drive the UI

Agreed, to make frontend development feasible, we’d need a framework on top of Popcorn. We’re currently experimenting with client-side LiveView.

AtomVM doesn’t implement all BEAM modules, which generates non-obvious errors.

The documentation could use contributions

Noted the Process.send_after, Logger should already work on Popcorn master. If you have more concrete examples what’s missing / not working, please share :wink: It’ll probably take time to fix, but eventually we’ll get there.

P.S. Hoping these efforts help you find a nice Elixir job :smiley: :crossed_fingers:

3 Likes

Hi Marcin,

It looks very interesting, but seems a bit fragile. I frequently ended up in this state when trying to run commands.

Still impressive though :slight_smile:

I know about this!
This is actually one small caveat I have not figured out yet properly.
I am using ExTTY module which will create a child process with IEx.

To make help() and other functions available, you give IEx a path to .iex.exs file. In WASM, there is no access to the filesystem, so what I do is evaluate import Portfolio.Helpers just after starting the REPL. However, I am not informed when IEx is restarted by ExTTY (on syntax error for example), and Helpers should be re-imported.

I am looking into doing Process.monitor() on one of the IEx processes, but still need to figure out which exactly process I should monitor.

edit
After a deep dive into ExTTY and IEx, I was not able to figure out how to monitor for IEx.Evaluator errors..What make it harder is that in WASM, some process introspection calls (Process.info) crash.
As for now I’ve added a hacky workaround to check for “Interactive Elixir” output that IEx is showing on startup, and import then :anguished_face:

Perhaps there is another way to do this?

1 Like