3 ms·
On automatic website refreshing: See guidelines 97 and 98 from Jakob Nielsen and Marie Tahir's book 50 Websites Deconstructed [1] for the primary reason why th
by dhx 15y ago
On automatic website refreshing:
See guidelines 97 and 98 from Jakob Nielsen and Marie Tahir's book 50 Websites Deconstructed [1] for the primary reason why there has been little interest in removing the "refresh" button from browsers.
Technical limitations don't really exist (and if they do exist it'd be fairly easy to solve). Server-sent events[2] and WebSocket[3] are already implemented in the latest versions of popular browsers. Modules or implementations within popular HTTP servers already exist for doing HTTP push (they tend to use older AJAX-like techniques though).
If usability was no concern (or very carefully handled) it'd be fairly easy to write your own nginx module or "WebSocket server"[4] that uses inotify to check for file system changes. For each change that impacts an open WebSocket connection, a "refresh this page" notification can be sent to the browser (which then uses JavaScript to force a page refresh). There is a potential for smarter refresh mechanisms in browsers that maintain the current scroll state, field values, etc but you'd still be frustrating the user with severe usability problems.
[1] http://www.useit.com/homepageusability/guidelines.html http://www.useit.com/homepageusability/guidelines.html
[2] https://en.wikipedia.org/wiki/Server-sent_events https://en.wikipedia.org/wiki/Server-sent_events
[3] https://en.wikipedia.org/wiki/WebSockets https://en.wikipedia.org/wiki/WebSockets
[4] http://altdevblogaday.com/2012/01/23/writing-your-own-websocket-server/ http://altdevblogaday.com/2012/01/23/writing-your-own-websoc...
- gaius 15y agoYes but none of these things existed in 1993. You can call it "lazy" I suppose that TBL didn't implement all the features you take for granted 20 years later before releasing the first browser(!)
- javascriptlol 15y agoIt's lazy when your platform still has mandatory polling decades after interrupt driven programming was invented.
- icebraining 15y agoInterrupts are not without drawbacks. There are valid reasons to not implement them, particularly on the web.
- javascriptlol 15y agoSo, WebSockets are a mistake then?
- icebraining 15y agoWebsockets are like airplanes: useful, but not for daily commuting.
- javascriptlol 15y agoSo do you have any technical points to make, or just more dumb excuses? If you don't want interrupts, you just use them to implement polling.
- icebraining 15y agoInterrupts are stateful on the server side; that creates problems in terms of scalability, both due to increased memory usage and by being less flexible (either you have each user "locked" to a single process, or you have to implement state sharing, which adds overhead). It can also be extremely wasteful - if I leave a tab open for hours or days, you'll have to waste your resources and mine to keep pushing me stuff I won't see, while now I just hit refresh when I want to see new content. In terms of usability, it's often jarring to watch content change when you're interacting with it - that's why even sites that implement real time notifications often have a link or button that you have to press to update the UI. In many cases, doing that completely negates the benefits of pushing. Also, see the thesis on "Architectural Styles and the Design of Network-based Software Architectures": http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Polling is a good default for the web; it fits most use cases (content that rarely changes) in a simple and economical way. WebSockets are useful for the exceptions.