3 ms·

Can someone ELIF? I can synchronize clients around some state using http. What is an http extension? Does it add new http methods? If so, will anyone else be ab

Can someone ELIF? I can synchronize clients around some state using http. What is an http extension? Does it add new http methods? If so, will anyone else be able to respond to these methods? Isn't http stateless what do you mean versioning? And etcetera! I'm sorry to criticize but who is this article written for? It's either so dense that you already need to be an expert to unpack all the information, or the information is not there. I would recommend starting from the assumption that the Hacker News layman knows the http protocol. Make sure what you show us is possible to follow from some reasonable starting point.

toomim 2y ago
HTTP (HyperText Transfer Protocol) is a State Transfer protocol. ReST (Representational State Transfer) is a State Transfer architecture. It was built for transferring a page from server to client. But if the page changed afterward, the protocol threw up its hands, and left it to the user to click "reload." Braid proposes new HTTP headers that give HTTP new features, so that instead of just being a State Transfer protocol, it gains the functionality to become a full State Synchronization protocol. To "extend" a protocol means to add new features to it, e.g. with new headers, which doesn't break existing uses of the protocol, but allows new implementations to opt into new extended functionality. HTTP was originally stateless, but then added cookies. Over time, web apps evolved to store tons of state in databases on the server. Then they started storing tons of state in javascript variables and DOM on the client. Today, most of the code we write in a web app is there to synchronize the changing state on a server with the changing DOM on the client. The web is no longer static pages. It is dynamic state. But since we haven't extended HTTP to support dynamic state, programmers have to write all this synchronization code by hand. This has been a pain in the ass, and so we've evolved monstrous stacks of Javascript frameworks (react, redux, etc. etc.) to try to help manage this state synchronization from server to client. If we build this functionality directly into HTTP, tons of code goes away, and the web itself gains great new features. Then, since we will have a standard for state synchronization, our state can interoperate, and walled siloes of websites break down. We can have a P2P web. When this work is complete, the browser will no longer need a reload button. The browser/server will guarantee that every page is always up-to-date, and every peer that synchronizes with that state will have an equal copy.
- spintin 2y ago
  [dead]
- skybrian 2y ago
  > the browser will no longer need a reload button I think this is skipping over some tricky UI issues regarding updates. For a text-heavy page, maybe you don't actually want a web page to jump around while you're reading it? Maybe there should be a live indicator to indicate that there are new updates, along with a reload button that lets you decide when you want to see them? Browsers themselves do similar things - they let you know there's a new browser version, but you don't have to click "update" right away. You can finish what you're doing. Contrast with video games where things are expected to move around. The visual design is different. There are animations so that you can track objects moving around. Another example: recently I had been playing around with automatic syncing of a web form so that the user wouldn't be editing stale data, but I realized it was confusing so I took it out. For a form, a good time to inform the user that there is an edit conflict is when they press the "submit" button. People expect to see form errors at that point. But live edit indicators and a reload button might be good too? Or what if you're reading a web forum, switch to another tab, then come back again. Should the page automatically refresh when it becomes active? Maybe, maybe not. It could be confusing. Maybe the new messages that appeared while you were away should be indicated somehow? For these reasons, I'm skeptical of automatic browser syncing. I think the web app designer needs control over how to apply live updates. Much like mobile apps were not just desktop apps scaled down, live web pages require different UI conventions. Maybe new HTML widgets?

toomim 2y ago

HTTP (HyperText Transfer Protocol) is a State Transfer protocol. ReST (Representational State Transfer) is a State Transfer architecture. It was built for transferring a page from server to client. But if the page changed afterward, the protocol threw up its hands, and left it to the user to click "reload." Braid proposes new HTTP headers that give HTTP new features, so that instead of just being a State Transfer protocol, it gains the functionality to become a full State Synchronization protocol. To "extend" a protocol means to add new features to it, e.g. with new headers, which doesn't break existing uses of the protocol, but allows new implementations to opt into new extended functionality. HTTP was originally stateless, but then added cookies. Over time, web apps evolved to store tons of state in databases on the server. Then they started storing tons of state in javascript variables and DOM on the client. Today, most of the code we write in a web app is there to synchronize the changing state on a server with the changing DOM on the client. The web is no longer static pages. It is dynamic state. But since we haven't extended HTTP to support dynamic state, programmers have to write all this synchronization code by hand. This has been a pain in the ass, and so we've evolved monstrous stacks of Javascript frameworks (react, redux, etc. etc.) to try to help manage this state synchronization from server to client. If we build this functionality directly into HTTP, tons of code goes away, and the web itself gains great new features. Then, since we will have a standard for state synchronization, our state can interoperate, and walled siloes of websites break down. We can have a P2P web. When this work is complete, the browser will no longer need a reload button. The browser/server will guarantee that every page is always up-to-date, and every peer that synchronizes with that state will have an equal copy.

spintin 2y ago
[dead]
skybrian 2y ago
> the browser will no longer need a reload button I think this is skipping over some tricky UI issues regarding updates. For a text-heavy page, maybe you don't actually want a web page to jump around while you're reading it? Maybe there should be a live indicator to indicate that there are new updates, along with a reload button that lets you decide when you want to see them? Browsers themselves do similar things - they let you know there's a new browser version, but you don't have to click "update" right away. You can finish what you're doing. Contrast with video games where things are expected to move around. The visual design is different. There are animations so that you can track objects moving around. Another example: recently I had been playing around with automatic syncing of a web form so that the user wouldn't be editing stale data, but I realized it was confusing so I took it out. For a form, a good time to inform the user that there is an edit conflict is when they press the "submit" button. People expect to see form errors at that point. But live edit indicators and a reload button might be good too? Or what if you're reading a web forum, switch to another tab, then come back again. Should the page automatically refresh when it becomes active? Maybe, maybe not. It could be confusing. Maybe the new messages that appeared while you were away should be indicated somehow? For these reasons, I'm skeptical of automatic browser syncing. I think the web app designer needs control over how to apply live updates. Much like mobile apps were not just desktop apps scaled down, live web pages require different UI conventions. Maybe new HTML widgets?