Taking a peek at the repo and the local first data layer issue (https://github.com/bartblast/hologram/issues/940) I get the sense that you aren't (and not planning to) using any off-the-shelf CRDT or the like, am I right in that assumption?
How will conflict resolution be handled? Or is it a last-write-wins type setup? It would be amazing to have this build on top of automerge or something like that! It could compile to and use the automerge js libs in the browser, and deal with automerge through a NIF server side? Ok, not knowing your implementation and plans, I have to confess I am talking a bit out of my arse here...
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.
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.
Just wanted to echo that my experience is almost identical (production elixir/phoenix for 10 years), and also very rarely touch erlang. But it does leak in every now and then.
And it'll feel less intimidating once you code in elixir, but I still find it more cryptic and less approachable the 3-4 times I've had to splunk into erlang to debug something in the last decade.
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.
