7 ms·

Relying upon browser features for native access will be trouble. Google could revoke the feature from chromium at any time. And in any real application you will

Relying upon browser features for native access will be trouble. Google could revoke the feature from chromium at any time. And in any real application you will need to interact with plenty of folders users cannot be expected to know, like Appdata.

Klathmon 8y ago
By that line of thinking relying on OS APIs will be trouble as Microsoft or Apple could remove features at any time.
- devwastaken 8y ago
  If they are shiny new features, absolutely. Browser features, especially from Google, are notorious in being experimental and removed when they want to be. Browsers in general will remove things unless their internal teams find use for them. Browsers do not want to support more features than they have to, as can be seen by subscribing and listening in on the mailing lists for Firefox. However your equivalence in this case is a completely false one, because file system API's are not going to just be 'removed' as that would break literally every application that uses standard fopen. over 20 years of standard is a pretty good boat to stand on unless there's signals that say otherwise.
  - Klathmon 8y ago
    Well sure you shouldn't rely on anything new for core aspects of your application without a plan for what happens if they go away. Especially when the API in question isn't even implemented yet... But that's not how I understood your comment above, which was to not rely on any browser features for native access, which IMO isn't good advice. Sure, you shouldn't go out and build a business around the "Web Writable Files API" tomorrow, but if it gets standardized, and if it gets implemented in a few major browser engines (which is a requirement for standardization in this context), then yeah go ahead and start to rely on it more. But this has very little to do with these new proposed APIs, and more with general software development.
ballenf 8y ago
> And in any real application you will need to interact with plenty of folders users cannot be expected to know, like Appdata. I think a lot of what you'd store in Appdata in a "real" application will remain in browser storage or pulled from the server. A single file or folder with app settings, drafts, etc. should suffice. And even settings are probably better stored server side for user convenience so they can easily switch devices.
- devwastaken 8y ago
  1. Completely unnecessary given native access 2. Native will be much faster 3. Native will allow for features from the kernel that browsers do not impliment. 4. You cannot plan for how people will use such a wide feature as the Filesystem. Saying 'X and Y should fit' requires a significant amount of honest research and testing, with a very good reason as to why the change is necessary.

Klathmon 8y ago

By that line of thinking relying on OS APIs will be trouble as Microsoft or Apple could remove features at any time.

devwastaken 8y ago
If they are shiny new features, absolutely. Browser features, especially from Google, are notorious in being experimental and removed when they want to be. Browsers in general will remove things unless their internal teams find use for them. Browsers do not want to support more features than they have to, as can be seen by subscribing and listening in on the mailing lists for Firefox. However your equivalence in this case is a completely false one, because file system API's are not going to just be 'removed' as that would break literally every application that uses standard fopen. over 20 years of standard is a pretty good boat to stand on unless there's signals that say otherwise.
- Klathmon 8y ago
  Well sure you shouldn't rely on anything new for core aspects of your application without a plan for what happens if they go away. Especially when the API in question isn't even implemented yet... But that's not how I understood your comment above, which was to not rely on any browser features for native access, which IMO isn't good advice. Sure, you shouldn't go out and build a business around the "Web Writable Files API" tomorrow, but if it gets standardized, and if it gets implemented in a few major browser engines (which is a requirement for standardization in this context), then yeah go ahead and start to rely on it more. But this has very little to do with these new proposed APIs, and more with general software development.

ballenf 8y ago

> And in any real application you will need to interact with plenty of folders users cannot be expected to know, like Appdata. I think a lot of what you'd store in Appdata in a "real" application will remain in browser storage or pulled from the server. A single file or folder with app settings, drafts, etc. should suffice. And even settings are probably better stored server side for user convenience so they can easily switch devices.

devwastaken 8y ago
1. Completely unnecessary given native access 2. Native will be much faster 3. Native will allow for features from the kernel that browsers do not impliment. 4. You cannot plan for how people will use such a wide feature as the Filesystem. Saying 'X and Y should fit' requires a significant amount of honest research and testing, with a very good reason as to why the change is necessary.