We're in an interesting time where my framework/stack choice is now much less dictated by existing engineer expertise and more about fundamental capabilities in the framework and stack themselves.
I ended up building an agent orchestrator in Elixir and Phoenix, not because I love working in Elixir/Phoenix (I do, but I just don't write code by hand anymore), but because the BEAM/OTP capabilities genuinely worked more reliably and elegantly to solve our orchestrator challenges.
I see projects like Hologram potentially showing up as the right tool for the job much more often. The barrier to picking up a new tool/framework/stack is so low these days with agentic development, and it comes down to speed, capability, and reliability.
Ironically, I don't think agents are going to suggest anything like Hologram on their own, so it is still down to human engineers to push it into common use. That might be the biggest barrier to adoption: overcoming obscurity so that LLMs suggest it as a solution.
My framework/stack choice on the other hand is now much more dictated by the quantity and depth of existing literature on the internet about that stack.
does that really help? I have had llms fumble pretty simple stuff in html/css and probably that's what there's more information on the internet, while with simple packages/languages with clear cut semantics it seems to be much better, even if off some samples pasted into context.
[edit] the case was simply, write me an html landing page, with a navbar, a content area and a footer, make sure the content on each area doesn't extend beyond 1200px wide , make each container centered (paraphrasing)
I'm on the opposite side of this. With LLMs, I no longer feel the need to use crazy frontend frameworks and abstractions. I'm back to building static HTML with minimal JS (and ideally no build step). Instead of using Tauri/Wails for GUI apps, I just use Swift.
I no longer try to build everything around my choice of language.
right, you're using the tool for the job. author was reaching for reliability, re: OTP/beam. now we don't know if they actually needed it, but, you're saying the same thing to me
i see one person saying it is now cheap to support the new hotness, which previously would have been its own project, and another saying it has become cheap again to do things the boring-yet-reliable way that maybe didn’t used to scale so great.
I would be really excited to see this moving forward - saying as someone who uses Phoenix regularly (and likes it for the most part) and has used react, vuejs, and so on - even at the stage it's at is already a very promising DX with what looks like a very reasonable roadmap and clear intent.
Having elixir apps that can work seamlessly local-first would be amazing and take care of one of the only areas where phoenix can't completely cover out of the box, making things that today take a lot of glue code, and error prone, a matter of a few declarations.
It's an Elixir framework for cross-platform mobile apps — has a LiveView-like API and a React Native-like native UI layer. I'm working on a couple of apps with it, and so far it's awesome!
Mobile's part of the plan - one Elixir codebase across web, mobile and desktop, with local-first as the groundwork. Covered in the post and roadmap (https://hologram.page/docs/roadmap).
There's no easy out-of-the-box way yet. But you can do it today with JS interop as a workaround. For small files: read the file and send the bytes directly in a Hologram command payload. For big files: fetch-POST the file to your own Phoenix endpoint, or directly to S3 with a presigned URL (no extra endpoint needed, since presigning can happen in a regular Hologram command or in the page's initial state), then pass the returned reference to a command for processing.
A proper Hologram-way file upload is planned as part of a high-level forms abstraction, which comes after Local-First support lands.
Hologram author here. It's the opposite, really - the whole thing is built on web technologies. The compiler builds an IR from your Elixir code, analyzes the call graph, and spits out per-page JavaScript bundles. In the browser it's regular JavaScript patching the real DOM, and transport is plain HTTP (POST + Server-Sent Events) - no canvas rendering, no WASM. It uses Web APIs directly, and the goal is to make the whole Web API surface available from Elixir. The only thing being swapped out is the authoring language, same as with TypeScript or Elm.
We're in an interesting time where my framework/stack choice is now much less dictated by existing engineer expertise and more about fundamental capabilities in the framework and stack themselves.
I ended up building an agent orchestrator in Elixir and Phoenix, not because I love working in Elixir/Phoenix (I do, but I just don't write code by hand anymore), but because the BEAM/OTP capabilities genuinely worked more reliably and elegantly to solve our orchestrator challenges.
I see projects like Hologram potentially showing up as the right tool for the job much more often. The barrier to picking up a new tool/framework/stack is so low these days with agentic development, and it comes down to speed, capability, and reliability.
Ironically, I don't think agents are going to suggest anything like Hologram on their own, so it is still down to human engineers to push it into common use. That might be the biggest barrier to adoption: overcoming obscurity so that LLMs suggest it as a solution.
My framework/stack choice on the other hand is now much more dictated by the quantity and depth of existing literature on the internet about that stack.
does that really help? I have had llms fumble pretty simple stuff in html/css and probably that's what there's more information on the internet, while with simple packages/languages with clear cut semantics it seems to be much better, even if off some samples pasted into context.
[edit] the case was simply, write me an html landing page, with a navbar, a content area and a footer, make sure the content on each area doesn't extend beyond 1200px wide , make each container centered (paraphrasing)
I'm on the opposite side of this. With LLMs, I no longer feel the need to use crazy frontend frameworks and abstractions. I'm back to building static HTML with minimal JS (and ideally no build step). Instead of using Tauri/Wails for GUI apps, I just use Swift.
I no longer try to build everything around my choice of language.
right, you're using the tool for the job. author was reaching for reliability, re: OTP/beam. now we don't know if they actually needed it, but, you're saying the same thing to me
i see one person saying it is now cheap to support the new hotness, which previously would have been its own project, and another saying it has become cheap again to do things the boring-yet-reliable way that maybe didn’t used to scale so great.
Did you use something like Jido or roll your own out of curiosity?
There's Jido Assembly that uses Hologram under the hood: https://github.com/agentjido/jido_assembly
Also interested in learning more.
Release discussions:
Hologram v0.7.0: Milestone release for Elixir-to-JavaScript porting initiative - https://news.ycombinator.com/item?id=46982943 - Feb 2026 (29 comments)
Hologram v0.5.0 - https://news.ycombinator.com/item?id=44690158 - July 2025 (50 comments)
Hologram: A full-stack isomorphic Elixir web framework - https://news.ycombinator.com/item?id=42710376 - Jan 2025 (37 comments)
I would be really excited to see this moving forward - saying as someone who uses Phoenix regularly (and likes it for the most part) and has used react, vuejs, and so on - even at the stage it's at is already a very promising DX with what looks like a very reasonable roadmap and clear intent.
Having elixir apps that can work seamlessly local-first would be amazing and take care of one of the only areas where phoenix can't completely cover out of the box, making things that today take a lot of glue code, and error prone, a matter of a few declarations.
Hologram is a joy to work with. Local first support will take it to the next level. Bart is cooking.
Local-first is simmering! :)
Would be great for reviving LiveView Native. Perhaps Dockyard / Brian Carderella might be interested.
Not exactly that, but check out Mob: https://github.com/GenericJam/mob
It's an Elixir framework for cross-platform mobile apps — has a LiveView-like API and a React Native-like native UI layer. I'm working on a couple of apps with it, and so far it's awesome!
Literally just had Mob surface from a chatgpt (or Claude I forget) session and am really intrigued.
Neat, didn't realize this existed. I'm experimenting the Rust Crux (https://github.com/redbadger/crux) for this - uses the Elm pattern.
Mobile's part of the plan - one Elixir codebase across web, mobile and desktop, with local-first as the groundwork. Covered in the post and roadmap (https://hologram.page/docs/roadmap).
The only thing that's stopping me from trying this currently is file uploads.
Otherwise it's a really cool project
It can handle file uploads. What issue are you running into?
Last time I tried it (quite some time ago) it didn't have anything built-in for file uploads: https://github.com/bartblast/hologram/issues/228
I've tried to keep an eye on its development, but I don't think file uploads were mentioned yet (and there's nothing about them in the docs).
There's no easy out-of-the-box way yet. But you can do it today with JS interop as a workaround. For small files: read the file and send the bytes directly in a Hologram command payload. For big files: fetch-POST the file to your own Phoenix endpoint, or directly to S3 with a presigned URL (no extra endpoint needed, since presigning can happen in a regular Hologram command or in the page's initial state), then pass the returned reference to a command for processing.
A proper Hologram-way file upload is planned as part of a high-level forms abstraction, which comes after Local-First support lands.
I feel it would be better promoted if it included more images in the doc.
The things people do to not use web technologies.
Hologram author here. It's the opposite, really - the whole thing is built on web technologies. The compiler builds an IR from your Elixir code, analyzes the call graph, and spits out per-page JavaScript bundles. In the browser it's regular JavaScript patching the real DOM, and transport is plain HTTP (POST + Server-Sent Events) - no canvas rendering, no WASM. It uses Web APIs directly, and the goal is to make the whole Web API surface available from Elixir. The only thing being swapped out is the authoring language, same as with TypeScript or Elm.