3 ms·

Thank you for this thorough analysis - these are definitely not disorganized thoughts! Let me address each point: Regarding Actions vs Commands: The distincti

Thank you for this thorough analysis - these are definitely not disorganized thoughts! Let me address each point: Regarding Actions vs Commands: The distinction serves several important purposes. Actions are synchronous and run in the browser, with access only to component state. They're expected to be reliable (barring code bugs). Commands, on the other hand, are asynchronous, may potentially fail (due to server/network issues), and have access to global server state (sessions, cookies, etc.). The naming choice, while perhaps not perfect (I'm not a native English speaker), was meant to reflect this fundamental difference - "action" suggesting immediacy, while "command" implies a remote procedure call. The inspiration came from Elm commands and Redux actions. There's also a technical reason for the separation: Hologram builds a call graph and transpiles everything from actions (including all functions called by those actions, and all functions called by those functions, and so on) to JavaScript, making that code public. Having distinct terms helps developers maintain a clear mental model of what code will end up client-side. Regarding Phoenix dependency: To clarify - Hologram requires Phoenix (not Phoenix LiveView) specifically for its web server functionality and excellent channels/pubsub support. The long-term plan is to make Hologram available as a standalone app, though Phoenix will likely remain as a hidden dependency. This approach was chosen because: 1) it was more practical than building everything from scratch, and 2) most Elixir web developers already use Phoenix, making it easier to adopt Hologram gradually by starting with just 1-2 pages. Regarding Elixir syntax coverage: Currently, you only need to worry about syntax support for code in actions and functions called by actions. While this might sound simple, I understand it's more complex in practice. When using unsupported syntax, you'll get specific error messages in the JS console. The path to 100% syntax coverage is relatively straightforward for most features. The real challenge lies in parallelism - the primary plan is to implement this using web workers and dynamic JS chunks. If that approach proves unfeasible, the fallback plan is to use JS microtasks, though this would mean single-threaded execution. You can see the current implementation status in the roadmap here: https://github.com/bartblast/hologram/commit/4e4a141f514cd2383839e5489b54f1eb7d9ed2d8 https://github.com/bartblast/hologram/commit/4e4a141f514cd23... (this information will soon be available on the website here: https://hologram.page/docs/roadmap https://hologram.page/docs/roadmap) It's worth noting that actions typically involve relatively simple code - updating state, processing strings, handling events. More complex operations can be handled through server-side commands. While there might be cases for complex client-side processing (like file processing to reduce server load), these are rare. The ultimate goal is to avoid making developers think about syntax compatibility - I agree that having a "worse version of Elixir" would defeat the purpose. Regarding bundle size and performance: The current bundle size and performance metrics are temporary - expect them to improve by an order of magnitude. I chose to release early to gather feedback, as it's easier to make changes based on real-world usage. Please don't hesitate to ask more questions or share your thoughts - your questions are incredibly valuable as they help me understand how developers perceive and interact with the project. This kind of feedback is essential for improving both the framework and its documentation :)

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 ago
  Phoenix 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.

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 ago
Phoenix 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.