[ciaranmn]

> If you want to promote portability, then blocks should be web components based, full stop. React-based blocks won't be usable without setting up React on the page.

As it stands we're reluctant to dictate the internal implementation of a block, on the assumption that we can abstract away dealing with different implementations - but I agree that the extra requirements for non-native implementations are a downside. We're also conscious of multiple implementation approaches potentially leading to fragmentation, with React-implemented blocks limited to applications who are happy to ship React, and other variations. It's a tricky balance to strike between freedom for the block author (i.e. can they implement it how they want, or must they use X) and work for the embedding application (how many different flavours of block implementation do they need to deal with - albeit we can provide libraries for this).

> Most reusable components these will have an interface described by a type system - this is how IDEs offer code completion and JSX and other template systems are type-checked.

Right - the components describe their interface, but there's no standardization of the shape of the interface. e.g. the format for Web Components you describe allows components to describe their methods, but the Block Protocol aims to standardize what the methods actually are - so that you don't need to read the API of a component to plug it into your app or understand what the methods do.

I believe the two projects are entirely compatible and complementary: a Web Component could have a thin wrapper around it to convert its methods to the expected name/signature specified by the Block Protocol. But I don't think Web Components as they are, in isolation, meet the aims of the BP.

[spankalee]

I think you're misunderstanding web components: Web components aren't an internal implementation - they can have any internal implementation the author wants to use - they're an external interface.

You can build web components with React, Svelte, Lit, Stencil, or just vanilla JS. Given that blocks need an interface, it'd be nice to extend a standard with whatever else you need rather than go completely parallel to the standard.

[ciaranmn]

I appreciate that you can use whatever JS you want when constructing custom elements.

To date we've been looking at how apps can deal with different ways in which blocks can be exposed to the app, but haven't ruled out specifying that they must be exposed in a fixed way - this would make it more consistent, at the cost (which may well be small and largely automatable) of requiring authors to wrap their block, e.g. with a custom element definition.

I'd be interested to talk in more detail about how that might work with relation to the current web component spec and future plans / other work in train: [e-mail] if you're up for it