bartblast

Local-first is simmering! :)

There's Jido Assembly that uses Hologram under the hood: https://github.com/agentjido/jido_assembly

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.

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.

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).

Creator here. Quick context: Hologram lets you build interactive web apps in pure Elixir by compiling to JavaScript on the client side.

This release brings JavaScript interoperability - the most requested feature since the project's inception. Hologram's premise is that you shouldn't need to write JavaScript, but cutting yourself off from 3 million npm packages and hundreds of browser APIs isn't realistic. v0.8.0 bridges that gap: call JS functions, use npm packages, interact with Web APIs, instantiate classes, and work with Web Components - all from Elixir, with zero client-side latency.

AMA!

Gleam is written in Rust but compiles to Erlang (BEAM) or JavaScript - I mentioned the JS compilation in my previous comment. The WASM point was a response to your bytecode interpreter suggestion, not about Gleam.

Oh yeah, I remember! We'll get there :) Hope you'll give Hologram another spin sometime soon!

To clarify - Hologram's runtime is heavier than Gleam's, but that doesn't mean it's heavy. The compiler does tree-shaking, bundling only the code your app actually uses, so you're not shipping the entire reimplemented runtime to the browser.

As for the WASM bytecode interpreter idea - you'd run into the same problems I described in my earlier comment. Even a minimal interpreter compiled to WASM tends to land in the multi-MB range once you include enough of the runtime to be useful. You still can't touch the DOM from WASM, so every UI update crosses the JS bridge with serialization overhead. You lose the ability to surgically call native browser APIs (like built-in Unicode support) instead of bundling your own. And you lose readable output, which matters for debugging.

It depends on what you're doing. I've been in Elixir web dev for about 7 years and never really needed to write or understand Erlang, outside of my work on Hologram. That said, Erlang is always there under the surface - it "leaks" into Elixir in places if you look at the stdlib, and understanding it gives you a better mental model of the whole platform. I'd say you don't need it on a daily basis for most Elixir work, but the runtime and OTP are incredible pieces of engineering, and getting to know Erlang better will only make you stronger in this ecosystem.

Two big reasons: bundle size - few hundred KB uncompressed vs multiple MB already compressed with WASM. And the DOM lives in the JS world - WASM can't touch it directly and has to cross the JS bridge with serialization overhead every time.

On top of that, since the browser platform has different characteristics, you can surgically drop down to native JS functions instead of compiling and bundling everything. For example, things like Unicode code point databases are already built into the browser - no need to ship them in your bundle when you can just call into the native APIs. The compiled output is also readable which helps with debugging.

For web apps generally JS is the better target IMO - you want the smallest possible bundle and the app reacting as quickly as possible on load.

Both! Right now the focus is on enabling rich UIs with pure Elixir running in the browser. But eventually Hologram could be able to act as an Erlang node in the cluster as well.

Not currently, but expanding to Erlang is definitely possible down the road. I've actually been considering adding an Erlang compiler since some Erlang functions that the Elixir standard library depends on could be compiled automatically instead of being ported by hand.

Really appreciate it! Would love for you to give it another go - a lot has improved since then. If you run into any issues or have ideas for how things could be better, don't hesitate to reach out. Happy to help!

Thank you! The Elixir -> JS compiler is currently coupled with the framework - it's a custom thing, not a separate dependency.

Re the Gleam comparison: I don't know Gleam's implementation in detail so someone correct me if I'm wrong, but as I understand it - Gleam compiles to fairly readable JS with a minimal prelude, and deliberately treats the two targets as having different concurrency semantics. It doesn't try to replicate BEAM processes or OTP in JavaScript, instead using JS's native promise-based async. The upside is zero runtime overhead and clean JS interop.

Hologram takes the opposite approach - we're iteratively reimplementing the Erlang runtime in the browser, with the goal of having full semantic parity eventually. The tradeoff is a heavier runtime, but the benefit is that the same Elixir code can run on both server and client with consistent behavior.

Hologram's journey just took a significant leap forward: Curiosum is coming on board as the Main Sponsor, and I'm joining their team to work on Hologram full-time.

Hologram compiles Elixir to JavaScript to run in the browser, enabling full-stack development in pure Elixir - and soon, Local-First applications.

I'm deeply grateful to Curiosum's founders for believing in this vision and going all in.

Read more about what this partnership means for Hologram: https://hologram.page/blog/hologram-partners-with-curiosum

Great news for Hologram: the Erlang Ecosystem Foundation has awarded a stipend to support key development milestones!

I’m deeply grateful to the EEF for their support of the project vision.

Read more about what this means for Hologram and learn about the EEF’s mission: https://hologram.page/blog/hologram-awarded-eef-stipend

(Hologram compiles Elixir to JavaScript to run in the browser, enabling full-stack development in pure Elixir - and soon, Local-First applications.)

Hi Elixir friends,

I'm Bart Blast, creator of Hologram. I wanted to share an update that's been on my mind lately. For those unfamiliar, Hologram is a full-stack Elixir web framework that automatically transpiles Elixir to JavaScript, bringing the language to the browser, see: https://hologram.page

After nearly 3 years of full-time work on Hologram, I've reached a crossroads. I believed deeply enough in this vision to dedicate years of my life to it - and that belief has been validated. We're seeing real-world production use, endorsements from community leaders, and genuine excitement from the ecosystem. But to keep this momentum going, I need to find a sustainable path forward.

Right now, I'm working 60+ hour weeks trying to balance contract work with Hologram development. It's not sustainable, and frankly, neither the codebase nor the community deserves a maintainer who's stretched this thin.

I've put together a post that explains where we are, where we're going, and how you can help if Hologram's vision resonates with you: https://hologram.page/blog/seeking-sustainable-sponsorship

Even if sponsorship isn't an option for you right now, sharing the post or talking about Hologram in your networks helps more than you know.

Thank you for reading. Let's build the future of Elixir web development together!

- Bart

(Disclosure: I'm building Hologram)

You might find Hologram interesting for this use case - it transpiles Elixir to JavaScript so your UI runs client-side. No persistent connection needed, so no reconnection delays or error messages. Still write in Elixir, still communicate with the server when needed.

It's early stage with some rough edges, but there are already Hologram apps in production: https://hologram.page

Appreciate the suggestion! Yeah, I've picked up on that - technical posts definitely do better here. The dang's comment is a great reference. I've got some good material brewing, but right now I need to prioritize building over blogging. Will definitely share some technical deep dives once things are further along!

Yes, I'm Hologram's creator. Previous newsletter editions will be published online eventually – for now they're only sent to subscribers.

In the meantime, here are the best places to follow development and join discussions:

- Hologram forum: https://elixirforum.com/hologram

- Hologram Slack: https://elixir-lang.slack.com/channels/hologram

- Monthly newsletter: https://hologram.page/newsletter

- My X account: https://x.com/Bart_Blast

- My Bluesky account: https://bsky.app/profile/bartblast.com

I'm also planning to set up a Discord channel soon.

Hologram could be a great alternative! The roadmap includes offline-first capabilities with a local data store, automatic sync, and reactive queries. These features aren't implemented yet, but they're planned as core parts of the architecture. The goal is to make apps that work seamlessly without internet and sync when connectivity is restored.

Could you elaborate on what you mean by "not as integrated as in Gleam"? Are you referring to Hologram being a framework/library rather than a language-level feature? Or is it more about the developer experience - like tooling, compilation workflow, or how seamlessly it fits into the Elixir ecosystem compared to Gleam's native JS transpilation? I'd love to understand your perspective better so we can potentially improve that integration feel!

Hey Elixir family, process spawners, fault-tolerant friends!

My ElixirConf talk just dropped! See how Hologram is pushing the boundaries of what's possible with Elixir - building modern, interactive frontends without leaving the BEAM!

Check it out: https://www.youtube.com/watch?v=TVs2_TzHC3E

#Hologram #Elixir #ElixirLang #BEAM #WebDev #ElixirConf

Hey Elixir friends! :) Have you seen a physics simulation that's written in pure Elixir and runs in the browser? That's the kind of magic Hologram makes possible!

Hologram v0.6.0 is here, bringing production-ready features to the full-stack Elixir web framework! This release focuses on enhanced security, comprehensive form support, and improved reliability as developers gear up for production deployments.

Key highlights:

- Complete form support with synchronized and non-synchronized form elements!

- Enhanced security with CSRF protection and XSS prevention

- Action scheduling with delay parameters for smooth 60 FPS animations

- Cross-platform improvements with extensive Windows development support

- Compiler reliability improvements with smart locking system

Full release notes: https://hologram.page/blog/hologram-v0-6-0-released

Check out the Interactive Bouncing Ball Demo that showcases the new action delay capabilities with realistic physics simulation and smooth performance! https://hologram.page/demos/bouncing-ball

With over 360 commits since v0.5.0, this release significantly strengthens Hologram’s foundation for production use while introducing powerful new features that enable more dynamic and interactive applications.

Special thanks to my current GitHub sponsors: @absowoot, @Lucassifoni, @D4no0, @dblack, @sodapopcan, and @zachdaniel!

Support Hologram’s development: If you’d like to help accelerate Hologram’s growth and make releases like this possible, consider becoming a GitHub sponsor. Every contribution helps dedicate more time to new features and community support! https://github.com/sponsors/bartblast

Stay in the loop: Don’t miss future updates! Subscribe to the Hologram Newsletter for monthly development milestones, ecosystem news, and community insights delivered straight to your inbox. https://hologram.page/newsletter

Challenge Time! With action scheduling and delay parameters now available, what will you build? Animations, games, real-time simulations - the possibilities are endless. Show me what you create!

Thanks for the kind words! You're right about the offline-first benefits - that's definitely part of what will eventually be Hologram's local-first philosophy and it's on the roadmap (https://hologram.page/docs/roadmap).

I needed to get the performance to a usable level in v0.5.0 because the previous iteration was quite slow, and I was concerned about getting bad press early on (there was actually a previous HN discussion about Hologram's performance issues). The slowness also prevented implementing latency-sensitive features like the real-time pointer/mouse events you see in the SVG drawing demo - which are really Hologram's main use case. It's already blazing fast now, though I haven't squeezed max performance yet - there's still room for improvement.

There are still some high-priority features that need to be implemented first before tackling the local-first capabilities. The CRDT implementation in this release is part of the foundation for those distributed/sync features, but there's more foundational work needed.

Thanks for the kind words about the documentation! I'm glad it came across as clear - I put a lot of effort into making it accessible.

You raise an excellent point about route conflicts. I'm actually thinking about detecting these at compilation time and throwing an error with details about which routes are conflicting and where they're defined. That should catch these issues early and make them easy to resolve.

The best practices guide is definitely a great idea and something I've been thinking about. I already have some ideas regarding project organization and routing conventions, but I want to ship a few more core features first before diving deep into that documentation. Hologram really obsesses over developer experience, and comprehensive docs are a big part of that :)

It's awesome to hear you're enjoying the Elixir/Phoenix ecosystem! Three months in and already exploring different frameworks shows great curiosity. I'd love to hear how your experience goes with Hologram when you give it a spin. Thanks again for reading through all the docs and providing such thoughtful feedback! :)

Thanks! I looked at the PageSpeed Insights report you linked. Apart from the bundle size (which will definitely be optimized) and bundles caching, other performance issues seem to be related to the page content itself - specifically some analytics scripts and a large animation GIF that's contributing to the load time.

I do notice that the report shows 104 KiB transfer size for the runtime bundle, which I think is actually a relatively reasonable result for a modern web framework, though there's certainly room for improvement. The bundle size will definitely decrease substantially in future versions as I focus on optimization.

Also worth noting that the bundles aren't being cached properly yet, which is another thing the framework should handle automatically - that alone would make a significant difference for repeat visits. This one's an easy fix though.

Everything you've mentioned is noted and will be addressed! Thanks again for taking the time to run the analysis and share the specific results - having concrete data like this is really valuable for prioritizing improvements.

Yeah, it happened to my last submission too: https://news.ycombinator.com/item?id=44246672 (newsletter) - got zero upvotes after the rename. I was discouraged, but HN is too big a medium to just take offense and ignore.

The speed comes from Hologram's optimizations - efficient rendering, smart diffing, and just-in-time page prefetching. But it's really Elixir's fantastic primitives and metaprogramming that make this possible, enabling the entire code transformation approach through phenomenal productivity and developer experience.