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

8 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:

2 Likes