I'm considering how to build an app that makes a modicum of sense, in a field of practice that has no discipline and an influx of young eager energy.

---

How I came to care.

I've been producing apps for around fifteen years, since I last checked. After my sophomore year in college, I spent the summer interning for Microsoft in Redmond, WA. I learned a bunch of bad organizational practices there, began immediately shirking my coding obligations (sorry, I remain unpersuaded that printer drivers in JavaScript is in any manner sensible).

On weekends, I learned to code web apps in Ruby on Rails, and that absorbed me for years through my employment at thoughtbot and Code for America.

At thoughtbot I picked up on the early wave of React, and then spent some months learning the core ES6 language, which I think is really nice, compared to the prior browser language-scape. By 2016 at Code for America, I began my obsession in deployment engineering, because Docker really began changing how apps are released.

This odd mix of skills dangerously increased my confidence; I assumed this was the pinnacle, all there was to know, and that I could bank on being ahead of the game, for the next decade or so. And then from 2016 - 2026, I suffered as much disillusionment as possible.

A former colleague from thoughtbot mentioned Elixir to me when I found her in Richmond, VA one day. She has since become a resident of Belgium and I miss her dearly, although I'm glad for the couple days we found for reunions on the East Coast.

Problem Space

Since learning of Phoenix and Elixir, I have gone through the basics. Really, using Elixir for web purposes doesn't really ...click... for me.

How come? Elixir was made to run on the Erlang base, made by the Ericsson telecommunications company, and used for linking thousands of phone relays to relay voice packets from one phone-handset to another; replacing clunky and laborious switchboards, and designed to minimize collisions or disconnections.

All that is to say, Elixir is supposed to happen at a deeper layer than the web. Using Elixir for web apps is possible, of course, and we have Discord and WhatsApp as primary examples of the possible scale the language can reach. Though... using something so capable to render HTML? Silly. Absurd.

Your choice.

Of course, how you choose to build an app is going to depend on your skills, your planned app, and the code packages you can use to build upon.

In Elixir, the package for building web apps is called Phoenix. Yes, [the package]. Python and Ruby both have macro-frameworks and micro-frameworks, but Elixir really has Phoenix only. People are beginning to discuss this problem. There happen to be more options for desktop gui apps, which is nice to consider as a future career arc.

• Emerge
• Scenic

So, Phoenix became popular and a marginal successor to Ruby on Rails, because of a Phoenix sub-package, called LiveView. LiveView in turn made possible LiveBook, which occupies the same niche as Jupyter. Especially remarkable is how LiveBook has learned to handle Python also.

So, because Elixir became popular for web apps, Chris McCord produced Phoenix and LiveView, and then all of the web programmers decided to bring in as many javascript frameworks as possible. Quick index:

• live_debugger
• live_select
• live_toast
• live_svelte
• live_monaco_editor
• live_react
• phoenix_live_react, perhaps different somehow?
• live_vue, annoying to all Elixir-focused podcast speakers.
• live_charts
• lucide_live_view, and similar packages for differing icon sets.

This is a sample from page one, Showing 1–30 packages of 201 total

I'll pause there, because perhaps you see how these packages are going. Eager coder says "sure'd be nice if my JS app could do more backend", and then copies all of their JS code into a package on hex.pm, a space that should be zoned for Elixir use - JavaScript belongs on NPM.

Old-school programmers may recognize this to be a coupling problem (see also).

Decoupling.

In my opinion, the place where such a solution seems to slip sidelong is simple to see. Phoenix Live View includes a module called Hooks, which nearly implies coupling by name alone.

Hooks.ts is a typescript file that compiles to javascript, which then runs in the browser - if you're on mobile, this means that the ~340 lines of code inside Hooks is running on your phone whenever you examine a LiveView-based app. That's simple enough, only... the purpose of this code is to package up other code and to synchronize it to the domain, the "Elixir Core" program based on Phoenix.

Three hundred lines of browser code is simple enough, and I've used hooks to bring in special UI - a specific calendar element from React. Sure is nice to be able to bind a specific user experience onto a specific back-end data layer.

Only, is this simple coupling any more? Or are we building many bridges, one for each JS package we depend on, repackaging the API from JavaScript through the Phoenix hook module, all so we can call up our database query before sending the user any of the HTML page? Are there too many of these bridges? Are they each a bridge too far?

Basic Shapes, Basic Approach.

Here we are, back at the name of this piece:

Elixir Core, Browser Edge.

Elixir is made to run as a mesh of relays, the "core" of the program. In telephonic phrasing, imagine how often an early telephone customer would have a chance to look at a switchboard. Zero. The telephone users should be able to ignore how their voices are being carried.

Similarly, the switches should probably make no bounds on how the end-user's telephone looks or functions. Our Elixir code should have roughly zero concerns with the packages or components used in the application pages. Besides, Elixir in the browser? More aspirational than functional.

So, as long as the relay and the home-phone agree on the messaging scheme, the packets on the cable, the coupling can relax. This happened, really, in telephony also. Two handsets that enabled encryption could exchange messages, without the relays in the middle able to unscramble them. Later, the relays needed no upgrades to connect internet modems, on the same line; thus the fun AOL dial-up tones, programmed into the CD-roms.

Elixir: choosing a proper dose.

[... more research needed ...]

Browser: Unencumbered.

[... more research needed ...]