When I said “middle ground” I didn’t mean “half-measure” - that was unfortunate wording on my part. I’m talking about reaching similar goals - automatic recalculation, performance optimization - but in a way that aligns with functional programming principles. I think computed properties actually fit naturally into the functional paradigm: they’re pure functions that transform immutable state into derived values. That’s fundamentally functional.
I know you’re not a fan of templates, but computed properties actually strengthen the template-as-presentation-layer approach by letting you move business logic out of templates into small, focused, testable functions.
To be clear: when I talk about computed/derived properties, I mean values like full_name, valid?, or formatted_price that derive from existing state - not template fragments. (Partials like <my_partial(param_1, @param2) /> would be a separate feature for generating template fragments.) These are tools in your toolbelt, not fundamental architectural commitments.
I think it’s worth considering the concrete benefits they provide - they solve real problems:
- Performance: Automatic memoization of expensive calculations
- Consistency: Derived state that can’t get out of sync when multiple values depend on each other
- Readability: Clear separation between data and derived values
- Testability: Small, pure functions that can be tested in isolation
Regarding “there is no forest; you are only concerned with the trees” - I understand your concern about losing the holistic view. But I think the key difference is that computed properties in Hologram would be values derived from state, not a reactive programming model that forces you to think in terms of dependencies and updates. You still write your component declaratively as a whole - the state updates explicitly through actions, and computed properties are just transformations of that state. The component’s logic remains interconnected and whole. Computed properties are simply a way to extract and name derived values rather than calculating them inline in the template.
Additionally, when components are small and properly isolated with focused responsibilities, it becomes easier to keep the entire component in your head at once - the “trees” are manageable and the “forest” emerges from how components compose together.
The key point: computed properties in Hologram would be optional and complementary to the existing explicit approach, not a replacement. They’re a tool for specific use cases where the benefits are clear. I want to be pragmatic about giving developers useful tools while maintaining a coherent architecture.
