> 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

> 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?