Browsers have been able to get access to files on disk for longer now than many frontend developers have even had careers—drag and drop was one of the first HTML5 APIs. Same with client-side processing for `<input type="file">` elements. (Directory access through the `webkitdirectory` attribute is another story, but it is supported by all major browsers nowadays—even if it's terribly named and the scary warnings about how it will "probably" go away on MDN haven't been updated.)

As for writing, you don't get unlimited unchecked writes the way that Chrome's proposed Filesystem Access API grants you, but you can trigger "checked" writes (that show a file save dialog) using `<a/>` elements with the `download` attribute. This is arguably a better user experience, because it keeps the user in the loop, allowing them to veto (or rename) the written file at a fine-grained level—which will be difficult or impossible to do if the Chrome team's proposed API because standard.

Overall, the File System Access proposal is a bad one that favors authors over users, and I hope it doesn't become either a de facto or a de jure fixture of the Web platform soon. Here's to hoping for a future post to the Chrome Developers blog announcing that support for yet another experimental API of theirs will be sunset in some future release.