bartblast

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.

Hey jamauro, good to see you here! :) Appreciate it. The offline work is going to be fun to implement - looking forward to seeing what kind of apps you create once that's ready!

Thanks! I completely did the same thing again - didn't explain what Hologram is. To be fair, the admins changed my title from "50x rendering speed improvements in Hologram (Elixir web framework)" to just "Hologram v0.5.0", but still... need to work on that! ;)

That's odd - I've tested the site multiple times previously and consistently got LCP results between 0.12-0.40s on large pages, which I consider very good results. I just tested it again on a large page using the Google Chrome Performance tab and got 0.14s LCP. I'm testing on the production site, connecting from Warsaw.

The 1.5s LCP you're seeing is quite different from what I'm observing. Performance can vary significantly based on location, network conditions, and device capabilities, so perhaps that's contributing to the difference in our results?

It's also possible that different pages have different performance characteristics depending on their content complexity and the navigation structure. Could you share which specific page you tested? That would help me understand the discrepancy better.

Regarding the runtime size - it hasn't been optimized at all yet, so I expect it will be much smaller in the future. I wouldn't be surprised if we can reduce it by a few times through proper optimization.

You're absolutely right that for a pure documentation site, a no-JS approach with prefetching would be lighter. The Hologram docs site is indeed dogfooding - I wanted to showcase the framework's capabilities and stress-test it with real-world usage, even if it means some overhead for this particular use case.

The goal was to demonstrate the instant navigation experience you mentioned, plus features like client-side search and interactive examples in the future that benefit from the stateful client-side architecture.

Thanks for taking the time to test the site and provide this feedback!

Wasmex is an interesting project, but there's an important distinction to clarify: Wasmex isn't actually a compiler that would transpile Elixir to WASM. Instead, it's a bridge that allows you to call existing WASM modules from Elixir code running on the server/BEAM VM.

Even if we had a hypothetical Elixir-to-WASM compiler, I believe transpiling to JavaScript offers several advantages for Hologram's use case:

- Bundle size: JavaScript bundles are much smaller since we only transpile the code that actually runs on the client, rather than shipping an entire runtime.

- DOM access: WASM doesn't have direct DOM access - it still needs to go through JavaScript APIs. This creates an additional communication layer and overhead for every DOM operation, which is frequent in UI frameworks.

- Communication overhead: The boundary between WASM and JavaScript has performance costs for frequent data exchange, which would impact things like event handling and state updates.

- Debugging experience: The transpiled JavaScript code remains readable and debuggable with familiar browser dev tools, making development much more pleasant.

- Selective transpilation: We can leverage high-level JavaScript functions and browser APIs directly instead of having to transpile every single operation from scratch.

- Performance: For Hologram's use case (UI logic, state management, event handling), the performance difference between JS and WASM is negligible. WASM really shines for CPU-intensive computations, which isn't our primary bottleneck.

The JavaScript approach gives us the right balance of performance, bundle size, and developer experience for a client-side UI framework.

Yes, absolutely! Hologram can work on top of Phoenix and coexist peacefully with LiveView in the same app. You can have some routes handled by LiveView for server-rendered interactions, and other routes handled by Hologram for client-side interactions that need to work offline or on low bandwidth. The session data is shared between them, so users can seamlessly move between LiveView and Hologram pages while maintaining their authentication state and other session information.

This is actually a really nice migration path - you don't have to rewrite your entire app. You can gradually move specific features to Hologram where offline support or instant responsiveness matters most, while keeping LiveView for parts where server-side rendering is enough.

For your offline/low bandwidth requirements specifically, Hologram is perfect because once the JavaScript is loaded, all the UI logic runs locally. No more waiting for server roundtrips on every interaction, and the app continues working even when connectivity is spotty.

The previous slowness was actually due to a temporary bitstring implementation we had in place. Now the full page renders at 60+ FPS, which is a massive improvement.

And this is just the beginning - I'm working on component-level selective rendering that should make things an order of magnitude faster still. Instead of re-rendering the entire page, only the specific components that actually changed will be updated.

It's exciting to see the performance gains become so noticeable in real usage. The hamburger menu responsiveness is exactly the kind of instant interaction that Hologram is designed to enable! :)

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.

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?

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.

Phoenix LiveView is absolutely fantastic for many use cases and has been a game-changer for the Elixir ecosystem. I have tremendous respect for what the Phoenix team has built.

The key difference with Hologram is that it transpiles Elixir code to JavaScript that runs directly in the browser, eliminating server round-trips entirely. So while LiveView uses websockets to update the DOM from the server, Hologram gives you true client-side execution with zero latency for interactions.

Thanks for the interest! That's exactly the vision - having Elixir everywhere in the stack is incredibly powerful. I'm actually planning to expand Hologram beyond just web applications. The eventual goal is to make Hologram a cross-platform development platform, so you could potentially target also mobile and desktop while staying in the Elixir ecosystem. Still early days, but the foundation I'm building with the web framework is designed with that broader vision in mind. Would love to hear your thoughts after you give it a try!

A user reported that the installation instructions were outdated after v0.5.0 removed redundant endpoint integration (which was simplified). If you’re getting errors during setup, just remove the use Hologram.Endpoint and hologram_socket/0 lines from your endpoint module and you should be good to go. https://github.com/bartblast/hologram/issues/223

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.

I’m excited to announce Hologram v0.5.0, a major evolution of the full-stack Elixir web framework! This release brings massive performance improvements - we’re talking execution times improved from milliseconds to microseconds in core client-side operations, making it fast enough for real-time interactions like mouse move events.

Key highlights:

- Complete bitstring rewrite with ~50x rendering speed improvements!

- Comprehensive session and cookie management

- Live reload functionality for enhanced DX

- Incremental compilation (2x-10x faster builds)

- New pointer and mouse move events

- HTTP-based transport layer

- CRDT support for future distributed features

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

Check out the SVG Drawing Demo that showcases smooth, responsive drawing using the new pointer move events - it really demonstrates the performance leap! https://hologram.page/demos/svg-drawing

With over 950 commits since v0.4.0, this release delivers significant architectural enhancements while maintaining the unique developer experience that makes Hologram special.

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

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

After building Hologram and sharing updates across various places, I’ve realized there’s a lot happening that doesn’t always make it to the usual channels. There’s been quite a bit of non-obvious progress over the previous months that many people probably aren’t aware of. So I’m starting a monthly newsletter to keep everyone in the loop on what I’m building.

What you’ll get each month:

- Development milestones and progress updates

- New features being worked on

- Community discussions and highlights

- Insights into the framework’s direction

- Ecosystem news and updates

Think of it as your monthly check-in with the Hologram world - no need to piece together information from different places. Everything gets compiled into one convenient monthly update. Whether you’re already building with Hologram, considering it for future projects, or just want to stay in the loop on what I’m working on, this newsletter will keep you connected to our growing community.

Ready to join? Head over to https://hologram.page/newsletter to subscribe.

Looking forward to sharing this journey with you all!

Hey Elixir friends! For those following Hologram’s progress... I’m excited to share that I’ve just published the official roadmap for Hologram. You can check it out at: https://hologram.page/docs/roadmap

The roadmap page provides a comprehensive overview of:

- Development Plan: Featuring both immediate priorities (before ElixirConf 2025) and medium-term goals (after ElixirConf), with features listed in planned order of implementation

- Feature Status: Detailed breakdown of what’s already implemented and what’s coming next

My immediate focus is on key improvements like optimizing client bitstring performance, implementing component-level rerendering, completing DOM events support, and adding cookies and sessions functionality.

The page also includes detailed status tables for various framework components, including the template engine, framework runtime, and Elixir client runtime features.

I hope this transparency helps the community understand where Hologram is headed and what to expect in the coming months. I welcome your feedback and contributions!

What features are you most excited about? Let me know in the comments!

Hi everyone! I'm Bart, the creator of Hologram. First, I'd like to thank whoever shared Hologram on HackerNews. I appreciate the interest and discussion it generated :)

I want to address some of the concerns raised in the comments:

Hologram is currently in early alpha stage. I released this version primarily to let developers experience Hologram's programming model and architecture.

The mobile navigation issues that several users reported were caused by a bug in Hologram's DOM patching mechanism (which is responsible for updating the page content during navigation) - this has since been fixed. However, you may still experience some lag on mobile devices. This is due to an early, temporary bitstring implementation that is very inefficient and causes performance issues with large templates (which are essentially huge strings). This is one of the areas that I'll be working on improving soon.

Some comments correctly pointed out that documentation is incomplete. You're absolutely right - I'm currently focusing heavily on improving the documentation. A more detailed explanation of what Hologram is and what to expect can be found in the announcement post on ElixirForum: https://elixirforum.com/t/hologram-an-isomorphic-elixir-web-...

Despite the issues with navigation and missing documentation that were highlighted in the discussion, many visitors still chose to star the project. Thank you very much for your support!

I'm committed to improving Hologram and addressing the concerns raised. The current version is just the beginning, and I appreciate both the criticism and encouragement from the community :)

Got ya! I've got to dig into Ash a little more!