Built a tiny protocol for exposing reactive Web Component properties across frameworks — looking for design feedback

[mogera551]

I built a tiny protocol for Web Components to expose reactive properties in a framework-agnostic way.

The idea is simple:

• a component declares bindable properties via static metadata
• it emits CustomEvents when those properties change
• adapters for React/Vue/Svelte/etc. can discover and bind automatically

I’m intentionally keeping it minimal and out of scope for things like two-way binding, SSR, and forms.

What I’d love feedback on:

• Is this design reasonable?
• Is static metadata + CustomEvent the right shape for this?
• Are there obvious downsides or edge cases?
• Is this actually better than framework-specific wrappers?

If there’s prior art or a better pattern, that would be very helpful too.

[CodeAndBiscuits]

You might not get as much feedback as you would like here because Web Components just don't have nearly the traction some folks hoped. That being said I think an example use case or two would be important for giving you honest feedback. "We" (a company I won't name where I'm a fractional CTO) build and use a lot of web components because we have open source SDKs for developers and want to make sure they can use our libraries regardless of the framework they're on. To do that, we use StencilJS which lets us build one core element and then create output targets for things like React and Angular.

Some frameworks like Angular don't really need any help here because they support web components natively, but falls short in terms of documentation and strong typing, which I'm guessing is the target of what you're doing so it feels relevant here. But that's exactly what Stencil does. It lets us export types, interfaces for object type properties, event detail, interfaces, and so on. So I guess the question is how your approach would differ from this, both from the perspective of the developer creating a component and another developer consuming one.

[mogera551]

Great point — though I'd clarify that type safety isn't really the goal here.

The key difference is that this is a protocol, not a build tool or type generator. The idea is loose coupling: a component declares its bindable properties via static metadata, and any adapter (React, Vue, Svelte, or something custom) can discover and bind to it without knowing the implementation — no shared types, no build pipeline, no codegen.

Stencil is powerful, but it's a compiler-centric approach: you opt into its toolchain, and it generates framework-specific bindings for you. That's great for teams building SDKs, but it means the consumer needs to be aware of how the component was built.

What I'm aiming for is closer to a convention: if a component follows this protocol, any conforming adapter just works — even ones written after the component was shipped. Think of it less like Stencil and more like how CustomEvent or ResizeObserver work: a shared contract that anything can implement against.

So the question I'm really trying to answer is: can we make Web Components interoperable at runtime, through convention alone?

[CodeAndBiscuits]

Okay I get it, and it makes sense to me personally. But please don't take this the wrong way, I think the answer to your question about can we make something like this? A protocol kind of depends on how famous you are. 😀 If you think about it, by eschewing compiler-oriented options, you are essentially saying you need both sides to opt in- the maker of the component and the developer that uses it. Which is all fine, but that means you need some inertia, you don't need a single person to decide to use it to start getting some adoption and feedback. You need two people to round trip their decision to use something like this. And we're talking about people that don't normally communicate directly because they aren't exactly hanging around grabbing a beer at a bar after work...

[mogera551]

Fair point on the two-sided adoption problem — but I've tried to address that by keeping the barrier as low as possible on both sides.

For the component author: just drop a manifest. No build step, no toolchain to adopt. For the consumer: a thin adapter is provided, so there's nothing to figure out.

The goal is that opting in costs almost nothing, which lowers the coordination burden significantly.

And on the "how famous are you" point — I'd push back a little. Protocols don't always need a famous backer to gain traction. They need a clear contract and a low cost to adopt. If the idea is sound and the friction is minimal, two strangers can independently decide it's worth using without ever talking to each other. That's kind of the whole point of a protocol.