[ciaranmn]

This is correct: it's the standardization of the interface between blocks and things using them, which includes structure in the data being passed back and forth, and the structure of the interface itself (e.g. what operations are available).

We do want to promote the free exchange of structured data, and to have data captured and marked up according to some structure - we also want to promote the portability and easy-of-setup of UI components.

Our FAQ illustrates how we relate to and intend to use existing standards - https://blockprotocol.org/docs/faq - we'd be interested in any others you think worth building on.

[spankalee]

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.

I think the FAQ around leaves a lot more open questions. Like:

> but they do not standardize the interface between those blocks and the applications using them

I'm not sure this is entirely true. 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.

In the Web Components Community Group we're also standardizing a format for describing the entire interface of a web component, including its attributes, properties, events, methods, CSS variables and parts, etc. This is called the Custom Element Manifest: https://github.com/webcomponents/custom-elements-manifest

Instead of being tied to json-ld, the manifest just documents what JS/TS type a property, etc., has. If a component has a person property that accepts a Person type, a tool can understand that.

This manifest will give tools like catalogs, linters, and visual UI builders enough information to do high-level operations like generate demos, lint templates, assemble components without code, etc.

[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