This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It would be quite nice if there was the ability to get events from the os when a file has been modified/updated/deleted. A possible use case might be an online resource editor, where a user drag drops the folder full of resources they wish to view and edit. But if one of the files the browser has access to is edited in another program on their computer (Example photoshop, paint, notepad etc) the javascript application could then receive an event for the file change and update the content/reload file as necessary. Currently I think the only way to do this is to poll the file.lastModifiedDate continuously. Which sure I guess could be used but its not as optimal as listening for events given by the OS would be.
There are a number of webdev tools that do this, in an OS-dependent way. (They're unfortunately mostly limited to OSX, so I can't use them.) They're super-useful, as they run build steps/refresh the browser automatically when you make a change, automating much of the development cycle when working on something locally.
There are a few moving parts here that are worth talking about: 1. The gradual "de-emphasizing" of events on the web. This is a bit subjective, but it seems to me that adding a new type of event is no longer in vogue given other developments. 2. The Streams API: https://streams.spec.whatwg.org/ There's an open issue for me to consider it in FileSystem API: https://github.com/w3c/filesystem-api/issues/2 (that's https://streams.spec.whatwg.org/). If developed correctly, maybe that would answer this use case; but, that's hard to say right now, since the API is in flux. 3. JS Observables, possibly in ECMAScript: https://github.com/jhusain/observable-spec which we refer to in the FileSystem API as a placeholder.
(In reply to Arun from comment #2) > There are a few moving parts here that are worth talking about: > > 1. The gradual "de-emphasizing" of events on the web. This is a bit > subjective, but it seems to me that adding a new type of event is no longer > in vogue given other developments. > Events are perfectly fine. Events work well in certain contexts, Promises in some others.
(In reply to Arun from comment #2) > There are a few moving parts here that are worth talking about: > > 1. The gradual "de-emphasizing" of events on the web. This is a bit > subjective, but it seems to me that adding a new type of event is no longer > in vogue given other developments. Yeah, there's absolutely nothing wrong with events. We just finally have better options for cases where events aren't an ideal fit. But this seems like a pretty classic "event" use-case.