Chapter 65: What Kitsune Is Not

The closing chapter of Part VI is honest about what the architecture doesn’t try to be.

A book that argues for a specific architectural approach has to acknowledge where the approach doesn’t fit. Kitsune is one tool. There are categories of application it doesn’t serve well, problems it doesn’t solve, and adjacent tools that the team should reach for instead. Naming these honestly is part of the architecture’s credibility.

This chapter walks through the major non-targets. The chapter is short on prose and direct in its claims. The reader who has come this far has earned the honest accounting.

What Kitsune Is Not: A Real-Time Framework

Kitsune is not, by itself, a real-time collaborative-editing framework.

Chapter 68 walked through how real-time work composes with the architecture — a CRDT library like Yjs as a module, WebSockets for transport, the runtime’s event bus for fan-out. The composition works for many real-time use cases. But for applications where real-time is the product — Figma-class design tools, Notion-class collaborative editors, multiplayer games — the architecture is a substrate; the real-time engineering is the actual product.

For those applications, dedicated tools like Yjs, Liveblocks, or proprietary frameworks like Figma’s internal engine are what the team will spend most of their engineering time on. Kit’s role is the non-real-time parts (the chrome around the canvas, the settings, the user management, the auth flow). For the canvas itself, the application’s main interaction loop is going to be designed around the real-time substrate, not around Kit’s event bus.

What Kitsune Is Not: A Server-Rendering Framework

Kitsune doesn’t render HTML on a server. The runtime runs in browsers. The component library runs in browsers.

For server-side rendering, the team uses an existing tool — Astro, Rails, Django, Phoenix, Laravel, Next.js (with the Kit React adapter for the components), or any other server-rendering framework. The team’s choice depends on their backend language, their hosting platform, their existing infrastructure.

Kit ships with @lit-labs/ssr integration so individual components can be rendered to HTML strings (with declarative shadow DOM) for inclusion in any server’s output. The pattern is Kit components in someone else’s template. Kit doesn’t try to be the template engine.

This is the right division. Server rendering is a mature category with strong tools per language; Kit doesn’t have an opinion about which one the team uses.

What Kitsune Is Not: A Native Mobile UI Kit

Kit ships web technologies. The components render to the DOM. The runtime uses web APIs.

For native mobile UI — using UIKit or SwiftUI on iOS, Jetpack Compose on Android — Kit isn’t the right tool. Those platforms have their own design systems, their own component models, their own architectural conventions.

For cross-platform mobile through web technologies — Capacitor, Tauri Mobile, the various PWA approaches — Kit works. The components are real custom elements; the platforms can host them. The pattern composes with the rest of Capacitor’s plugin ecosystem.

What Kitsune Is Not: A Build Tool

Kit doesn’t bundle, transpile, or transform the application’s code. The team uses Vite, Webpack, esbuild, Rollup, Parcel, Bun’s bundler, or any other tool that handles JavaScript modules. Kit ships as standard npm packages; whichever bundler the team uses imports them like any other dependency.

The team’s build configuration is the team’s. Kit doesn’t dictate it.

What Kitsune Is Not: An Animation Library

Kit components include some animation (button hover transitions, dialog open/close, container-query layout shifts). For application-level animation — complex sequences, scroll-driven effects, generative motion, brand-specific animation systems — the team uses GSAP, Framer Motion, Motion One, or the platform’s own Web Animations API.

The architecture doesn’t impose an animation library. The Kit components style themselves; the application’s animation is whatever the team wants.

What Kitsune Is Not: A Data Layer

The architecture provides patterns for the data layer (the repository pattern, the adapter pattern, validation at the boundary — Chapter 43). It doesn’t provide the implementation. The team implements repositories against their server’s API; the team implements adapters between their server’s shape and the client’s; the team picks a validator (Zod, Valibot, hand-written, whatever).

For applications where the data layer is non-trivial — complex caching, optimistic updates, normalized state — the team may add TanStack Query, Apollo Client, or another data-fetching library on top of Kit’s architecture. The architecture composes with these; it doesn’t replace them.

What Kitsune Is Not: A Visualization Library

For charts, graphs, network diagrams, geographic visualizations, scientific plots — the team uses D3, Observable Plot, Chart.js, ECharts, Vega-Lite, deck.gl, or another visualization-specific library.

Kit’s components are general-purpose UI primitives — buttons, dialogs, forms, fields. Specialized visualization is its own engineering domain. The Kit architecture’s role for visualization-heavy applications is the chrome (navigation, controls, settings); the visualization itself is the specialized library’s domain.

What Kitsune Is Not: A Rich-Text Editor

Editors like ProseMirror, Slate, Lexical, Tiptap, and CKEditor are specialized libraries for rich-text editing. The problem space (selection handling, undo/redo, IME composition, mention support, formatting, embeddings, collaboration) is its own engineering discipline.

Kit applications can include rich-text editors as third-party components inside the architecture. The metadata boundary observes events from the editor; the runtime distributes them; capability modules respond. The editor itself stays specialized.

What Kitsune Is Not: A WYSIWYG Page Builder

For visual page-building tools — Webflow, Framer’s editor, Notion’s block-based editor — Kit isn’t the tool. Those products are specialized for non-developers building UIs visually. They have their own component models, their own constraint systems, their own deployment pipelines.

Kit is for developers building applications in code. The distinction matters; they’re different problems.

What Kitsune Is Not: An AI Tool

Kit’s architecture is designed to receive AI-generated UI (Chapter 73). It’s not an AI tool itself. The team brings their own AI integration — the model provider, the prompt engineering, the conversation management, the structured output handling.

The architecture’s role is to be the substrate AI-generated UI lands on. The AI engineering is the team’s specialized work. The two compose; neither tries to be the other.

What Kitsune Is Not: A Complete Solution

A more philosophical point. Kit isn’t a complete solution for any application. It’s a coordination layer. The application still has to:

Have a UI that works (designed by the team’s designers).
Have a backend (built by the team’s backend engineers).
Have a data model (designed by the team’s data engineers).
Have an auth system (selected and integrated by the team).
Have a deployment pipeline (configured by the team’s platform engineers).
Have a testing strategy (built by the team).
Have an accessibility commitment (maintained by the team).
Have an internationalization strategy (executed by the team).

Kit handles a specific architectural surface — the coordination between UI and capability modules, with the platform’s primitives as the substrate. The rest of the application is still the team’s responsibility.

This is the right scope. A framework that tried to handle everything would be enormous, opinionated about things it shouldn’t be opinionated about, and brittle to change. Kit’s deliberate smallness is what makes it adoptable, composable, and maintainable.

Where Kit Earns Its Keep

The honest version of the inverse claim. Kit earns its keep for applications that:

Are built primarily with forms, lists, dialogs, navigation, and standard UI patterns.
Have meaningful cross-cutting concerns (analytics, audit, observability, permissions, notifications) that the team wants to manage centrally.
Care about accessibility, performance, supply-chain risk, or AI-generated UI compatibility.
Will be maintained over years, by teams that turn over, with code that should survive framework churn.

For these applications, Kit is the right shape. The architecture’s small surface delivers substantial value. The team’s investment in learning the architecture is rewarded over the application’s lifetime.

For applications that don’t match this profile — the real-time tools, the visualization-heavy products, the specialized editors — the team should reach for the dedicated tool. Kit can coexist (the chrome around the dedicated tool can be Kit-architected) but isn’t the application’s center.

Closing Part VI

Part VI has been the maintained version. The runtime, the shell, the boundaries, the metadata, the events and commands, the diagnostics, five application walkthroughs, the React adapter, and the honest accounting of what the architecture is not.

The book has been working toward this. Parts I–II gave the historical and platform context. Parts III–V developed the architecture’s principles, hand-built implementation, and component library. Part VII covered production concerns. Part VIII looked at the AI-generated future. Part VI is the maintained tool — the thing real teams adopt for real work.

The chapter closes Part VI; the book’s chapters are now complete. Whatever the reader builds next, the architecture is one of the tools available. The depth from Parts I–V is the more durable contribution; the architecture is one expression of that depth.

Exercise: Match the Tool to the Problem

Make a list of five applications you might build in the next year — features for your current job, side projects, possible future products, anything. For each one, decide:

Is Kit the right architectural choice? Why or why not?
What other tools would the application use? (Server framework, real-time substrate, visualization library, AI integration, etc.)
How would the tools compose? (Kit for the chrome, dedicated tools for the specialized concerns?)
What’s the team’s time horizon for the application?
Would the architectural investment in Kit pay off given the time horizon?

For some applications, Kit will be the obvious right answer. For others, it’ll be the wrong choice — and naming why is useful.

The exercise is the architectural judgment Chapter 72 argued for, applied to specific projects. The depth lets the team make these calls deliberately, with the trade-offs visible. Kit is one tool. The depth — the thing the book has been transmitting — is what makes the tool useful.

Part VI ends here. The architecture is documented. The applications are walked through. The integrations are mapped. The honest accounting is on the page. What the reader builds next is theirs.