Loading…
Topic
Phoenix LiveView
10 posts about Phoenix LiveView. Every summary links to the original.
- 10 posts
- 1 company
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Logbook: October 29 to November 6, 2022
This weekly logbook covering October 29 through November 6, 2022 reports updates across Elixir, Postgres, Laravel Livewire, Redis, and Fly Machines. Chris McCord describes how React inspired Elixir LiveView, while revamped Elixir documentation and Livewire tutorials cover client-side pagination, grouping, sorting, and browser notifications from the server. Fly’s revised Postgres documentation distinguishes the tools it provides for provisioning and managing a cluster from the responsibilities customers retain, and points readers to managed Postgres services. The Fly Redis dashboard command opens the Upstash Redis console with instance statistics and connection instructions, while a Fly Machines preview supports defining multiple processes to run inside one container; the log also notes updated documentation and a required CLI version update.
How LiveView Took on a Life of Its Own
Phoenix LiveView began as an attempt to build dynamic server-rendered applications without writing JavaScript, using the server for interactions such as realtime reservation updates. Its initial design used stateful Phoenix Channels, a WebSocket connection, client event bindings, and full template re-renders sent back as HTML, a model that worked but produced redundant server work and large payloads. Adding Phoenix PubSub let LiveViews subscribe to reservation events and update all connected browsers through ordinary Elixir callbacks, without client changes. The implementation then evolved around diffing dynamic values, shared static template references, and cached live component templates, reducing transferred data and avoiding growing client bundles. The post concludes that this programming model sidesteps HTTP for dynamic features, with compact payloads and less client-side code.
Accessibility and Real-time Apps: Clearing Fog and Picking Fruit
This post describes an initial accessibility pass on LiveBeats, a Phoenix LiveView reference app with real-time social features, focused on screen reader users before real-time updates are introduced. It recommends labeling meaningful controls and images with visible text, alt, SVG desc, or aria-label, while hiding decorative imagery with aria-hidden="true" or blank alt attributes. It then explains that semantic HTML such as button, main, nav, and article is preferable to ARIA roles where available, while named regions can improve navigation and orientation. Roles also create behavioral obligations: a role="button" control must support focus and Enter or Space activation, and role="application" can force focus mode, blocking caret-browsing conveniences unless the app supplies comprehensive interaction behavior. The initial work clears foundational accessibility issues, with later work reserved for presenting live changes accessibly.
Accessibility for real-time web apps
Accessibility for real-time web apps argues that accessibility should be treated as an ongoing design and engineering process rather than a late checklist, using blind developer Nolan Darilek’s experience to frame the subject. It explains why reducing interaction barriers benefits everyone, why disability can be temporary or acquired with age, and why teams should plan for access needs from the beginning. Recommended practices include automated checks such as Deque’s Axe DevTools, live audits, testing with people who have specific access needs, and hiring people with disabilities without making one employee solely responsible. The post then identifies Phoenix LiveView challenges in LiveBeats: dynamically loaded routes need transition announcements, live regions need careful updates, and dropdowns and modals require keyboard-accessibility work.
Turbocharge your Heroku Apps with New Turboku
New Turboku clones a Heroku app on Fly.io without requiring data migration, while the resulting app should be able to use services such as Heroku Postgres or Redis through transferred environment variables. The rebuilt workflow integrates flyctl with Fly.io’s remote builders instead of AWS CodeBuild: it queries Heroku, selects a region, converts config variables to secrets, and generates fly.toml, an ephemeral Dockerfile, and a reconstituted Procfile from the slug and process map. A Phoenix LiveView web launcher wraps the deployment by starting a Fly.io Machine running flyctl, while the CLI is available through flyctl turboku. The launcher also configures webhooks and watches environment-variable changes for automatic updates, whereas the CLI lacks webhook integration; the source reports about one millisecond of added database latency for a US-based app.
LiveBeats: Building a social music app with Phoenix LiveView
LiveBeats is an open-source social music application built as a full-stack Phoenix reference app and learning test bed for LiveView features. It demonstrates a shared real-time UI for playlist playback, presence, GitHub OAuth, and concurrent MP3 uploads, using Phoenix PubSub and the existing LiveView WebSocket connection rather than separate REST, JSON, or polling layers. Uploads are processed concurrently in temporary files to verify MP3 validity and enforce a duration below 20 minutes, while HEEx function components and slots provide reusable UI and JS commands keep immediate interactions such as modal hiding on the client. The application runs across five continents with automatic clustering, file proxying, and regional Postgres read replicas; the post presents this as a way to deliver responsive global behavior with relatively minor changes.
How Safari Ruined My Tuesday
Safari 15 introduced an obscure CSS bug that made pointer-events: none persist in LiveView applications. LiveView uses connected and disconnected modes, and its default app.css had included .phx-disconnected * { pointer-events: none; } to disable interaction while disconnected. In Safari 15, the rule could remain effective after reconnection or class changes, leaving links and buttons unresponsive even though the web inspector reported pointer-events: auto. The workaround removes pointer-events: none from app.css, although LiveView already ignores clicks on Phoenix links and buttons while disconnected; LiveView 0.17 instead uses a different disconnected-state class. The change avoids applying the faulty rule from existing user-land CSS while retaining custom loading-state styling, and the post says a Safari Development Preview build might fix the underlying bug.
How We Got to LiveView
Chris McCord recounts how Phoenix and LiveView emerged from attempts to make real-time features as simple as Rails CRUD development. He first built sync.rb, which used WebSockets to re-render server-side templates and push HTML updates without requiring programmers to write JavaScript, but Ruby’s concurrency model and EventMachine proved unreliable for the task. He then turned to Elixir and the Erlang VM, whose lightweight message-passing processes and fault tolerance supported Phoenix Channels and a reported load test of 2 million concurrent WebSocket connections on one server. LiveView unifies client and server state in a stateful process that synchronizes only necessary HTML changes. The account also describes binary uploads, WebSocket-based navigation via live_redirect and live_patch, and HEEx, an HTML-aware Elixir template syntax with compile-time validation.
Building a Distributed Turn-Based Game System in Elixir
Mark Ericksen describes building a proof-of-concept distributed, clustered game system for turn-based multiplayer applications with Elixir and Phoenix LiveView. Rather than separate JavaScript and API layers or external state systems such as Kafka and Redis, the design uses server-rendered HTML over websockets, Phoenix.PubSub, and Horde’s distributed process registry. A player’s LiveView sends moves to a GameServer, which publishes updated game state so subscribed LiveViews re-render for every connected player; Tic-Tac-Toe supplies the model. Hosted on Fly.io, geographically close web servers connect over a private WireGuard network while a game’s single GameServer remains the source of truth, with libcluster handling cluster formation and healing. The resulting open-source proof of concept supports multiplayer games, four-letter game codes, on-demand creation, responsive updates, and globally clustered servers.
Low Latency LiveView
LiveView sends HTML fragments over a WebSocket connection, allowing Phoenix applications to update the DOM in response to server or user activity. For interactions such as a like button, however, a server round trip can make feedback feel slow: a sub-100ms sequence may be acceptable, while many interactions benefit from responses under 40ms. The post presents client-side state prediction as one remedy, where the browser displays an expected value immediately and later reconciles it with the server. Its preferred “boring” alternative is reducing round-trip time by running application processes near users in multiple cities, connecting Phoenix instances over a private network and enabling clustering. A seven-region Counter deployment is shown with fly regions set and fly scale count 7, while Phoenix.PubSub and Phoenix.Presence handle clustering transparently.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.