diff --git a/apps/landing/src/app/(detail)/docs/LeftMenu.tsx b/apps/landing/src/app/(detail)/docs/LeftMenu.tsx index 7129a1dc..d3485904 100644 --- a/apps/landing/src/app/(detail)/docs/LeftMenu.tsx +++ b/apps/landing/src/app/(detail)/docs/LeftMenu.tsx @@ -7,6 +7,21 @@ export function LeftMenu() { Overview Installation + + Core Concepts + Features ` tags, or resolve variables. +- When dynamic values (e.g., variables, expressions) are used, these solutions often fall back to runtime dependencies—a partial solution that reintroduces costs. +- In frameworks like Next.js, such runtime-style systems frequently cannot be used inside RSC (React Server Components). + +We asked: Can we deliver truly zero-runtime CSS that also works in RSC—without extra UI runtime code? + +Our approach is grounded in static analysis. Once code is built and shipped, it should contain the definitive answer—no further computation required on the client. + +## What “No Dependencies” Means + +- No UI runtime code is added to your bundle for styling. +- No extra plugins, pre-generation scripts, or PostCSS configs are required. +- Pure React remains your source of truth; styles are compiled at build time into static CSS. +- Works in RSC and the edge/runtime contexts where client-side style engines are unavailable or undesired. + +## How It Works? + +1. Parse your React source into an AST using Rust-based tooling. +2. Perform static analysis to extract all style semantics from components and props. +3. Resolve and de-duplicate styles, generating compact, atomic class names. +4. Emit a new AST with class names applied and a CSS virtual file populated with the minimal rule set. +5. Bundle emits static CSS and class-applied markup—no client-side style engine. + +## Compatibility + +- Next.js (including RSC): Safe to use without runtime style engines. +- Vite, Rsbuild, Webpack: Supported via official plugins. +- Works with server-first and edge contexts that restrict DOM/JS-based style injection. + +## Class Naming Policy + +- Class names never start with a digit (to satisfy CSS constraints). +- We minimize class name length while maintaining safety. + For example, tokens like `ad` may be flagged by content blockers; we emit `a-d` instead to break filter matches. +- To avoid common ad-blocker heuristics, we segment suspicious tokens by inserting a hyphen(`-`). +- Example mappings: + - `ad` → `a-d` +- Scope: applied to Devup UI–generated atomic class tokens only; user-supplied `className` strings are not rewritten. +- Allowed characters include `a`–`z`, combinations like `az`, `a0`, and safe hyphen/underscore placements. + +## Advantages if Using + +Devup UI brings the convenience of CSS-in-JS together with the performance of static CSS—delivering the best of both worlds with no extra UI runtime dependencies. + +1. **Zero runtime**: All styles are compiled to static CSS at build time. +2. **De-duplication**: Identical styles are generated once and reused globally. +3. **Performance**: Rust-powered pipeline provides fast, scalable builds. +4. **Smaller bundles**: No redundant classes, no UI runtime styling code. diff --git a/apps/landing/src/app/(detail)/docs/core-concepts/style-storage/page.mdx b/apps/landing/src/app/(detail)/docs/core-concepts/style-storage/page.mdx new file mode 100644 index 00000000..d221d8eb --- /dev/null +++ b/apps/landing/src/app/(detail)/docs/core-concepts/style-storage/page.mdx @@ -0,0 +1,46 @@ +export const metadata = { + title: "Core-Concepts", + alternates: { + canonical: '/docs/core-concepts/style-storage', + } + +} + +# Style Storage + +Devup UI removes duplication by storing and looking up styles in a single storage, reusing the same atomic class for identical style declarations. + +This document explains the de-duplication principle, the requirement for a single storage, its relationship with build order, the single CSS output option, per-page CSS splitting, and the key–value style storage with deterministic ordering. + +### How it works + +- Even if the same style appears in multiple places, it is generated as exactly one atomic class (no duplicates). +- If a style already exists in storage, the existing class is reused. Otherwise, a new class is generated and registered. + +### Why a single storage is required + +- To guarantee deduplication and reuse, there must be exactly one style storage in the build pipeline. +- Multiple storages fragment duplicate detection and may cause the same style to be generated with different class names. + +## Single CSS option + +- `single css`: emit all generated styles as a single CSS output file. +- Default is `false`. +- Pros: simplifies loading paths; maximizes browser caching benefits. +- Cons: for very large apps or when styles vary significantly per page, it can increase initial load. + +### Style ordering and key–value storage + +- The storage uses a key–value model: the style signature as the key, and the generated class name and rule as the value. +- Rule order follows the discovery order during the build. Rules with equal priority are merged deterministically to keep the output predictable. + +### Per‑page CSS splitting (optional) + +- You can split CSS per page so that only the rules needed for that page are loaded. +- This can improve initial load time in large applications. A reasonable caution is that using only a single global CSS might constrain initial load for some pages. +- Excessive splitting can increase network requests and fragment caching. Balance it according to your app size and navigation patterns. + +### Relation to Zero Runtime + +- Style Storage is resolved at compile time; no client‑side style engine or extra runtime computation is required. +- For background and rationale, see the Zero Runtime guide: [Zero Runtime](/docs/core-concepts/zero-runtime) diff --git a/apps/landing/src/app/(detail)/docs/core-concepts/zero-runtime/page.mdx b/apps/landing/src/app/(detail)/docs/core-concepts/zero-runtime/page.mdx new file mode 100644 index 00000000..b8cf3682 --- /dev/null +++ b/apps/landing/src/app/(detail)/docs/core-concepts/zero-runtime/page.mdx @@ -0,0 +1,68 @@ +export const metadata = { + title: 'Zero-Runtime', + alternates: { + canonical: '/docs/core-concepts/zero-runtime', + }, +} + +# Zero Runtime + +Devup UI is a CSS-in-JS preprocessor that requires no runtime. By moving style computation to build time, Devup UI avoids browser runtime overhead. We are building a preprocessor that accounts for all syntactic cases. + +## End-to-end Process + +### 1. **Source Code Input** + +Your application code written in JSX/TSX/JS/TS is provided as input. + +For example, consider the following ` +``` + +### 2. **AST Transformation (Rust + oxc)** + +We use **oxc** (a Rust-based JavaScript tooling suite) to convert code into an AST (Abstract Syntax Tree). + +- **Lexer**: breaks source code into tokens +- **Parser**: structures tokens into an AST + +This step is required to enable optimizations performed later by the **Style Storage**. + +### **3. Style Caching Logic (Core logic)** + +Core logic written in Rust + WebAssembly optimizes styles by consulting the Style Storage: **Style Storage Check** + +- **Existing style?** → Reuse the existing class name (cached result) +- **New style?** → Generate a new class and register it + +### **4. Code Generation Paths** + +Based on the caching results in step 3, two parallel outputs are produced. + +- **New AST** + - Generate a new AST in TypeScript + - Inject resolved style class names + +- **Update CSS Virtual File** + - Append newly generated style classes to the CSS virtual file + - Do not regenerate existing styles + +### **5. Final Output** + +The bundler (Vite, Rsbuild, Next.js, Webpack) emits optimized code. + +```html + +``` + +Inline style props are compiled into **atomic CSS classes**, achieving zero runtime.