No Configuration Files

By observing the DOM directly, Maple entirely eliminates the mismatch between static analyzers and runtime reality.

The Flaw of Static Analysis

Most utility-based styling engines depend on static analysis. They scan your source files ahead of time, trying to predict which class names might exist when the application runs. However, as soon as your class names stop being purely static strings, this analysis breaks down:

• Dynamic assembly: Classes concatenated in JavaScript (e.g., p-{spacing})
• Data-driven styles: Classes pulled from a database or CMS
• External injections: Classes introduced by third-party scripts or markdown parsers
• Complex architectures: Large codebases with ambiguous scan boundaries

The inevitable result is configuration overhead: you are forced to maintain safelists, complex glob patterns, and special rules just to keep the analyzer in sync with reality.

The Observer Approach

Instead of scanning files, Maple runs at the end of the pipeline and observes the DOM itself using a MutationObserver. If the browser sees a class, Maple sees it. This means Maple works naturally with:

• Classes from CMS,
• Classes from server-rendered HTML,
• Classes generated by JavaScript at runtime,
• Classes introduced by third-party libraries,
• Classes from literally anywhere.