It’s really easy to complain about yet-another-web-thing. This one is kind of provocative with the “we want it to be everywhere on the web” stance, but that overshadows the proposal’s immediate value: to standardize an already existing, already in-use block-based model of user interaction, which users seem to like in practice. In terms of UI/UX design, this has immediate value to sites which use that model of UX, which is in contrast to a typical “if everyone just uses my new standard, things will be great” kind of proposal.
Demonstrably useful advances in UX design have little impact if the findings aren’t widely known, so this standardization strikes me as a Good Thing. I’m reminded of when CSS grid layout became quite standard, which was (mostly) a Good Thing. I would be worried for the future of web UX if the design philosophies made known and pushed onto web devs continue to be things like SPAs, Bootstrap modals, and clientside rendering.
A block with react in its externals, and a JavaScript entry point, is likely a React component, and the source can be used to create a function which is then rendered like any other React component, with the required functions and properties passed in as props. Any dependencies it expects could be provided by giving a requires function when creating the function.
…so SPAs and client-side rendering galore! Contrary to other crustaceans, I consider SPAs to be, on the whole, a Good Thing. I’ve found the benefits generally outweigh the costs when building interactive web applications.
Blocks I’m less sure of. How does one specify which version of React to use? What if the blocks one is using have conflicting version requirements or require different frameworks altogether? Run them concurrently? (I hope not.) I haven’t yet found answers to these questions. The devil’s in the details and, at first glance, it appears the Block protocol leaves the most important details up to Block consumers.
No. Web Components are just a buzzword and a couple of poorly thought through APIs. Typically people use the term Web Component to refer to custom elements, that is calling a DOM API to register that some JS should process a node with a custom tag like <my-tag>. Custom elements are just a building block (and again a truly terrible API), they don’t really do anything useful compared to just running your own JS when you see <div data-type="my-div">. It’s just a convention, and a poorly thought through one (there’s no actual namespace for custom elements, so it’s a landgrab for the element names, yay!).
The Block protocol is an attempt to create a cross-CMS standard, so it’s more akin to Open Graph data or OEmbed.
I’d go even further and say he’s reinventing html with semantic annotations like rdfa or jsonld.
webcomponents could just be seen as a potential source for new, complex html tags (h1 doesn’t need webcomponents f.e).
On reading the actual spec, the protocol part reminds me a lot on ActivityPub meets IndieWeb meets CMS. Kind of like breaking down and generalizing Mastodon or one of similar things.
Web Components don’t implement data binding or inter-component communication. If you need those things, the most obvious choice is to bake a SPA into a web component. The danger there is the temptation to embed the entirety of the framework into the component for portability’s sake. The create-block-app template creates a React component but excludes React from the build output and codifies (albeit vaguely) the notion of React as an external requirement.
So I have a similar question: if most (all?) Blocks are just React components under the hood, what is all this ceremony adding?
I really liked the idea of OpenDoc back when I was using OS/2. But I never found anything built on top of it other than the example rich-text editor and associated components. Also, my PC was very low-spec for OS/2, so OpenDoc on top of that was a bit of a trudge.
Sort of. But OLE and ActiveX were mostly meant to be composed by developers to assemble custom GUis. These blocks are different in that end users compose them to build their content. (Again, like OpenDoc.)
OLE was also meant to let you embed one document kind in another. KParts in KDE and some of the GNOME stuff as well were all aiming at the same thing. It was a big deal in the 1990’s, and I’d be glad to have a lot of it back again.
These things were all killed by security. With Etoile, we wanted to push even further in that direction but hit the same issue: you want to embed executable content from a third party but you don’t want to trust that third party. Java has shown that complex language-based sandboxing doesn’t work. MMU-based isolation is too expensive if you want to scale it up. WebAssembly doesn’t give confidentiality guarantees in the presence of speculative side channels (a wasm program can leak all of the contents of memory in the enclosing process) but that might not matter if it’s not allowed to make network connections. This is one of the reasons that I started working on CHERI: to be able to build systems where you could run many small untrusted components in a single address space without security problems. Any decade now…
Sure. JVM security depends on every single part of the Java language being implemented correctly. A bug in any part leads to a sandbox escape. A single-bit bitflip can let you escape, so any kind of memory corruption can typically be turned into a sandbox escape. The JVM itself is a hugely complex piece of software. It must be written in an unsafe language because it’s doing intrinsically unsafe things to implement the safe-language abstract machine. It must be bug free for the security invariants to hold.
When it was local on your desktop from you installing software from a (hopefully) trusted source those issues weren’t as big. More innocent times…
I hadn’t seen the CHERI stuff before. That’s really cool! It reminds me vaguely of some of the things the old Burroughs large machines did with typed memory. If I had a reason to justify playing with some of those new boards…
When it was local on your desktop from you installing software from a (hopefully) trusted source those issues weren’t as big. More innocent times…
Unfortunately, that was never the case. You’d get a document on a floppy disk, it contained an embedded object, the object contained malware, and now you were infected. The malware would then embed itself in all outbound documents. They propagated a lot more slowly than when the Internet came along but getting a virus on a floppy was pretty common in the ’80s and ’90s.
I hadn’t seen the CHERI stuff before. That’s really cool! It reminds me vaguely of some of the things the old Burroughs large machines did with typed memory. If I had a reason to justify playing with some of those new boards…
The B5500 was certainly one of my inspirations on CHERI and I think several of the other folks are fans of this architecture.
Microformats are cool. The idea is that you can hide structured data inside HTML without having any ramifications on the presentation, because you can throw arbitrary classes on things and then the microformat decoder will find the microformat structure using XPath or CSS selectors, without really caring about the presentation structure or the real HTML structure at all.
However, this appears to be something more specifically tied to rich editing through the web.
Apples and oranges. An iframe is a view object with no content associated with it. It also loads a different page, which is unnecessary and heavyweight.
heavy weight being a bad thing depends™, its a perf / security tradeoff. If the block is heavy its a good thing because it would take it off the main thread for both webworkers and iframes. So depending on the block it could be a security + perf win.
So, a block is literally using an existing standard.
There are standards for other things as well.
Packages? For web things? That can include type information, data structures, code? Reminds you of one or several things?
Protocols? ActivityPub comes to mind, but there are others as well.
Likewise for structured data. Essentially, pulling together existing standards to unite them.
I’ve commented elsewhere, to me personally, this looks a lot like a specific thing aimed at CMS-like things, the article mentions Wordpress, note taking apps, kanban boards etc. Sure, it would be nice if something like this worked okay, but what would happen is an app would support this, but they’d also want to support old-school Wordpress plugins so now I have to support both, right? Which is what the original XKCD is about, isn’t it?
This is the decentralization we need, but probably won’t get.
Reading the spec a bit closer this seems like… Interesting? I’m not quite sure what to make of it, because it’s asking for blocks to be highly interactive, but doesn’t have much to say about styling yet.
I get the feeling that this could lead to a lot of a kitbashed look on pages, if there isn’t a lot of time/attention paid to markup being built for easily being styled.
And, other than standardizing an approach, I’m not entirely sure what the value for this is going to end up being, yet. Like, we already have embed generators for other sites, that’s a thing.
It almost feels like it’s trying to seize at what Visual Basic used to be, but around the UI metaphor de jur.
But, if anyone can rally a crowd of devs around something like this, it’d be Spolsky and co.
I’m wondering what Joel’s interest is in this? He has always been a great marketer of his own products but this a standard and not a product. Is this his “retirement” gig after making a gigaton of money from selling Trello (and FogBugz)?
It’s seems to be created by hash.ai, which he’s affiliated with. I’d assume they are interested in getting more functionality (i.e. widgets) for document authors/users for free.
I find this interesting as over the past few years, there has been a rise in block based editors / apps.
For example:
Notion implements these concepts (not the protocol mentioned here) to build their block based editor built on top of markdown primitives. You can drag videos, images, pdf files, tables and so many other things. I love this model actually. See “Data Model behind Notion Engineering blog post”
Microsoft is building their own Notion, Coda, Confluence alternative built on block primitives called Microsoft Loop. I’m very excited about this. Currently we use confluence/jira at LinkedIn (where I work) and this could replace that. It integrates with all of Microsoft’s other products like: outlook, Teams, and more.
As someone who is a note maker, I’m most fascinated about building block based experience that compile down to simple primitives like pieces of markdown. I take notes in my text editor in markdown files. Sometimes I wish I could toggle into an editor mode like notion & quickly revert back to text-editing mode.
It’s really easy to complain about yet-another-web-thing. This one is kind of provocative with the “we want it to be everywhere on the web” stance, but that overshadows the proposal’s immediate value: to standardize an already existing, already in-use block-based model of user interaction, which users seem to like in practice. In terms of UI/UX design, this has immediate value to sites which use that model of UX, which is in contrast to a typical “if everyone just uses my new standard, things will be great” kind of proposal.
Demonstrably useful advances in UX design have little impact if the findings aren’t widely known, so this standardization strikes me as a Good Thing. I’m reminded of when CSS grid layout became quite standard, which was (mostly) a Good Thing. I would be worried for the future of web UX if the design philosophies made known and pushed onto web devs continue to be things like SPAs, Bootstrap modals, and clientside rendering.
From the developer’s quick start:
From the consumer’s rendering docs:
…so SPAs and client-side rendering galore! Contrary to other crustaceans, I consider SPAs to be, on the whole, a Good Thing. I’ve found the benefits generally outweigh the costs when building interactive web applications.
Blocks I’m less sure of. How does one specify which version of React to use? What if the blocks one is using have conflicting version requirements or require different frameworks altogether? Run them concurrently? (I hope not.) I haven’t yet found answers to these questions. The devil’s in the details and, at first glance, it appears the Block protocol leaves the most important details up to Block consumers.
Isn’t what Web Components are? What does it solves that existing solution are not good enough for?
No. Web Components are just a buzzword and a couple of poorly thought through APIs. Typically people use the term Web Component to refer to custom elements, that is calling a DOM API to register that some JS should process a node with a custom tag like
<my-tag>. Custom elements are just a building block (and again a truly terrible API), they don’t really do anything useful compared to just running your own JS when you see<div data-type="my-div">. It’s just a convention, and a poorly thought through one (there’s no actual namespace for custom elements, so it’s a landgrab for the element names, yay!).The Block protocol is an attempt to create a cross-CMS standard, so it’s more akin to Open Graph data or OEmbed.
data / schema stuffs
I’d go even further and say he’s reinventing html with semantic annotations like rdfa or jsonld. webcomponents could just be seen as a potential source for new, complex html tags (h1 doesn’t need webcomponents f.e).
On reading the actual spec, the protocol part reminds me a lot on
ActivityPubmeetsIndieWebmeetsCMS. Kind of like breaking down and generalizing Mastodon or one of similar things.Web Components don’t implement data binding or inter-component communication. If you need those things, the most obvious choice is to bake a SPA into a web component. The danger there is the temptation to embed the entirety of the framework into the component for portability’s sake. The
create-block-apptemplate creates a React component but excludes React from the build output and codifies (albeit vaguely) the notion of React as an external requirement.So I have a similar question: if most (all?) Blocks are just React components under the hood, what is all this ceremony adding?
This is cool. Very much aligned with the worthwhile bits of OpenDoc, a bloated 90s design I worked on, but applied to the web.
I really liked the idea of OpenDoc back when I was using OS/2. But I never found anything built on top of it other than the example rich-text editor and associated components. Also, my PC was very low-spec for OS/2, so OpenDoc on top of that was a bit of a trudge.
My thoughts exactly. This an Tim Berners Lee’s new private data pods and there is hope for the web.
Does this make anyone else think of OLE objects, but for the web?
The web is slowly rediscovering the utility and power of 90s GUIs. I think it’s no accident that Joel Spolsky is throwing his weight behind it.
Sort of. But OLE and ActiveX were mostly meant to be composed by developers to assemble custom GUis. These blocks are different in that end users compose them to build their content. (Again, like OpenDoc.)
OLE was also meant to let you embed one document kind in another. KParts in KDE and some of the GNOME stuff as well were all aiming at the same thing. It was a big deal in the 1990’s, and I’d be glad to have a lot of it back again.
These things were all killed by security. With Etoile, we wanted to push even further in that direction but hit the same issue: you want to embed executable content from a third party but you don’t want to trust that third party. Java has shown that complex language-based sandboxing doesn’t work. MMU-based isolation is too expensive if you want to scale it up. WebAssembly doesn’t give confidentiality guarantees in the presence of speculative side channels (a wasm program can leak all of the contents of memory in the enclosing process) but that might not matter if it’s not allowed to make network connections. This is one of the reasons that I started working on CHERI: to be able to build systems where you could run many small untrusted components in a single address space without security problems. Any decade now…
Could you elaborate on that?
Sure. JVM security depends on every single part of the Java language being implemented correctly. A bug in any part leads to a sandbox escape. A single-bit bitflip can let you escape, so any kind of memory corruption can typically be turned into a sandbox escape. The JVM itself is a hugely complex piece of software. It must be written in an unsafe language because it’s doing intrinsically unsafe things to implement the safe-language abstract machine. It must be bug free for the security invariants to hold.
Interesting, that makes sense. Thank you for expanding on your comment!
When it was local on your desktop from you installing software from a (hopefully) trusted source those issues weren’t as big. More innocent times…
I hadn’t seen the CHERI stuff before. That’s really cool! It reminds me vaguely of some of the things the old Burroughs large machines did with typed memory. If I had a reason to justify playing with some of those new boards…
Unfortunately, that was never the case. You’d get a document on a floppy disk, it contained an embedded object, the object contained malware, and now you were infected. The malware would then embed itself in all outbound documents. They propagated a lot more slowly than when the Internet came along but getting a virus on a floppy was pretty common in the ’80s and ’90s.
The B5500 was certainly one of my inspirations on CHERI and I think several of the other folks are fans of this architecture.
Technical description, which is probably a better fit for Lobsters: https://blockprotocol.org/spec#overview
Seems a bit like Microformats (the little bit I skimmed)? http://microformats.org/
Microformats are cool. The idea is that you can hide structured data inside HTML without having any ramifications on the presentation, because you can throw arbitrary classes on things and then the microformat decoder will find the microformat structure using XPath or CSS selectors, without really caring about the presentation structure or the real HTML structure at all.
However, this appears to be something more specifically tied to rich editing through the web.
See also https://microformats.io which I find to be a nicer landing page
I thought iframe already exists?
Apples and oranges. An iframe is a view object with no content associated with it. It also loads a different page, which is unnecessary and heavyweight.
And yet iframes are proposed as a sandboxing mechanism for potential use for blocks here.
heavy weight being a bad thing depends™, its a perf / security tradeoff. If the block is heavy its a good thing because it would take it off the main thread for both webworkers and iframes. So depending on the block it could be a security + perf win.
Situation: There are 15 competing standards.
that’s a lazy response - the problem is there are 15 competing implementations and zero standards. i really hope this blocks endeavour succeeds.
Though there are also standards?
Are there?
From Block Protocol Spec:
So, a block is literally using an existing standard.
There are standards for other things as well. Packages? For web things? That can include type information, data structures, code? Reminds you of one or several things? Protocols? ActivityPub comes to mind, but there are others as well. Likewise for structured data. Essentially, pulling together existing standards to unite them.
I’ve commented elsewhere, to me personally, this looks a lot like a specific thing aimed at CMS-like things, the article mentions Wordpress, note taking apps, kanban boards etc. Sure, it would be nice if something like this worked okay, but what would happen is an app would support this, but they’d also want to support old-school Wordpress plugins so now I have to support both, right? Which is what the original XKCD is about, isn’t it?
I haven’t seen a remotely similar attempt at standardize something like this outside of platform specific stuff. Curious if anybody has examples.
Well, OpenDoc. It ran on Mac, Windows and OS/2. But it wasn’t related to the Web at all.
This is the decentralization we need, but probably won’t get.Reading the spec a bit closer this seems like… Interesting? I’m not quite sure what to make of it, because it’s asking for blocks to be highly interactive, but doesn’t have much to say about styling yet.
I get the feeling that this could lead to a lot of a kitbashed look on pages, if there isn’t a lot of time/attention paid to markup being built for easily being styled.
And, other than standardizing an approach, I’m not entirely sure what the value for this is going to end up being, yet. Like, we already have embed generators for other sites, that’s a thing.
It almost feels like it’s trying to seize at what Visual Basic used to be, but around the UI metaphor de jur.
But, if anyone can rally a crowd of devs around something like this, it’d be Spolsky and co.
I’m wondering what Joel’s interest is in this? He has always been a great marketer of his own products but this a standard and not a product. Is this his “retirement” gig after making a gigaton of money from selling Trello (and FogBugz)?
It’s seems to be created by hash.ai, which he’s affiliated with. I’d assume they are interested in getting more functionality (i.e. widgets) for document authors/users for free.
How is a “block” different from an HTML tag?
I find this interesting as over the past few years, there has been a rise in block based editors / apps. For example:
As someone who is a note maker, I’m most fascinated about building block based experience that compile down to simple primitives like pieces of markdown. I take notes in my text editor in markdown files. Sometimes I wish I could toggle into an editor mode like notion & quickly revert back to text-editing mode.
I found this OS VueJS library which recreates the notion block editor experience, one day..to hack on it https://github.com/CedarXi/All-in-one
This sounds like oEmbed but with interaction to me.
Reminds me of Google Gadgets (rip) kinda, but not just for google things.
[Comment removed by moderator pushcx: Dismissive scorn doesn't prompt good discussion. Don't do this.]