4 ms·

This is a great example of how useful the File System Access API is. On http://co-do.xyz/ http://co-do.xyz/ you can select a directory and let AI get to work i

by mg 8mo ago

This is a great example of how useful the File System Access API is. On http://co-do.xyz/ http://co-do.xyz/ you can select a directory and let AI get to work inside of it without having to worry about side effects. The Fily System Access API is the best thing that happened to the web in years. It makes web apps first class productivity applications.

layer8 8mo ago
> It makes web apps first class productivity applications. They won’t be first-class as long as native UI still has the upper hand.
- cobolexpert 8mo ago
  In which way does native UI have the upper hand, do you think? To me it seems like a lot of users are largely indifferent to this aspect (e.g. so many applications nowadays being Electron/browser based). If browsers keep gaining capabilities then it seems like this gap will get even smaller.
  - TingPing 8mo ago
    I’ve never used a webapp that felt nicer than native software, it’s always very clearly a compromise.
    - simonw 8mo ago
      I can't tell what's a web app and what's native these days. Are you sure you can?
      - deleted 8mo ago
        [deleted]
      - TingPing 8mo ago
        I'd have a very good hit rate, it mostly comes down to knowledge of toolkits. There are native apps that use their own toolkit, mostly written in Rust these days, and they always are worse than traditional toolkits (accessibility, respecting platform settings, visually fitting in, etc). That same issue applies to webapps typically.
      - layer8 8mo ago
        The way keyboard-only usage works, if it is workable at all, is usually a dead giveaway. As is the lack of dialog windows and traditional menus, and often latency.
- whywhywhywhy 8mo ago
  This battle is long won in favor of webtech in every realm but 3d/video editing/audio work/things that do gpu heavy lifting like game engines. Outside those sort of spaces it’s hard to name a popular piece of software still on native that isn’t a wrapped webapp.
  - Sammi 8mo ago
    > video editing cough CapCut cough
  - layer8 8mo ago
    Microsoft Office apps, Java IDEs, text editors in general. Most of the time I spend with software is with non-web-UI applications. To the extent that the battle has been won, the apps it has been won with are nevertheless second-class compared to native-level usability.
    - whywhywhywhy 8mo ago
      > Microsoft Office apps Thought these were web wrappers now if you use the latest > text editors in general Definitely not in general, VSCode and Cursor are both webtech and are extremely popular. Only terminal editors are native and then beyond that you have things like SublimeText, Textmate which are extremely niche now. > Java IDEs Yeah those and XCode I guess, Java IDE is extremely niche compared to webdev.
auggierose 8mo ago
Unfortunately, this feature of the API is not supported (yet?) either by Safari or Firefox.
- mmis1000 8mo ago
  The guarantee of web page never edit file on your disk(only create new ones) does not hold on this api though. I know it's what makes this api useful. But at the same time, there is big risk that user never expected this and results into giant security issue. Firefox and safari are generally very conservative about new api that can enable new type of exploits. At least firefox and safari does implement origin private file system. So, while you can't edit file on user disk directly. You can import the whole project into browser. Finish the edit and export it.
- pjmlp 8mo ago
  Because it is a ChromeOS Platform API, not that it matters with the Chrome market share.
- cxr 8mo ago
  Browsers have had widespread support for processing files via drag-and-drop and the <input> element since HTML5 (< 2015). The last holdout on allowing the filepicker to accept a full directory (and its subdirectories, recursively—rather than 1 or N individual files) was Safari sometime around (before) 2020. The Chrome team's new, experimental APIs are a separate matter. They provide additional capabilities, but many programs can get along just fine without since they don't don't strictly need them in order to work—if they would ever even have end up using them at all. A bunch of the applications in the original post fall into this category. You don't need new or novel APIs to be able to hash a file, for example. It's a developer education problem (see also: hubris).
  - jefftk 8mo ago
    Providing a web app with edit access to a local directory is really needed for this to be usable. Without that you're constantly managing downloaded files and manually replacing things. I do think this is a case where the File System Access API shines.
storystarling 8mo ago
It definitely makes deployment cheaper, but I'm skeptical about relying on the browser for state management in longer chains. I tried this for a publishing tool and ended up migrating back to LangGraph and Celery just to ensure reliability. The infrastructure savings weren't worth the headache of handling edge cases on the client.

by mg 8mo ago

layer8 8mo ago

> It makes web apps first class productivity applications. They won’t be first-class as long as native UI still has the upper hand.

cobolexpert 8mo ago
In which way does native UI have the upper hand, do you think? To me it seems like a lot of users are largely indifferent to this aspect (e.g. so many applications nowadays being Electron/browser based). If browsers keep gaining capabilities then it seems like this gap will get even smaller.
- TingPing 8mo ago
  I’ve never used a webapp that felt nicer than native software, it’s always very clearly a compromise.
  - simonw 8mo ago
    I can't tell what's a web app and what's native these days. Are you sure you can?
    - deleted 8mo ago
      [deleted]
    - TingPing 8mo ago
      I'd have a very good hit rate, it mostly comes down to knowledge of toolkits. There are native apps that use their own toolkit, mostly written in Rust these days, and they always are worse than traditional toolkits (accessibility, respecting platform settings, visually fitting in, etc). That same issue applies to webapps typically.
    - layer8 8mo ago
      The way keyboard-only usage works, if it is workable at all, is usually a dead giveaway. As is the lack of dialog windows and traditional menus, and often latency.
whywhywhywhy 8mo ago
This battle is long won in favor of webtech in every realm but 3d/video editing/audio work/things that do gpu heavy lifting like game engines. Outside those sort of spaces it’s hard to name a popular piece of software still on native that isn’t a wrapped webapp.
- Sammi 8mo ago
  > video editing cough CapCut cough
- layer8 8mo ago
  Microsoft Office apps, Java IDEs, text editors in general. Most of the time I spend with software is with non-web-UI applications. To the extent that the battle has been won, the apps it has been won with are nevertheless second-class compared to native-level usability.
  - whywhywhywhy 8mo ago
    > Microsoft Office apps Thought these were web wrappers now if you use the latest > text editors in general Definitely not in general, VSCode and Cursor are both webtech and are extremely popular. Only terminal editors are native and then beyond that you have things like SublimeText, Textmate which are extremely niche now. > Java IDEs Yeah those and XCode I guess, Java IDE is extremely niche compared to webdev.

auggierose 8mo ago

Unfortunately, this feature of the API is not supported (yet?) either by Safari or Firefox.

mmis1000 8mo ago
The guarantee of web page never edit file on your disk(only create new ones) does not hold on this api though. I know it's what makes this api useful. But at the same time, there is big risk that user never expected this and results into giant security issue. Firefox and safari are generally very conservative about new api that can enable new type of exploits. At least firefox and safari does implement origin private file system. So, while you can't edit file on user disk directly. You can import the whole project into browser. Finish the edit and export it.
pjmlp 8mo ago
Because it is a ChromeOS Platform API, not that it matters with the Chrome market share.
cxr 8mo ago
Browsers have had widespread support for processing files via drag-and-drop and the <input> element since HTML5 (< 2015). The last holdout on allowing the filepicker to accept a full directory (and its subdirectories, recursively—rather than 1 or N individual files) was Safari sometime around (before) 2020. The Chrome team's new, experimental APIs are a separate matter. They provide additional capabilities, but many programs can get along just fine without since they don't don't strictly need them in order to work—if they would ever even have end up using them at all. A bunch of the applications in the original post fall into this category. You don't need new or novel APIs to be able to hash a file, for example. It's a developer education problem (see also: hubris).
- jefftk 8mo ago
  Providing a web app with edit access to a local directory is really needed for this to be usable. Without that you're constantly managing downloaded files and manually replacing things. I do think this is a case where the File System Access API shines.

storystarling 8mo ago

It definitely makes deployment cheaper, but I'm skeptical about relying on the browser for state management in longer chains. I tried this for a publishing tool and ended up migrating back to LangGraph and Celery just to ensure reliability. The infrastructure savings weren't worth the headache of handling edge cases on the client.