Helix - Visual AI Agent Workflow Designer

React’s complexity ramps up fast. Not so much in building UIs—that part’s fine—but once backend auth and coordination come in, things get heavy.

I’m considering giving LiveView a try. By cutting most of the frontend-backend communication, it could make handling complexity much simpler. I’d keep React Flow in play through LiveView hooks.

I tried moving things to LiveView, but looks like a full migration would eat up too many hours, and React’s already running stable. I did hit some weird lag—dragging a node made the connection line duplicate until I refreshed. Could just be how I hacked it together in the spike. My guess is the LiveView way here would be to leave the fast UI bits (dragging, animations) to JS, and let LiveView just handle the events/state.

Sticking with React, for now. I probably can migrate later after having it “finalized” with all major features working needing just minimal polishing.

Screenshot 2025-09-22 at 21.53.281200×740 43.7 KB

Released minor patch updates to add login and signup functionality. Currently refining the OTP design to ensure maximum resilience. The intended use case is for teams to host this repository internally as a service to design and orchestrate AI agents.

Hologram? Although I have no idea if it plays well with the fast amount of JS libs for charts and client UI interactions.

Good point! If there’s specific JS library integration needed, it’s probably worth waiting for the JS interop that’s coming soon. But besides that, the charts and the whole UI could actually be implemented in pure Elixir if you choose to go that route.

No need to leave the “fast UI bits” to JS when you can handle dragging, animations, and all the interactive parts directly in Elixir on the client side

I hadn’t come across Hologram before — looks like a really interesting project. If I understand it right, the idea is to write code using an Elixir macro and have it translated into JavaScript? I’m a fan of DSLs, but I’m a bit on the fence since I’d still need to memorize the Phoenix/LiveView DSL, which has changed a lot over the past few years. Touching the bare bones isn’t always bad

Thanks for sharing interop.

Mixing Elixir with JS doesn’t seem like a bad compromise. Most libraries try to hide the JS layer so people can ejoy typing Elixir code, but I actually like to understand what’s going on under the hood.

However i’ll go with entire LiveView or other Elixir libraries next time. I’d need time and energy to rebuild the entire thing in LiveView specially in an early stage without any users or contributors.

I can share my 2 cents here. I’m the author of live_vue library, and I’m mixing live views with frontend frameworks on a daily basis for more than a year

All in all, LiveView plays nicely with JS frameworks when instead of rendering HTML it synchronizes top-level props to the frontend component and handles selected client-side events in the same way as in a regular LiveView. That way you get both of two world - your live view handles routing, data fetching and updates, and your frontend handles client-side state, rich interactivity and is free to use any library from a selected ecosystem. You might want to read that post.

Personally I’ve built entire SaaS product https://postline.ai that way - each of my live views renders just a single vue component. It’s similar to IntertiaJS, but uses LiveView behind the scenes.

There’s also live_svelte and live_react. I think my library is the most feature-complete, but since your frontend is written in react it might be the easiest to migrate.

Good luck, hopefully it will be useful!

Thanks! these are really good options. Maybe the only downside on having it entirely in React (without LiveView) is that I might get less people interested on contributing? I’ll take a look at those libraries you mentioned. Live Vue seems like a great one! I see what you mean when talking about LiveView hooks complexity. Probably why I gave up the migration saga to LiveView because I ended up creating a huge hook with a lot of submodules.

I think there might be a small misunderstanding about how Hologram works. You don’t need to use macros or learn DSL at all. Hologram lets you write regular Elixir code that gets transpiled to JavaScript - so you’re working with pure Elixir.

The JS interop page I mentioned is specifically for interfacing with existing JavaScript libraries client-side when you need them, but the core framework doesn’t require any JS knowledge.

Speaking of workflow builders, Aldous Waites built a great Hologram interactive demo with snappy, draggable graph nodes that showcases how smooth client-side interactions feel in Hologram. The implementation is surprisingly clean - what would require complex JavaScript coordination in traditional approaches becomes straightforward Elixir code.

Since you’re working on a visual workflow designer, this demo might be relevant to show what’s possible with Hologram for that kind of interactive UI! The dragging, real-time updates, and visual feedback all happen smoothly on the client side, written entirely in Elixir.