Motivation

Before going into the details of how Maple works, let's understand why you might actually need it.

CSS as a Static Asset

Since the introduction of CSS, the stylesheets are treated as static assets for a good reason. The "C" at the beginning of CSS stands for "Cascading", meaning that the rule at line 5000 can override the rule at line 1.

This feature naturally draws a hard line on how CSS can be evaluated between the first stylesheet request and the pixels on the screen. Any random combination of selector and specificity order has to be converted to CSSOM before its sibling DOM can be processed. So downloading stylesheets in the head, parsing them, building the CSSOM and then matching it with the DOM elements became the inevitable way to render the page, which we call Critical Rendering Path.

That "hard line" forced us to architect optimizations entirely around network latency and selector complexity. Currently, our optimization options are:

• Remove unnecessary styles
• Split CSS into separate modules
• Minify and compress CSS files
• Simplify selectors
• Preload important assets

Implementation of these optimizations requires complex tooling, build steps and configurations, in addition to cognitive load of splitting strategies. So far, we invented:

• Preprocessors (Compass, Sass, Less)
• Postprocessors (PostCSS, Autoprefixer)
• Semantic Approaches (BEM, OOCSS, SMACSS)
• Utility-first frameworks (Tailwind, Tachyons)
• Purgers (PurgeCSS)
• Critical CSS Extractors
• CSS-in-JS (Styled Components, Emotion)

The Tailwind Era

As of now, the industry has settled on the idea that "CSS scales better when you stop writing CSS." That's why the popularity of Tailwind is not a coincidence. However, this does not change the fact that Tailwind is still bound by the "Static Asset" hard line. To see your first styles rendered on the screen, here is what needs to be done:

• Bootstrap a project with a build tool (Vite, Webpack, etc.)
• Install Tailwind
• Configure Tailwind
• Let Tailwind purge unused styles
• Build and deploy

So, no matter what we do, we face the same hard line: developers can optimize how CSS is delivered, but not when or how styles are created and managed at runtime.

Challenging the Hard Line

Maple is here to challenge this hard line. Instead of optimizing CSS files, Maple generates styles on-demand as the browser encounters classes. This seemingly simple change creates cascading architectural benefits:

• Delivery & Performance:
  Constant Transfer Size (14kb, always)
  Incremental CSSOM
  Automatic Splitting
  No Unused Styles
• Developer Experience:
  No Build Step
  No Configuration Files
  No Special SSR Treatment
  Universal Portability
• Styling Power:
  Dynamic Data as CSS
  Variable-First Architecture
  Dynamic Color Manipulation
  True Encapsulation