Frequently Asked Questions
Short answers to the questions people ask most often, from paint timing and performance to framework support and license terms.
How does Maple generate styles before the browser paints?
Maple processes <html> synchronously when the script runs. After that, a MutationObserver watches the document. The parser appends an element, the observer sees it, and Maple inserts that element's rules into the stylesheet right away. Observer callbacks run at microtask checkpoints, and microtasks drain before the browser's next rendering opportunity. The rules for an element are therefore in place before it can be painted.
Does Maple cause a flash of unstyled content?
No. Maple blocks rendering the way your stylesheet does. Load it as a <script> in <head> and it generates the styles before the browser paints.
Keeping the script synchronous is the key. Skip async, defer, type="module", and end-of-body placement, for the same reason you wouldn't defer your main stylesheet. They let the browser paint before styles are ready. See Quick Start for the correct placement.
Isn't generating CSS at runtime slow?
Less than the phrase suggests. Maple's work scales with unique utilities, not elements; reusing a class a thousand times produces one rule. Against a perfectly scoped static stylesheet for the same workload, the benchmark gap is measured in tens of milliseconds: static wins the cleanest high-reuse case by about 100ms, and the two are effectively even once the page uses more unique utilities.
Production stylesheets are rarely that clean. Once the static side carries unused rules, such as shared app CSS or styles for routes the user never opens, the result flips: Maple leads by hundreds of milliseconds, because it never transfers or parses rules the DOM doesn't use. Neither model wins universally. See Runtime vs. Static CSS Delivery for the full benchmark matrix, which you can run yourself.
Is Maple CSS-in-JS?
No, though both generate styles at runtime. CSS-in-JS libraries such as Styled Components and Emotion have you author styles in JavaScript source, tie them to a component framework, and ship them inside your bundle, so the styling payload grows with the application and server rendering needs an extraction step.
Maple shares none of that anatomy. Styles are authored as utility classes in markup, the engine is a single script whose size never changes as the app grows, and no framework, bundle, or extraction step is involved. See Motivation for where Maple sits among the existing approaches.
How is Maple different from Tailwind?
Both style through utility classes; the difference is when the CSS comes to exist. Tailwind scans your source at build time and emits a static stylesheet, so it needs a build pipeline and a rebuild before any new class works, dynamic class names must be safelisted or avoided, and conflicting classes are handled in component code with helpers like tailwind-merge.
Maple generates rules from the live DOM. There is no build step, no configuration, and no purging; a class composed at runtime works like any other, and when two utilities write the same property, the one on the right wins without a helper. The trade is that Maple requires JavaScript and does its work in the browser. See About Tailwind comparisons for how to weigh the two architectures fairly.
Does Maple work with React, Vue, or my framework?
Yes. Maple observes the DOM and ignores your source files, so whatever produced the HTML makes no difference. There is no plugin, loader, or framework integration to install.
The same holds beyond JavaScript frameworks. HTML rendered by WordPress, Rails, Django, PHP, a static site generator, or a no-code builder is styled exactly the same way, because the browser is the only environment Maple ever runs in. See Universal Portability.
Some framework lint rules flag blocking scripts. Next.js has no-sync-scripts, for example. Maple blocks on purpose, so suppress the rule for that one line.
Do classes added or changed at runtime work?
Yes. This is not a special case; it is how Maple always operates. The same MutationObserver that styles elements as the parser appends them also watches class attribute changes. Toggle a class from an event handler, render a component, read a utility string out of an API response, or type one into the element in your browser's dev tools, and the rules are inserted before the next paint, even for a utility no page has ever used.
A build-time tool only has rules for the class names it found in your source, so dynamic names must be safelisted or avoided. Maple has no such list, and utilities can even interpolate runtime values directly. See Dynamic Data as CSS.
Can I add Maple to a site that's already built?
Yes, and this is one of the places Maple is strongest. Get a <script> into <head> through a WordPress plugin, a wp_head hook, a CMS header field, or a template partial. You can then write any utility class on the markup you already have, including one the site has never used. No build step, no config file, and no change to how the site is compiled or deployed.
A build-time CSS tool has to regenerate its stylesheet and redeploy it before a new class does anything.
One thing to know up front: the site's existing CSS is unlayered and Maple's is layered, so by default the theme keeps any property it already sets. To override it, load the script as maple.js?important, which marks every generated declaration !important, or prefix individual utilities with !. See Global Important Mode for the full behavior.
Does Maple work without JavaScript?
No. Maple generates styles in the browser instead of shipping a static stylesheet, so it carries the same requirement as any client-rendered application. Choose another tool if you must fully support clients with JavaScript disabled. See Trade-offs.
Does generating styles at runtime hurt SEO?
No. Search engines rank the content and metadata in your HTML, and Maple touches neither. The markup arrives exactly as your server, framework, or static host produced it; Maple only generates the stylesheet for it. A crawler that reads raw HTML sees the same content it would see with a static stylesheet.
Crawlers that render pages, such as Googlebot, execute JavaScript and see the styled result. Because the script blocks rendering like a stylesheet, there is no unstyled snapshot to index and no layout shift to count against Core Web Vitals. See also No Special SSR Treatment.
Can I use Maple in a commercial or closed-source product?
Yes. The Root Source License grants the same rights MIT does: commercial use, modification, distribution, sublicensing, and sale. There is no royalty and no copyleft. Your own source stays yours.
How does the Root Source License differ from MIT?
ROOT is MIT with one added distribution condition. If you provide public network access to a system that can recreate the Root on demand, the copyright and permission notice travels with what that system distributes.
Commercial use
Yes
Yes
Modify
Yes
Yes
Distribute
Yes
Yes
Sublicense and sell
Yes
Yes
Private use
Yes
Yes
Copyleft on your source
No
No
Royalty
None
None
Notice required when redistributing
Yes
Yes
Notice required when redistributed through a recreating system
—
Yes
Read the full text in the LICENSE.