From ab33af987378183683510874aef933b61afee7bc Mon Sep 17 00:00:00 2001
From: abyss-s <lh3729@naver.com>
Date: Thu, 9 Oct 2025 13:30:48 +0900
Subject: [PATCH 1/6] docs: add Zero Runtime core concept documentation

---
 .../docs/core-concepts/zero-runtime/page.mdx  | 68 +++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 apps/landing/src/app/(detail)/docs/core-concepts/zero-runtime/page.mdx

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..c4fe4bfb
--- /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 `<Button>` component.
+
+```tsx
+<Button
+  _hover={{ bg: 'red' }}
+  bg="blue"
+  className="btn"
+  color="white"
+  fontSize={['10px', null, null, '16px']}
+>
+  Click me!
+</Button>
+```
+
+### 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
+<button className="btn a b c d">Click me!</button>
+```
+
+Inline style props are compiled into **atomic CSS classes**, achieving zero runtime.

From e59f3d8e6c1e5586a5d49506bd7bb3a7a601510c Mon Sep 17 00:00:00 2001
From: abyss-s <lh3729@naver.com>
Date: Thu, 9 Oct 2025 13:31:03 +0900
Subject: [PATCH 2/6] docs: add No Dependencies core concept documentation

---
 .../core-concepts/no-dependencies/page.mdx    | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 apps/landing/src/app/(detail)/docs/core-concepts/no-dependencies/page.mdx

diff --git a/apps/landing/src/app/(detail)/docs/core-concepts/no-dependencies/page.mdx b/apps/landing/src/app/(detail)/docs/core-concepts/no-dependencies/page.mdx
new file mode 100644
index 00000000..7e3aea04
--- /dev/null
+++ b/apps/landing/src/app/(detail)/docs/core-concepts/no-dependencies/page.mdx
@@ -0,0 +1,69 @@
+export const metadata = {
+    title: "Core-Concepts",
+    alternates: {
+        canonical: '/docs/core-concepts/no-dependencies',
+    }
+
+}
+
+# No Dependencies
+
+Devup UI converts pure React source code without additional UI runtime code.
+
+This section explains what “No Dependencies” means in practice, why it matters, and how Devup UI achieves it without requiring client-side style engines, extra plugins, or manual pre-generation steps.
+
+## Motivation
+
+- Many CSS-in-JS libraries rely on JavaScript at runtime to compute styles, inject `<style>` 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 (e.g., EasyList-style rules), we segment suspicious tokens by inserting a hyphen while keeping names compact.
+- Example mappings:
+  - `ad` → `a-d`
+  - `ads` → `a-ds`
+  - `adbanner` → `a-dbanner`
+  - `ad_top` → `a-d_top`
+- Generation is deterministic: the same input always yields the same safe class name across builds.
+- The policy does not depend on any specific filter list and typically remains robust as lists evolve.
+- 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.

From f35df4acbbbd47f2e56d164a605dcd4a6621e16b Mon Sep 17 00:00:00 2001
From: abyss-s <lh3729@naver.com>
Date: Thu, 9 Oct 2025 13:31:12 +0900
Subject: [PATCH 3/6] docs: add Style Storage core concept documentation

---
 .../docs/core-concepts/style-storage/page.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 apps/landing/src/app/(detail)/docs/core-concepts/style-storage/page.mdx

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..3b7e6cb3
--- /dev/null
+++ b/apps/landing/src/app/(detail)/docs/core-concepts/style-storage/page.mdx
@@ -0,0 +1,47 @@
+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.
+- This happens at build time (when the bundler runs). The generation order can vary depending on the order in which the input code is discovered and analyzed.
+
+### 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)

From 2a7779bf5bcabbb1fd1a623d616c69c49292963d Mon Sep 17 00:00:00 2001
From: abyss-s <lh3729@naver.com>
Date: Thu, 9 Oct 2025 13:31:32 +0900
Subject: [PATCH 4/6] feat: add core concept with navigation menu

---
 apps/landing/src/app/(detail)/docs/LeftMenu.tsx | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

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() {
     <VStack gap="6px">
       <MenuItem to="/docs/overview">Overview</MenuItem>
       <MenuItem to="/docs/installation">Installation</MenuItem>
+      <MenuItem
+        subMenu={[
+          { to: '/docs/core-concepts/zero-runtime', children: 'Zero Runtime' },
+          {
+            to: '/docs/core-concepts/no-dependencies',
+            children: 'No Dependencies',
+          },
+          {
+            to: '/docs/core-concepts/style-storage',
+            children: 'Style Storage',
+          },
+        ]}
+      >
+        Core Concepts
+      </MenuItem>
       <MenuItem to="/docs/features">Features</MenuItem>
       <MenuItem
         subMenu={[

From f1892b55c8f335f307383a22cee67b5f258867af Mon Sep 17 00:00:00 2001
From: abyss-s <lh3729@naver.com>
Date: Thu, 9 Oct 2025 13:36:54 +0900
Subject: [PATCH 5/6] docs: remove unnecessary documentation for core concept

---
 .../(detail)/docs/core-concepts/no-dependencies/page.mdx   | 7 +------
 .../app/(detail)/docs/core-concepts/style-storage/page.mdx | 1 -
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/apps/landing/src/app/(detail)/docs/core-concepts/no-dependencies/page.mdx b/apps/landing/src/app/(detail)/docs/core-concepts/no-dependencies/page.mdx
index 7e3aea04..1ee234ea 100644
--- a/apps/landing/src/app/(detail)/docs/core-concepts/no-dependencies/page.mdx
+++ b/apps/landing/src/app/(detail)/docs/core-concepts/no-dependencies/page.mdx
@@ -48,14 +48,9 @@ Our approach is grounded in static analysis. Once code is built and shipped, it
 - 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 (e.g., EasyList-style rules), we segment suspicious tokens by inserting a hyphen while keeping names compact.
+- To avoid common ad-blocker heuristics, we segment suspicious tokens by inserting a hyphen(`-`).
 - Example mappings:
   - `ad` → `a-d`
-  - `ads` → `a-ds`
-  - `adbanner` → `a-dbanner`
-  - `ad_top` → `a-d_top`
-- Generation is deterministic: the same input always yields the same safe class name across builds.
-- The policy does not depend on any specific filter list and typically remains robust as lists evolve.
 - 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.
 
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
index 3b7e6cb3..d221d8eb 100644
--- 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
@@ -16,7 +16,6 @@ This document explains the de-duplication principle, the requirement for a singl
 
 - 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.
-- This happens at build time (when the bundler runs). The generation order can vary depending on the order in which the input code is discovered and analyzed.
 
 ### Why a single storage is required
 

From 956b3b1b39084687e0c0206ea120173ae3f31948 Mon Sep 17 00:00:00 2001
From: abyss-s <lh3729@naver.com>
Date: Thu, 9 Oct 2025 14:30:50 +0900
Subject: [PATCH 6/6] docs: fix className typo in zero-runtime example

---
 .../src/app/(detail)/docs/core-concepts/zero-runtime/page.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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
index c4fe4bfb..b8cf3682 100644
--- 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
@@ -62,7 +62,7 @@ Based on the caching results in step 3, two parallel outputs are produced.
 The bundler (Vite, Rsbuild, Next.js, Webpack) emits optimized code.
 
 ```html
-<button className="btn a b c d">Click me!</button>
+<button className="btn a b c d e">Click me!</button>
 ```
 
 Inline style props are compiled into **atomic CSS classes**, achieving zero runtime.