

Curiosum
718 posts

@curiosum_dev
Elixir & React Native meets modern design | [email protected]



Most frontend code isn't UI. It's data plumbing - caches, sync, loading states, state management, and that's the short list. None of it is the actual product. That's the part Hologram's new data layer takes over. You say what the data should be, it keeps itself in sync in the browser, and offline just works. Pure Elixir top to bottom. I'm teaching it hands-on at ElixirConf US this September, a full day where we build a real app on it. The training's the day before my talk, so you'd build with the data layer before I unveil it on stage. Separate, limited ticket. Grab a spot here: elixirconf.com/trainings/buil… #Elixir #BEAM #LocalFirst #ElixirConf #Hologram






Hey Elixir friends, funny how getting a feature down to a simple one-line call takes two weeks of design work. Sharing what that looked like for Hologram realtime. One slice of the new realtime API - the call for "push an action to every client in a room": put_broadcast(server, {:room, 42}, "page", :append_message, message: msg) The full API is a handful of similarly tight functions for broadcast, subscribe, and unsubscribe. The diagram below is what it takes to set up the SSE connection underneath - and it's just one of six workflows in the design doc. I originally thought the realtime layer would be a thin server-to-client action push and nothing more. But a bare push API would have forced every app to roll its own membership tables or presence layer the moment they wanted something as ordinary as a chat room. That defeats the point of using a framework. Hologram Local-First (on the roadmap) will eventually own most pub/sub use cases - durable, ordered, DB-backed state. But channel-style fan-out has a permanent niche even after Local-First lands: typing indicators, real-time cursors, forced sign-outs - anything ephemeral or non-DB-backed. A pattern I keep running into building this framework: the simpler the public API, the more the framework has to absorb underneath. Most of that work is invisible to the people who'll eventually use it, which is exactly how it should be - but it's also why design like this takes longer than people expect. Anyone else here hit this trade-off building developer-facing tools?
















