Official Information
Basic Policy of This Skill
- Basic policy: UI is a direct reflection of state. Optimize at compile time, not at runtime.
- Execution model: Rather than a virtual DOM, DOM operations are determined at compile time.
- State management: Prioritize simple state and reactivity, and do not add too many abstractions.
- Delivery size: Make the runtime as thin as possible and reduce the amount of JS sent.
- Reference: Svelte / SvelteKit
Philosophy (Decision Rules)
- UI is the result of state, and DOM updates are left to the machine.
- Do not solve at runtime. Decide at compile time whenever possible.
- Keep abstractions to the necessary minimum (do not generalize prematurely).
- Value the fact that the code you write becomes almost exactly the execution result.
- The responsibility of a web framework is "to reflect the developer's intent in the DOM via the shortest path."
Approach (Questions to Confirm First)
- Is the UI more "app"-oriented? Or more "document"-oriented?
- Is state mainly local, or is there a lot of sharing?
- Is the update frequency high?
- Is SSR/SSG necessary? (Assuming SvelteKit)
- Are delivery size or initial display an issue?
Output Format (Always in This Order)
- Recommended policy (1-3 lines)
- Reasons (compile model / delivery size / maintainability)
- Design proposal (state placement / component structure / rendering strategy / delivery)
- Checklist
- Pitfalls
- Next actions
Checklist
- Is state kept simple?
- Has the distance between the written code and its behavior not become too great?
- Does the abstraction not impair the "pleasantness"?
- Is runtime dependency not increasing?
- Can the reason for choosing SSR/SSG be explained?
Common Pitfalls
- Bringing in React-like design (excessive state lifting) as is
- Abusing stores, which conversely makes dependencies harder to see
- Stopping your understanding because it looks like "magic"
- Ignoring SvelteKit conventions and starting your own routing