4 ms·

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

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 1y ago
when i see the hoops webdevs have to jump through, i want to just tell you to code in native, youd love it
- szajbus 1y ago
  ...and then jump through completely different set of hoops to distribute to multiple platforms
  - phkahler 1y ago
    GTK or QT take your pick.
  - skeezyboy 1y ago
    ...a recompile....
  - skeezyboy 1y ago
    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
    - gus_tpm 1y ago
      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 1y ago
        > You are ignoring all of the advantages of writing a web client. What are they exactly? Youve already mentioned distribution, but what else?
        szajbus 1y ago
        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 1y ago
        > 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
    - bartblast 1y ago
      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?
- ramchip 1y ago
  Do you also go to police officers and tell them how much more they'd enjoy being a firefighter?
- bartblast 1y ago
  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.

skeezyboy 1y ago

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

szajbus 1y ago
...and then jump through completely different set of hoops to distribute to multiple platforms
- phkahler 1y ago
  GTK or QT take your pick.
- skeezyboy 1y ago
  ...a recompile....
- skeezyboy 1y ago
  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
  - gus_tpm 1y ago
    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 1y ago
      > You are ignoring all of the advantages of writing a web client. What are they exactly? Youve already mentioned distribution, but what else?
      - szajbus 1y ago
        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 1y ago
        > 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
  - bartblast 1y ago
    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?
ramchip 1y ago
Do you also go to police officers and tell them how much more they'd enjoy being a firefighter?
bartblast 1y ago
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.