One does not need to conflict with each other. It’s obvious for everyone that for example external JavaScript libraries would be supported (most probably simply by giving an src in script tag). You can obvious put your own scripts the same way and call them with this low-level API.
Eiji
1
olivermt
Eiji
We look for a solution in framework that’s changing Elixir code to JavaScript or “simplicity” instead? If we want simplicity then why we even bothering about adding some complex stuff like ports? Why we even care about using Elixir? We could simply call addEventListener on custom Hologram events. That would be the “simplest” solution.
We talk about DX and not simplicity. We want to have such functions because we want to use them within actions instead of writing another big blob of JavaScript code. If we are trying to avoid JavaScript and allow using only some libraries for compatibility then why we even consider writing more JavaScript in ports? For me it does not makes any sense …
The above proposals happen naturally and suddenly you came and say it’s too complex? What’s so complex here? You can write you own Chart in JavaScript and just use the above proposed functions to initialise it with maybe even one call. Yeah, very complex … 
If there is something complex in context of our discussion then it’s a fact that we have to implement port or event bridges not because they give us some reasonable feature, but only because they look “simpler” for someone only because someone is used to work with Elm before or something like that. If we would be so hard into JavaScript then we would not care about writing Elixir code anyway …
While I initially proposed was a handy high-level API, after the discussion I understood that the low-level one would give us much more than what I was originally expecting. I honestly don’t see here any place for JavaScript-based solution here (in context of writing Elixir code). As said you can move 99% of your logic to JavaScript and use a single call to initialise it when needed. In Hologram ecosystem it would be rather considered a bad practice, but I don’t see why anyone would consider stopping you from doing that.
0
olivermt
If I want to use google maps I am not looking to avoid javascript, I want to use javascript in the most practical manner possible.
Hologram is about isomorphic solution to 80-90% of your app, then for the rest where I can use pre-built stuff that is supported by a profitable business I just want a very ergonomic way to do javascript.
I do not think Bart spending time re-implementing Javascript in elixir is a good use of his time for that 
5
cschmatzler
If you talk about DX, you explicitly do not want to reimplement JavaScript in Elixir. We have millions of dollars invested into JavaScript tooling; language servers, linters, build tools, runtime debugging tools.
defmodule Chart do
use Hologram.JS.Interop
def draw(element_id, width, height, data_points) do
element =
js_ref("document")
|> js_call("getElementById", [element_id])
if is_nil(js_unwrap(element)) do
# handle case when element is missing
end
js_ref("Chart")
|> js_create([element, %{width: width, height: height}])
|> js_call("draw", [data_points])
end
end
This gets rid of all of that.
If you want to write JavaScript, just write JavaScript. Our tooling already understands it.
1
Eiji
Meanwhile from Hologram’s main page:
Build rich, interactive UIs entirely in Elixir using Hologram’s declarative component system. Your client-side code is intelligently transpiled to JavaScript, providing modern frontend capabilities without relying on any JavaScript frameworks.
This in context of compatibility with 3rd-party .js libraries by simply putting them in templates (script with src attribute). I really don’t see a reason for attempt on convert everyone into JavaScript religion even if the core point is clearly states that we want to work “entirely in Elixir”.
If you don’t like it go for node. I bet there is no better environment for JavaScript tooling. No, I don’t want JavaScript tooling in Elixir codebase. I’m more than fine with Elixir’s tooling. Everything that I would need would be a high level API done by me or someone else, so that the Elixir tooling could use all it’s power.
The false assumption is absolutely the worst thing people can have. Who said anything about writing JavaScript code? The interop is all about 2 things:
-
Backwards compatibility - support initialisation calls of 3rd-party
JavaScriptlibraries (simply because it’s not worth to rewrite every existing one) that are in separate.jsfiles. -
Access the same API the
JavaScriptcan. The point would be same no matter what language would be used in browsers. All we want is to accessDOMand other APIs and not writeJavaScriptcode. It’s like inXlanguage you would like to add some feature fromElixirand I would say just useElixirinstead. No, I want to have access to same feature, not to write code in other language.
0
cschmatzler
With this proposal you are literally writing JavaScript, just with extra steps and without any of the available tooling. Like, why would you have “draw” as a string when in JavaScript you get the function as autocomplete?
Having the goal to translate higher-level APIs to JavaScript is fine, but copying the API one-to-one doesn’t sound very appealing?
2
bartblast
Creator of Hologram
I agree that event-based communication is generally more testable and aligns well with JavaScript’s async nature.
However, I wouldn’t use LiveView as a reference point here - LiveView didn’t really have a choice in this regard due to its specific architecture (server-side components communicating over WebSocket). It had to go the event route.
But here’s where I see the tradeoff: events force async communication even when you just need to call a simple synchronous function. Think about cases like:
- Querying information:
chart.getWidth(),element.getBoundingClientRect() - Mathematical operations: Math.cos(angle) (normally you’d use the transpiled Elixir equivalent, but if there’s a bug in Hologram’s implementation and you need a working solution immediately, direct JS access becomes essential)
- Feature detection:
Modernizr.webgl - Validation: validator.isEmail(input) (same escape hatch scenario as with Math.cos, but let’s say there’s no suitable Elixir library that provides this specific validation behavior you need)
These naturally return immediate values. Making them async adds complexity and breaks the natural flow of your logic.
And this becomes especially important when you consider that many of these operations will need to go through interop until Hologram has official wrappers for specific Web APIs, DOM features, or browser-specific functionality. For instance, if you need getBoundingClientRect() today for a layout calculation, you can’t wait for Hologram to build a high-level DOM measurement API - you need direct access to that synchronous browser function right now.
Performance can also be a factor - for high-frequency operations (animations, real-time data processing), the event serialization overhead and callback coordination can become noticeable.
So with events, you’re essentially shifting control from Elixir to JavaScript, which can be good or bad depending on the case. I don’t think it’s that black and white.
But here’s the thing - FFI could actually enable the pattern you’re describing. If we have a low-level API for power users, we can build higher-level abstractions on top. For example:
def dispatch_event(name, params) do
event = JS.new("Event", ["my_custom_event_name"])
JS.call("window", "dispatchEvent", [event])
end
This way, those who want the event-based pattern can have it, but we don’t lock out use cases that need direct function calls. The FFI approach gives us both options rather than forcing one pattern for everything.
What do you think about having that flexibility?
3
tozz
Interesting discussions, I think one key aspect is to make sure you can store the JS return values and use them in later calls, or maybe you already thought about that?
Let’s say you do chart = JS.new(“ChartLibrary”, [{data: nil}] and then in somewhere later you want to access chart and do something like JS.call(chart, "populateData", [...]) on it, how would that work?
1
bartblast
Creator of Hologram
The right design is crucial here, and the basic implementation for either approach is relatively straightforward.
0