5 ms·

Hologram v0.5.0

83 points by bartblast 1y ago

bartblast 1y ago
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 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 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 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 https://hologram.page/newsletter
- agos 1y ago
  the performance increase is tangible - before, opening the hamburger menu on the site required a second or so, now it's fast enough to not notice
  - bartblast 1y ago
    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! :)
arresin 1y ago
Every time I think of elixir and its vm I think of the robot character from slay the spire
- pawelduda 1y ago
  Why?
travisgriggs 1y ago
I’ve poked around a little the site. There’s a lot of “this is awesome” advertising. I still don’t know where this fits with Phoenix/liveview/bandit. Does it replace them? Why and to what end? Am I to use it as a companion? For which parts? In other words, which problems do I need to have to appreciate how cool this is?
- bartblast 1y 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 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.
bartblast 1y ago
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 https://github.com/bartblast/hologram/issues/223
christophilus 1y ago
Well. This is nifty. I currently work on a full stack web application, and having the same language everywhere is really nice. This is that, but for Elixir. I’m definitely giving this a tire-kick when I have some spare time.
- gchamonlive 1y ago
  Don't know if this was your intent, but you make it sound like it's only now, with hologram, that elixir's got superpowers and can be used both in front- and backend. However Phoenix Liveview has been around for a while.
  - bartblast 1y ago
    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.
    - gchamonlive 1y ago
      Couldn't you leverage wasm and run the client-side actor locally and achieve something similar without having to compile to JavaScript which is brittle and not fun at all? Maybe using something like https://github.com/tessi/wasmex https://github.com/tessi/wasmex Never tried it, so I don't know what the limitations would be, but it seems feasible in theory.
      - bartblast 1y ago
        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.
dsiegel2275 1y ago
The offline support story here looks interesting. My Elixir/Phoenix app, which relies heavily on LiveView, has some new "offline" and "low bandwidth" set of requirements. Can Hologram sit alongside the existing routes of a Phoenix app?
- bartblast 1y ago
  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.
  - dsiegel2275 1y ago
    Thank you for the reply! I will be looking into this for sure.
  - bdunks 1y ago
    I've just read through the entire documentation end-to-end. It's very clear and well written, thank you for the time and love. One thing that's unclear to me in how I might manage this "side-by-side coexistence": how you manage potential route conflicts, e.g., You have a Hologram "page" that defines `route "/hello-world"`, and the Phoenix application router.ex also defines a route, `live "/hello-world', MyApp.HellowWorld, :index`. I could imagine the lack of a central router may be offset through conventions of how you organize pages (perhaps a directory-based-routing convention). I saw in the Installation section that it's common to organize under `app/`, and `app/pages`. Maybe an expansion on best practices for larger project organization, and how you keep Hologram routes straight, would be interesting to other people as well. Regardless, I've just started dipping my toes in the elixir and phoenix ecosystem about 3 months ago, and it's been a real joy. I'm throwing every hobby project I can think of at it to learn more. I'll give hologram a spin -- thanks again for such clear documentation.
doodlesdev 1y ago
I must say the proposal for Hologram is extremely interesting. The website is made using Hologram, and it speaks loudly to how good it is: every page navigation is (practically) instantaneous. Compared to other approaches such as LiveView, it's pretty good. The initial page load isn't impressive, though: Google's PageSpeed Insights indicates a 100+kb runtime with lots of unused JavaScript initially, resulting in a LCP of 1.5s (results will vary, of course). I wonder how much of the JavaScript is simply code that stores the website pages, haven't had the time to look at this in detail yet. For a docs website, that's excessive and bloated; it'd be much better to just deliver no JS and provide HTML with prefetching rules and cache headers (which would also provide instant navigation and offline support). I'm happy they made the docs website with it, though, to dogfeed and showcase it.
- bartblast 1y ago
  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!
lawn 1y ago
I haven't seen Hologram before. What an ambitious and exciting project! I see that you've been focusing on the performance aspect but I see a big benefit with the offline first use-case. It would be nice to have built-in support for syncing any changes when the client comes back online as it would remove the biggest issue with LiveView based websites (that they stop functioning if you lose connection). For example, a simple todo list where you can check off items offline and when you go online they're sent to the server?
- bartblast 1y ago
  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 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.
  - lawn 1y ago
    Excellent! I'll definitely keep following the project and I need to play around with it when I find the time to.
jamauro 1y ago
Hologram looks really good. Excited to build offline-capable fullstack Elixir apps with it.
- bartblast 1y ago
  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!
Alifatisk 1y ago
Wow, the whole site is instant! Is it thanks to Elixir?
- bartblast 1y ago
  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.
svieira 1y ago
For those like me who didn't know what this was: > Hologram is a full-stack isomorphic Elixir web framework that runs on top of Phoenix. It lets developers create dynamic, interactive web applications entirely in Elixir. Through intelligent code analysis and transformation, Hologram converts the necessary parts of your Elixir code into JavaScript, delivering modern frontend functionality without requiring any JavaScript frameworks or direct JavaScript coding.
- bartblast 1y ago
  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! ;)
  - ElijahLynn 1y ago
    That's a pretty big title change. I'd be discouraged from posting again if that happened to a post from me like that.
    - bartblast 1y ago
      Yeah, it happened to my last submission too: https://news.ycombinator.com/item?id=44246672 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.
    - httpsterio 1y ago
      editorialising of the title is not allowed, you're supposed to use the title of the page you're linking to.

83 points by bartblast 1y ago

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 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 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 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 https://hologram.page/newsletter

agos 1y ago
the performance increase is tangible - before, opening the hamburger menu on the site required a second or so, now it's fast enough to not notice
- bartblast 1y ago
  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! :)

arresin 1y ago

Every time I think of elixir and its vm I think of the robot character from slay the spire

pawelduda 1y ago
Why?

travisgriggs 1y ago

I’ve poked around a little the site. There’s a lot of “this is awesome” advertising. I still don’t know where this fits with Phoenix/liveview/bandit. Does it replace them? Why and to what end? Am I to use it as a companion? For which parts? In other words, which problems do I need to have to appreciate how cool this is?

bartblast 1y 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 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.

bartblast 1y ago

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 https://github.com/bartblast/hologram/issues/223

christophilus 1y ago

Well. This is nifty. I currently work on a full stack web application, and having the same language everywhere is really nice. This is that, but for Elixir. I’m definitely giving this a tire-kick when I have some spare time.

gchamonlive 1y ago
Don't know if this was your intent, but you make it sound like it's only now, with hologram, that elixir's got superpowers and can be used both in front- and backend. However Phoenix Liveview has been around for a while.
- bartblast 1y ago
  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.
  - gchamonlive 1y ago
    Couldn't you leverage wasm and run the client-side actor locally and achieve something similar without having to compile to JavaScript which is brittle and not fun at all? Maybe using something like https://github.com/tessi/wasmex https://github.com/tessi/wasmex Never tried it, so I don't know what the limitations would be, but it seems feasible in theory.
    - bartblast 1y ago
      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.

dsiegel2275 1y ago

The offline support story here looks interesting. My Elixir/Phoenix app, which relies heavily on LiveView, has some new "offline" and "low bandwidth" set of requirements. Can Hologram sit alongside the existing routes of a Phoenix app?

bartblast 1y ago
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.
- dsiegel2275 1y ago
  Thank you for the reply! I will be looking into this for sure.
- bdunks 1y ago
  I've just read through the entire documentation end-to-end. It's very clear and well written, thank you for the time and love. One thing that's unclear to me in how I might manage this "side-by-side coexistence": how you manage potential route conflicts, e.g., You have a Hologram "page" that defines `route "/hello-world"`, and the Phoenix application router.ex also defines a route, `live "/hello-world', MyApp.HellowWorld, :index`. I could imagine the lack of a central router may be offset through conventions of how you organize pages (perhaps a directory-based-routing convention). I saw in the Installation section that it's common to organize under `app/`, and `app/pages`. Maybe an expansion on best practices for larger project organization, and how you keep Hologram routes straight, would be interesting to other people as well. Regardless, I've just started dipping my toes in the elixir and phoenix ecosystem about 3 months ago, and it's been a real joy. I'm throwing every hobby project I can think of at it to learn more. I'll give hologram a spin -- thanks again for such clear documentation.

doodlesdev 1y ago

I must say the proposal for Hologram is extremely interesting. The website is made using Hologram, and it speaks loudly to how good it is: every page navigation is (practically) instantaneous. Compared to other approaches such as LiveView, it's pretty good. The initial page load isn't impressive, though: Google's PageSpeed Insights indicates a 100+kb runtime with lots of unused JavaScript initially, resulting in a LCP of 1.5s (results will vary, of course). I wonder how much of the JavaScript is simply code that stores the website pages, haven't had the time to look at this in detail yet. For a docs website, that's excessive and bloated; it'd be much better to just deliver no JS and provide HTML with prefetching rules and cache headers (which would also provide instant navigation and offline support). I'm happy they made the docs website with it, though, to dogfeed and showcase it.

bartblast 1y ago
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!

lawn 1y ago

I haven't seen Hologram before. What an ambitious and exciting project! I see that you've been focusing on the performance aspect but I see a big benefit with the offline first use-case. It would be nice to have built-in support for syncing any changes when the client comes back online as it would remove the biggest issue with LiveView based websites (that they stop functioning if you lose connection). For example, a simple todo list where you can check off items offline and when you go online they're sent to the server?

bartblast 1y ago
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 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.
- lawn 1y ago
  Excellent! I'll definitely keep following the project and I need to play around with it when I find the time to.

jamauro 1y ago

Hologram looks really good. Excited to build offline-capable fullstack Elixir apps with it.

bartblast 1y ago
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!

Alifatisk 1y ago

Wow, the whole site is instant! Is it thanks to Elixir?

bartblast 1y ago
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.

svieira 1y ago

For those like me who didn't know what this was: > Hologram is a full-stack isomorphic Elixir web framework that runs on top of Phoenix. It lets developers create dynamic, interactive web applications entirely in Elixir. Through intelligent code analysis and transformation, Hologram converts the necessary parts of your Elixir code into JavaScript, delivering modern frontend functionality without requiring any JavaScript frameworks or direct JavaScript coding.

bartblast 1y ago
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! ;)
- ElijahLynn 1y ago
  That's a pretty big title change. I'd be discouraged from posting again if that happened to a post from me like that.
  - bartblast 1y ago
    Yeah, it happened to my last submission too: https://news.ycombinator.com/item?id=44246672 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.
  - httpsterio 1y ago
    editorialising of the title is not allowed, you're supposed to use the title of the page you're linking to.