This file has been truncated. show original
This is an analysis of the architecture of the Druid framework, and how I think it should evolve in the near future.
[Druid](https://github.com/linebender/druid) is an experimental GUI framework in the Rust programming language; it's somewhere between declarative and object-oriented, and implements a high-level abstraction for platform-specific architectures. It's also the base for [crochet](https://github.com/raphlinus/crochet/), an immediate mode GUI library, and [panoramix](https://github.com/PoignardAzur/panoramix), a reactive GUI library; both of them extremely experimental.
Recently, Druid's author Raph Levien started talking about the idea of refactoring druid into multiple layers (a simple "backend layer", and one or more frontends like crochet and panoramix). We've discussed possibilities, and Raph has described some (still hypothetical) design decisions that I want to challenge.
Now, separating a framework into tight layers isn't fundamentally a good or bad idea. Sometimes it helps isolate orthogonal logical concepts; sometimes it's over-engineering that makes using the framework more complicated. But in Druid's case, I think the idea has merit.
Druid is a library that manages both the internal state of a widget graph (with all the complexity and platform-dependent implementation details that entails) and a declarative abstraction for end users to produce that widget graph.