August 10, 2026
Web Village Technology Choices
Why Phoenix, Elixir and Liquid
Web Village is a multi-tenant, white-label website platform with a federated social layer. That shape rewards a specific stack — one built for concurrency, isolation, and safe customization — far more than the defaults reach for.
Six requirements fall out of "many client sites, each customizable, talking to the wider social web." Every stack choice below answers one or more of them.
- Isolation - Many client sites, each with genuinely separate data.
- Simple editing - Resellers & non-developers customize templates without running code.
- Concurrent I/O - Feeds, federation, cross-posting, media, AI — lots at once.
- Reliability - One tenant's bad data can't take down the others.
- Rich admin - A full editor without needing to call in developers
- Efficiency - Many tenants per server; bootstrapped economics.
Elixir runs on the VM built for many small, independent things at once
Elixir compiles to the BEAM — the Erlang virtual machine, forged in telecom for systems that stay up while thousands of independent connections come and go. That heritage is exactly the workload underneath a federated, multi-tenant platform. Where Ruby/Rails and PHP reach for external machinery to approximate it, the BEAM makes it the grain of the language.
| Elixir / BEAM | Ruby / Rails | PHP | |
|---|---|---|---|
| Concurrency | Millions of lightweight processes, true multicore parallelism. | Threads throttled by the GVL; parallelism via more OS processes. | Process-per-request; no concurrency inside a request. |
| Background work | In the VM. Fan-out is free; Oban adds durability — no broker required. | Sidekiq + Redis, a separate worker fleet. | External queue / cron + Redis; nothing survives the request. |
| State & cache | ETS, PubSub, Presence built in. The feed cache lives in-node — no Redis. | Multi-process → externalize to Redis. | Stateless by design → externalize everything. |
| Fault tolerance | Supervised processes restart; one failure stays isolated. | Request-scoped rescue; workers need outside supervision. | Request dies on error; no long-lived supervision. |
| Real-time UI | LiveView over persistent sockets, state on the server. | Hotwire / Turbo — HTML over the wire, lighter. | Livewire or hand-rolled JS bolted on. |
| Efficiency / cost | High concurrency per node — fewer, smaller machines. | Scale by adding processes & RAM. | Cheap per request; concurrency & state return as infra. |
The pattern: everything Rails and PHP solve with a queue, a broker, and a cache server, the BEAM solves inside one running system.
Phoenix LiveView - A real-time, full admin
The entire back office — the block editor, the page tree, drag-to-reorder, inline field edits, live validation, even the "is this owner email already an account?" check as you type — is LiveView. Interactivity is server-rendered over a persistent WebSocket, with state held on the server. There is no separate JavaScript app, no API layer to keep in sync, and no frontend build pipeline.
- vs React/SPA: no duplicated client/server state, no API contract drifting from the UI, no framework churn to chase.
- vs Hotwire & Livewire: genuinely stateful interactivity, not just HTML fragments — the server holds the live model of what's on screen.
- It rides the runtime: each live session is one lightweight BEAM process, so thousands of concurrent editors cost almost nothing.
- Both rendering modes, one codebase: public sites stay server-rendered (fast, cacheable, SEO-clean); the admin is live.
- Room to grow for free: collaborative editing, live preview, presence and notifications come from PubSub/Presence already in the box.
For a small team this is the decisive multiplier: one language, one codebase — features ship without hiring a separate frontend discipline.