DEV Community: JVM

# I Built an AI-Driven Component Library with Web Components

JVM — Fri, 25 Sep 2026 12:13:10 +0000

An AI coding assistant can produce a convincing interface while getting a component's API wrong. A property might belong to another library. An event handler might use the wrong event name. A screen might look right while its form never submits.

For a component library, that raises a practical question: how do you give an assistant enough context to use the components correctly?

My approach with AWC UI is to ship that context alongside the code: component manuals, machine-readable API metadata, project instructions, and an optional MCP server.

That is what I mean by “AI-driven” here: supporting the workflow of building interfaces with an AI coding assistant. The components themselves run as ordinary Web Components in your application.

AWC UI is an MIT-licensed Material Design 3 library built with Stencil. It includes 56+ components, with integrations for React, Angular, Vue, Svelte, and plain HTML. The catalog covers forms, navigation, dialogs, tables, and charts, with shared theming and density controls.

The part I want to explain in this post is how an assistant can discover and use those components.

Start with the documentation for the installed version.

Core includes a library-level guide, main-llm.md, and individual component manuals inside the npm package. This gives an assistant a reference that travels with the dependency installed in your project.

Those manuals cover more than property names. They include component selection, events, slots, styling hooks, keyboard behavior, and common integration mistakes. They also explain when another component would be a better fit.

For example, this is valid AWC UI button markup:

<md-button variant="filled" size="sm" type="submit">
  Save changes
</md-button>

The button manual explains several details that matter when generating the surrounding code:

sm is the default size.
loading makes the button inert as well as showing its loading state.
soft-disabled keeps an unavailable action in the keyboard tab order.
type="submit" participates in the surrounding form's submission and validation.

These details affect behavior, even when two implementations look similar in a screenshot. They are useful things for an assistant to read before editing a form.

Connect your assistant to those manuals.

With a supported Node version—22.13+ on the 22.x line, or 24+—run this from your app's directory:

npm install @awc-ui/core
npx --no-install awc-ui ai-setup

The setup command adds documentation references to the project instruction files used by Codex, Claude Code, Cursor, and GitHub Copilot. Those references point into the installed Core package.

You can preview the changes first:

npx --no-install awc-ui ai-setup --dry-run

Then give your assistant a task with a clear outcome. For example:

Add a customer settings form to this app using AWC UI. Keep the existing framework, routing, and theme. Include a required email field and a save action. Read the relevant component manuals before implementing, then check keyboard navigation and form validation.

This setup supplies library context. Framework configuration and implementation still follow the needs of your application. The Building with AI guide covers setup and optional build and review skills.

MCP makes the same documentation searchable through tools.

For assistants that support the Model Context Protocol, AWC UI also provides the optional @awc-ui/mcp server.

It exposes four tools:

Tool	What the assistant can retrieve
`search_components`	Components matching a name or use case
`get_component`	A component's manual, structured API, or both
`list_guides`	Available framework, theming, and other guides
`get_guide`	The content of a selected guide

For clients using an mcpServers configuration, the entry looks like this:

{
  "mcpServers": {
    "awc-ui": {
      "command": "npx",
      "args": ["-y", "@awc-ui/mcp"]
    }
  }
}

The server bundles its documentation and serves it locally after installation. Its tools provide read-only documentation access; your coding assistant uses its own tools to edit and run your application.

Version matching matters here. MCP responses report a coreVersion, which should be checked against the Core version installed in your app. If they differ, the manuals in your installed Core package provide the reference for that application.

Alongside the prose documentation, Core publishes a custom-elements.json manifest describing elements, properties, events, slots, CSS parts, and CSS custom properties. That structured data is useful to IDEs and documentation tools as well as the MCP integration.

The output still needs to be checked.

This setup gives an assistant concrete information to consult. It does not guarantee that every generated interface is correct, and I am not presenting a benchmark claiming a particular improvement in accuracy.

For a generated form, I would still check empty and invalid values, keyboard operation, submission behavior, and the result on a narrow screen. For a server-rendered application, I would also check the framework integration and hydration behavior. Component documentation is one input to that work.

If you want to try the approach, pick one small feature in an existing project, connect the documentation, and ask your assistant to implement it. That makes it easier to inspect the result and identify any missing guidance.

You can explore the live components, follow the AI setup guide, or browse the source on GitHub.

If you use AI tools for frontend development, where do they most often get component libraries wrong: API names, styling, forms, or accessibility? I would like to use those examples to improve AWC UI's documentation and integrations.

Introducing AWC UI: Material Design 3 for React, Angular, Vue and Svelte

JVM — Thu, 17 Sep 2026 13:54:55 +0000

I started building AWC UI because I couldn't find a Material Design 3 library that covered my needs for enterprise applications while remaining framework-agnostic.

I wanted one consistent set of components I could use across React, Angular, Vue and Svelte, with the practical features that larger applications need: accessible forms, theming, RTL support and server-side rendering.

AWC UI is the result: an open-source library of 56 Material Design 3 components built on standard Web Components. The core is free under the MIT license.

You can explore the components or try the application showcases directly in your browser.

One component system across different frameworks

When different teams use different frameworks, keeping a consistent interface can mean maintaining several implementations of the same design system.

AWC UI gives those applications a shared component foundation. It works with React, Angular, Vue, Svelte and plain HTML, with framework integrations and TypeScript support. Your teams can keep their application stack while sharing the same visual language and component behaviour.

More of the pieces an application needs

A business application needs forms, navigation, dialogs, tables and feedback states, as well as buttons.

AWC UI brings these together with date and time pickers, autocomplete, multi-select, an organization chart and essential charts. They share Material Design 3 styling and behaviour, which reduces the work of combining unrelated UI packages and making them feel consistent.

Form controls also integrate with native HTML forms, including submission, validation and reset. That means less custom plumbing around everyday form interactions.

Accessibility and internationalization from the start

Keyboard navigation, focus management, ARIA semantics and screen-reader support are part of the component work, with automated accessibility checks against WCAG 2.1 AA criteria.

The goal is to give developers a stronger starting point for accessible interfaces. The finished application's accessibility still depends on how its screens are designed and assembled.

Built-in RTL support and localizable component text help teams build for different languages without maintaining a separate set of controls for right-to-left layouts.

A shared design system that can match your product

Material Design 3 provides the foundation, and design tokens let you adapt it to your brand. AWC UI includes light and dark themes, a theme generator based on seed colours, and component-level styling options.

A density system lets you adjust spacing for information-heavy screens. A dashboard and a settings page can use the same components at a density that fits each workflow.

Practical features for development and maintenance

Zero third-party runtime dependencies in the core package: a smaller dependency surface to maintain.
Server-side rendering: documented integrations for Next.js, Nuxt, SvelteKit and Angular SSR, using Declarative Shadow DOM.
AI-ready documentation: component APIs and usage guidance ship with the package, so coding assistants can use documentation that matches the installed version.
Open source: inspect the implementation, report issues and contribute improvements on GitHub.

These are the kinds of needs I had in mind when building AWC UI for enterprise applications: consistent UI across stacks, configurable themes, internationalization and predictable form behaviour.

See what you can build

The Components page has interactive demos, API documentation and examples for each supported framework.

The Showcases bring those components together into demonstration applications for banking, healthcare, booking and other workflows. They're a way to explore complete screens and interactions before trying the library in your own project.

You can also inspect component variants in Storybook.

Start with the components and the showcases. If AWC UI fits your project, the documentation will take you through installation and integration.

The source is on GitHub, and the core package is on npm. If you'd like to follow the project, a GitHub star is appreciated.

What would you need from a component library before adopting it in your team?