new | show | ask | jobs Github

bartblast 6 days ago

Hologram is essentially a competitor to LiveView. Here's the key difference:

LiveView: Renders UI updates on the server and sends them to the client.

Hologram: Transpiles your Elixir UI code to JavaScript that runs entirely in the browser.

You'll appreciate Hologram when you want to avoid LiveView's latency. For example:

- Instantaneous UI interactions without client-server roundtrips

- Real-time interactions like smooth drawing, drag-and-drop, or complex animations

- Offline-capable applications that work without constant server communication

- Reduced server load since UI logic runs client-side

If you need truly responsive client-side interactions or want to reduce server roundtrips, that's where Hologram shines. It's the same Elixir developer experience, but with client-side performance characteristics. Think of it as "LiveView for when you need the UI to feel like a native app.

Note: Currently Hologram requires Phoenix, but in the future you'll be able to run it as a standalone framework.

▲

skeezyboy 4 days ago | parent [-]

when i see the hoops webdevs have to jump through, i want to just tell you to code in native, youd love it

▲

bartblast 4 days ago | parent | next [-]

I totally get the appeal of native development! But for many of us, we genuinely love coding in Elixir and want to use it everywhere we can.

Elixir brings some incredible advantages: the Actor model for handling concurrency, fault tolerance, pattern matching, functional programming paradigms, and honestly just a really enjoyable developer experience. When you're already building your backend in Elixir and loving it, being able to use the same language, mental models, and tooling for the frontend is hugely appealing.

It's less about avoiding native development and more about 'I already know and love this language - why not use it everywhere?' Similar to how JavaScript developers felt when Node.js let them use JS on the backend, or how Swift developers felt when SwiftUI came along.

▲

ramchip 4 days ago | parent | prev | next [-]

Do you also go to police officers and tell them how much more they'd enjoy being a firefighter?

▲

szajbus 4 days ago | parent | prev [-]

...and then jump through completely different set of hoops to distribute to multiple platforms

▲

skeezyboy 4 days ago | parent | next [-]

yeah, how in the world are we ever gona update a binary in 2025... is this really still an issue? webdevs try to make GUI software in a browser for one reason; they can only code in web languages. Basically, if all you know is a hammer, everything looks like a nail

▲

bartblast 4 days ago | parent | next [-]

re: "What are they exactly? Youve already mentioned distribution, but what else?"

Here are the key advantages of web clients beyond distribution:

Instant updates - Push a new version and every user gets it immediately. No app store approval process, no waiting for users to update, no supporting multiple versions in the wild.

Universal accessibility - Works on any device with a browser. Your grandmother's old Windows laptop, your coworker's Chromebook, someone's phone - all access the same application without platform-specific builds.

Zero installation friction - Users can try your application instantly by clicking a link. No download, install, permissions, or disk space considerations.

Sandboxed security model - Browsers provide built-in security isolation. Users trust clicking web links more than downloading and running executables.

Seamless integration - Easy linking, sharing, bookmarking. Users can send a direct link to a specific state of your application.

Lower development/maintenance overhead - One codebase, one deployment pipeline, one set of bugs to fix. Compare that to maintaining separate iOS, Android, Windows, Mac, and Linux builds.

Built-in networking - HTTP/WebSocket APIs are first-class citizens. No need to bundle networking libraries or worry about firewall configurations.

That said, native absolutely wins on performance, system integration, and offline capabilities. It's genuinely about picking the right tool. For Hologram specifically, we're trying to get you closer to native performance while keeping these web deployment advantages - best of both worlds for certain use cases.

▲

bartblast 4 days ago | parent | prev | next [-]

I appreciate the perspective, but I think you're mischaracterizing what Hologram is about. We're not web developers who "can only code in web languages" - we're Elixir developers who've deliberately chosen Elixir for its technical merits (fault tolerance, Actor model, pattern matching, etc.) and want to leverage that investment across our entire stack.

Your hammer/nail analogy actually supports the case for Hologram: if Elixir is genuinely a superior tool for building systems, why shouldn't we extend that tool to work client-side too?

Native development absolutely has its place, and for many use cases it's the right choice. But there are legitimate scenarios where you want the reach and deployment characteristics of the web platform combined with client-side performance. That's exactly what Hologram provides - it transpiles your Elixir UI code to JavaScript that runs in the browser, giving you instant interactions without server roundtrips while keeping the language and paradigms you prefer.

Binary distribution isn't technically hard in 2025, you're right. But "not technically hard" isn't the same as "optimal for every use case." Sometimes you genuinely want instant deployment, universal accessibility, and the ability to update your application without user intervention. Different tools for different jobs.

I'd actually love to hear what you think about Hologram's transpilation approach specifically - writing Elixir UI code that gets converted to JavaScript for client-side execution. Does that change the equation at all from your perspective?

	▲	skeezyboy 4 days ago \| parent [-]
		Where does this Elixir lang rate in terms of performance against say Rust or Go? I noticed its run through a vm but also recommends itself for embedded?

▲

gus_tpm 4 days ago | parent | prev [-]

You are ignoring all of the advantages of writing a web client. Are you really saying that distributing a native app for every platform is better than writing something that uses the browser?

▲

skeezyboy 4 days ago | parent [-]

> You are ignoring all of the advantages of writing a web client. What are they exactly? Youve already mentioned distribution, but what else?

▲

szajbus 4 days ago | parent [-]

Well, distribution is the killer feature. More, it's inherent property of the platform (web).

Web devs are in full control of their whole stack (excluding the browser where you occasionally need to account for incompatibilities), have to maintain only one version of the app (no upgrade needed on client-side), are not constrained by the platform owner's policies (app store tax).

Yes, it's more limited than native technologies in other ways, so it's not an answer for every problem.

	▲	skeezyboy 4 days ago \| parent [-]
		> have to maintain only one version of the app (no upgrade needed on client-side) Except what happens when it doesnt run the same on Firefox as it does on Chrome? Or what about when Edge is run on Win7 and youre app doesnt render correctly? Yes you only code one version of an app, but you are still obliged to consider the underlying platform - which is exactly compile once, run anywhere is it? its more like compile once but make sure you test it on all the different browser/OS combos before you do. Distribution aside, its more likely you only know web languages and THATs why youre coding your project on the web stack. Pick the best tool for the job

▲

phkahler 4 days ago | parent | prev | next [-]

GTK or QT take your pick.

▲

skeezyboy 4 days ago | parent | prev [-]

...a recompile....