This is, as others have commented, a much better explanation than the article at the top of this thread.
But I'm not sure it's quite as simple as Joel makes it seem here:
> If you work on any kind of editor—be it a blogging tool, a note-taking app, a content management system, or anything like that—you should allow your users to embed blocks that conform to the Block Protocol. This way you can write the embedding code once and immediately make your editor able to embed a rich variety of block types with no extra work on your part.
I don't see how this would work. Sure, the data would be embeddable anywhere, but how does the editor know how to display it to the user and let the user interact with it? That's not just "embedding code". And later on:
> Want to create a block that shows the Great Circle routing for a flight between two airports? Write the code for the block once and it can be embedded anywhere.
Again, how does the application it's being embedded in know how to display it to the user? That seems like it requires more than just "embedding code". Each new kind of block requires each application to add code to use the block.
I agree the data exchange interoperability part is nice, but I'm not sure about the code reduction that seems to be implied here.
Reading The Fine Manual here : (https://blockprotocol.org/spec) - blocks are expected to include code to render the block information in a displayable format. So, a block isn't just the data model, it's also the view layer. Some options suggested in the spec include React, vanilla HTML, and Web Components. This part feels a little mushy at the moment, since there's no proposal yet for how a Block identifies which rendering context it expects.
> Some options suggested in the spec include React, vanilla HTML, and Web Components.
Ah, ok. So the code is only expected to run in a browser, not an arbitrary application. Although since the spec is open, I have no doubt there will be efforts to write code for handling blocks in non-browser applications.
At the moment, yes - we want to figure out the principles of application/block interaction in a web context first, and then move on to other environments. The principles should be transferable, although some of the 'how are they implemented' won't be (https://blockprotocol.org/docs/faq#what-about-non-web-contex...)
The comment above you is right that 'handling blocks implemented in different ways' (in a web context) is one of the mushier parts of the spec, and it's something we need to do more prototyping and refinement of.
I imagine there will be some JS libraries you can drop in to render various block types. I don't think that will solve all problems, but it makes it so the protocol doesn't need to specify a presentation layer. Otherwise you may as well use iframes...
We will be providing these, yes - we want to minimise the amount of work embedding applications have to do in setting themselves up to render blocks, as well as making it easier for block authors to write them.
Is it a better explanation? After reading this I still don't know where the UI code or "editor" state is hosted, or who are the parties to the supposed "protocol". If none of these are questions the "block protocol" is intended to answer, what makes it more interesting or in any way different from a UI framework?
The parties to the protocol (in this early form, with a web focus) are:
1) an application which is generating a web page, and
2) a block of functionality which is part of that page.
Or the authors of each.
Where is state?: blocks can have their own local state, but to persist data beyond the session should make use of the operations defined in the spec to pass data back to the application (the standardisation of what these operations are and what they do is a key part of the spec).
Where is the UI code?: I might've misunderstood this question, but - a block should have a package which contains code for rendering its UI and dealing with data to/from the application embedding it. The application can then either pull that code at runtime (e.g. from a CDN) when a user requests to use a certain block, or include it as a library and ship it with the application.
But I'm not sure it's quite as simple as Joel makes it seem here:
> If you work on any kind of editor—be it a blogging tool, a note-taking app, a content management system, or anything like that—you should allow your users to embed blocks that conform to the Block Protocol. This way you can write the embedding code once and immediately make your editor able to embed a rich variety of block types with no extra work on your part.
I don't see how this would work. Sure, the data would be embeddable anywhere, but how does the editor know how to display it to the user and let the user interact with it? That's not just "embedding code". And later on:
> Want to create a block that shows the Great Circle routing for a flight between two airports? Write the code for the block once and it can be embedded anywhere.
Again, how does the application it's being embedded in know how to display it to the user? That seems like it requires more than just "embedding code". Each new kind of block requires each application to add code to use the block.
I agree the data exchange interoperability part is nice, but I'm not sure about the code reduction that seems to be implied here.