There are quite a few reactive libraries for Java these days, so what makes Hookless different? There are no clear-cut groupings of reactive libraries. Every library chooses its own mix of features. The following list enumerates characteristic traits of Hookless and names some other libraries that are either similar or different in that direction.
- Hookless is all pure Java with no special bytecode modifications or JVM instrumentation (contrary to projects like Quasar).
- Invalidate-then-refresh pattern allows Hookless to have highly dynamic dependency lists, because dependencies are collected during every recomputation of the reactive value instead of being specified upfront.
- Invalidate-then-refresh pattern enables implicit dependency tracking (like in Meteor or Assisticant). Hookless-based code is mostly just plain Java code except that reactive dependencies are transparently captured in a thread-local context object. Hookless relies on thin libraries that wrap numerous existing high-level non-blocking APIs instead of trying to intercept low-level blocking operations (like Quasar).
- Hookless lets you define a number of local reactive values that refresh independently (like in Meteor or Assisticant) as opposed to single global state that would refresh all at once (like in React).
- Dependency graph in Hookless is garbage-collected. Hookless uses weak references (like Assisticant) to make whole sections of the dependency graph collectable once nothing needs them instead of relying on explicit teardown (like Meteor).
- In order to protect programs from hot reactive variables, invalidated reactive values are refreshed asynchronously and concurrently on a thread pool instead of being refreshed immediately after reactive variable change (like in Assisticant or Meteor).
- Hookless has efficient high-resolution reactive time implemented via semi-explicit time algebra (like in Assisticant). Other reactive libraries usually just provide either fully explicit timers or a low-resolution global tick.