@Twfo326 Thanks! Here are the main selling points:

• State on the client - and all of the problems that get solved by this approach (below)…

• No latency issues as most of the code is run immediately on the client. This makes it possible to create rich UI or even games. At the moment with LiveView you need something like fly.io to make it bearable, but you still have latency and can’t guarantee the response time (there is always some variance). And you still need some JS or Alpine to make it work. Until someone manages to create quantum internet (e.g. by taking advantage of entanglement), there are no workarounds for this problem. Not sure if this is even technically possible, though

• Better offline support (internet connection loss, poor signal, etc.). Since most of the code is run on the client and you only hit the server to run some command from time to time, Hologram can work offline most of the time. This would also make it possible to create PWA’s or mobile apps through WebView, assuming you use something like LocalStorage.

• Less server RAM used - state is kept in the browser instead of the socket.

• Less CPU used - most of the code is run by the browser not by the server.

• Less bandwidth used - only commands need to communicate with the server, no need to send diffs to rerender components.

• No state sync problems - state is kept only in one place (browser) and the websocket communication used is stateless.

• No JS or Alpine.js needed except for communication with some third party scripts or widgets, but this can also be solved by creating some standardized libs for popular packages that would handle the interop.

Another important selling point is the dev experience. I envision Hologram to be very friendly to new Elixir converts or beginner devs. I want it to be very, very intuitive, so that you can focus on working on new features in your project instead of solving technical problems and writing boilerplate code.
To achieve that Hologram will provide out of the box such things as UI component library (CSS framework agnostic), authentication, authorization, easy debugging (with time travel), caching, localization and some other features that you typically use in a web app.

I think that using Hologram’s approach, i.e. Elixir-JS transpilation, code on client and action/command architecture it’s possible to create something as productive as Rails, but without its shortcomings related to scalability, efficiency, etc.

I want to clarify this section a bit. This sentence only applies if you try to use LiveView for client-only interactions, but the docs are very clear that you should not use LiveView for that.

I am aware that you know this, I am commenting to avoid confusion in other threads.

Assuming you have to hit the server, for example to talk to a database, LiveView response time is actually better than regular HTTP requests because it works over an existing authenticated web socket connection. So the work of parsing headers, authenticate users, etc is not done on every server interaction. Hologram and LiveView should be similar here, as both are WebSockets based.

Similarly, Fly.io gets you closer to your users, which means any server-based application could benefit from Fly.io.

In other words, LiveView is for server based interactions and it excels at that, with or without Fly.io. Indeed, for more complex cases on the client, then you need custom JS (or something that aims to fully cover both server and client, like Hologram).

@christhekeele I initially tried to use ElixirScript, but I couldn’t make it work. When I went through its GitHub issues I realized the creator stopped maintaining the project and focused all of his efforts on Lumen: Still alive? · Issue #495 · elixirscript/elixirscript · GitHub So I tried Lumen, but too much work was in progress. And now it looks that the project is stalled at the moment: Project Status · Issue #698 · lumen/lumen · GitHub

I also tried another route: Erlang → PureScript → JavaScript through Erlscripten, Erlscripten – Transpiling Erlang to Javascript. Yes, you read it right - News and Announcements - æforum but I wasn’t convinced with it, because one of my goals was easy debugging of the transpiled code, and for that it helps if the transpiled code resembles what was actually written in Elixir.

So I decided to write my own transpiler, because that gives me much more control over the output code and I can fix any errors myself. I do this by first converting the code to AST, then building IR (intermediate representation) containing context and metadata, which makes it easier to reason about the code and finally the IR is encoded into JavaScript. You can take a glance at its structure here: hologram/lib/hologram/compiler at master · segmetric/hologram · GitHub

@bartblast @christhekeele I stopped working on elixirscript mostly because it seemed like it wasn’t providing the value to the community I hoped it would. And bringing the BEAM to the browser is a big task in itself. But sounds like there is some interest in that sort of thing. I’d be interested in helping with an effort for having elixir compile to js. Nx and Gleam’s JS compiler makes me think going in a similar direction would be a good start since you don’t have to solve the BEAM in the browser so much.

1. I’m in the final stages now - wrapping up feature testing and fixing minor issues that popped up during testing. We’re very close to having a playable release!

2. About Phoenix integration:

   • Authentication: Nope, Hologram will come with its own auth layer (but it’ll be there out of the box). There’s a possibility we could share sessions between Hologram ↔ Phoenix which would make auth work both ways, but I haven’t dug deep into that yet - just have a general idea how it might work.
   • PubSub: Yes, this will definitely work, but in a later release. We’ll have a nice dedicated DSL in pages and components to talk to Phoenix PubSub.

3. Here are the downsides I can think of:

   • Browser download size: The framework runtime (with commonly used Erlang/Elixir functions) comes in at 427 kB (minified) / 75 kB (gzipped). I haven’t done any optimization yet though, and there are definitely functions in there we don’t need, so I expect we can cut that in half eventually. Plus each page has its own separate bundle that’s way smaller than the runtime bundle - size depends on what the page uses.
   • Client-side code caution: Since we’re auto-transpiling to JavaScript, you’ll need to be careful not to include any secrets in your client code (passwords, keys, etc). Phoenix LiveView doesn’t have this issue since everything runs server-side.
   • Function limitations:
     • You can’t pass anonymous functions between client and server in command parameters
     • So this won’t work: put_command(component, :my_command, a: 1, b: fn x → 2 * x end)
     • But function captures are fine: put_command(component, :my_command, a: 1, b: &DateTime.utc_now/1)
     • I’m still thinking about whether to allow this at all for security reasons
   • DOCTYPE declaration: All pages/layouts need to use the same DOCTYPE and you can’t use template expressions in the DOCTYPE template fragment. But honestly, in 2024 this isn’t really a problem - just use <!DOCTYPE html> everywhere and you’re good to go.