3 ms·
Actions vs Commands: Thanks, that's a satisfying justification. Phoenix dependency: I feel like your answer here is justifying the choice to use Phoenix, but
by bhaney 2y ago
Actions vs Commands:
Thanks, that's a satisfying justification.
Phoenix dependency:
I feel like your answer here is justifying the choice to use Phoenix, but my question was about the opposite. I would expect a project like this to use Phoenix in the first place, so I was wondering why you mentioned it as if it was something regrettable that you needed to be apologetic for.
Elixir syntax coverage:
Cool, sounds like the minimum possible infection. It does seem a little daunting knowing that any random library code that I transitively call from an Action will need to be transpile-able. If I call a utility function that uses a library that uses a library that implements some small-but-relevent part of itself as a NIF without me knowing, I assume that will fail to transpile and I'll be locked out from using that utility function until I swap out the dependency of a dependency with something transpiler-friendly. But thinking more about it, that probably doesn't come up much if Actions are just focused on simple operations. Out of curiosity, have you done any compatibility testing with Hologram's ability to correctly transpile and run code from major libraries? It might be good to publish a metric about this some day, like "Able to transpile 99.92% of the top 10,000 packages on Hex" with a little graph of how the number has improved over time or something. Many more important things first though, I'm sure.
> When using unsupported syntax, you'll get specific error messages in the JS console
In the JS console? Like at runtime? I don't just get them as build errors?
Bundle size and performance:
Yeah that's totally reasonable.
- bartblast 2y agoPhoenix dependency: I mentioned Phoenix as a dependency because some developers prefer other backend solutions like Ash Framework or Commanded (for CQRS/Event Sourcing), or may want to use Hologram with their existing non-Phoenix backends. While Phoenix is currently a great foundation for Hologram (providing battle-tested HTTP, WebSocket, and PubSub capabilities), the long-term vision is to potentially make Hologram self-sufficient. This would give developers maximum flexibility in choosing their backend architecture. That said, Phoenix remains an excellent choice and most Elixir web developers are already using it, making Hologram easy to adopt incrementally in existing Phoenix applications. Elixir syntax coverage: You are right, this shouldn't be an issue in practice due to Hologram's action/command distinction. Actions are meant for UI state updates and triggering commands, while commands handle things like database access, file I/O, and OS operations on the server side. We're actually quite close to 100% Elixir syntax compatibility. Process-related functionality isn't implemented yet, but the plan is to handle it initially using microtasks and Promises to provide semantically equivalent behavior and eventually use Web Workers for real parallelism. The key is that actions should remain focused on UI concerns, while commands handle the heavy lifting on the server side. This natural separation means you rarely encounter compatibility edge cases in practice. > In the JS console? Like at runtime? I don't just get them as build errors? Currently, syntax checks happen at runtime because Hologram doesn't perform dead code elimination for unused function heads. This means that even if your action code is valid, there might be unused function clauses in the same function that contain syntax we haven't implemented yet. Even if your code only calls one specific function head, all other heads of that function would still be included in the transpiled JavaScript.
- borromakot 2y agoAsh isn’t an alternative to Phoenix, they are typically used side by side :)
- bartblast 2y agoGot ya! I've got to dig into Ash a little more!