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/4e4a141f514cd23... (this information will soon be available on the website here: 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 :)