• Embrace the Web Platform
• Use any server-side technology to render HTML
• Have components
• Have reactivity
• Have type safety
• Have optimal performance
• Have fun!

UIElement assumes you start with semantic HTML and want to enhance it with behavior:

<hello-world>
  <p>Hello, <span>Alice</span>!</p>
</hello-world>

This means better SEO, faster initial page loads, and progressive enhancement that works even when JavaScript fails.

Progressively enhance the user experience by adding interactivity:

import { asString, component, setText } from '@zeix/ui-element'

component('hello-world', { name: asString() }, (_, { first }) => [
  first('span', setText('name')),
])

UIElement augments what the platform already provides. It leverages the Web Components standard while adding just enough convenience functions to make reactive UI behaviors easy to implement.

• Unlike SPA frameworks (React, Vue, Angular, Svelte, Lit, etc.) we never render on the client. Instead, the server and browser do this work. Like it's 1995.
• Because we never render on the client, we need no JSON data and no JS templates either. This means less data over the wire and no plumbing DB → JSON → JS → HTML.
• Unlike Hypermedia frameworks (HTMX, Datastar) we don't compensate for the lack of client-side rendering by a network request if not needed. If possible, we calculate the new state on the client.
• We just add event listeners and set up a signal graph. Invisible work that doesn't cause layout shifts.
• When the user interacts with the UI, we know exactly what to do. We just do fine-grained updates to the DOM. No VDOM, no diffing. Wait for signal 🚦 and go! 🏁

Because we add less abstractions, we can keep the library small (approximately 5kB gzipped).

UIElement is a lightweight library that provides a simple and efficient way to build reactive user interfaces. It is designed to be easy to use and understand, while still providing powerful features for building complex applications.

HTML ain't broken. CSS ain't broken. JavaScript ain't broken. We just want to split it in chunks (components), detect bugs early (type safety), and have predictable updates without tight coupling (reactivity). That's what we stand for.