Skip to content

Caliburn.Micro vs. ReactiveUI

Caliburn.Micro is a long-running, convention-driven MVVM framework. It has carved out a strong niche on WPF and is actively maintained.

Approach

Caliburn.Micro is built around conventions and conductors/screens. The view-model class name conventionally maps to a view (ShellViewModel -> ShellView); a method named Save on a view-model automatically binds to a <Button x:Name="Save" />; an IScreen defines an activation/deactivation lifecycle; IConductor<T> types compose screens into navigable hierarchies.

It is opinionated about app structure (Bootstrapper, Conductors, Screens) and largely leaves async coordination, derived state, and event composition to plain async/await + INotifyPropertyChanged.

Where ReactiveUI differs

AspectCaliburn.MicroReactiveUI
View bindingConvention-based (x:Name matches a VM member)Explicit (this.Bind, this.OneWayBind, BindCommand) with strongly-typed Expressions
NavigationConductor<T> / Screen lifecycleIScreen + RoutingState, or Sextant
Reactive compositionNot built inFirst-class via Rx
CommandsTask / void methods bound by nameReactiveCommand<TParam, TResult> with IsExecuting / ThrownExceptions
ActivationIActivate / IDeactivateIActivatableViewModel + WhenActivated
DIBootstrapper-driven (you wire whatever container)Splat by default, adapters for every common container

When to pick which

  • Pick Caliburn.Micro when you want a strongly opinionated, convention-driven structure (especially for WPF), and you don't need reactive composition.
  • Pick ReactiveUI when you want explicit, refactor-safe bindings (no string conventions), Rx-based composition, and cross-platform views beyond WPF.

Mixing them

It's uncommon but technically possible: Caliburn.Micro relies on INotifyPropertyChanged, which ReactiveUI's ReactiveObject already implements. The two frameworks have overlapping ideas of "screen / conductor" vs "routable view-model / screen", so picking one as the navigation owner is recommended.