The browser is an extremely poor medium to deliver applications. It works, but barely, is a huge resource hog, fragile and it breaks way too often due to a lack of backwards compatibility between browser versions of the same manufacturer. I have a small app that I support and it's been fun to get it to work in the browser (instant cross platform support was indeed the driver) but the experience is still sub-par compared to what I could do on a local application.
Unfortunately, I think all these things are externalities - or at least, areas that don't impact revenue enough to get companies to change.
I too wish that software would be efficient, robust and long-lasting. But it seems that most people don't care about this enough (compared to other factors) to force change. (Alternatively, they are locked in to platforms they don't like to use.)
this does not track with my experience, so possibly it's the nature of your app or the way it's coded. frameworks like react are notoriously crap. stick to pure html5/css/js and it can be extremely fast and light.
You could have clicked on my profile to find the app that you're criticizing unfairly. It does not use react, but it uses pure html5,css,js, it is extremely fast and light. And yet, there are things that it can not do simply because it runs in the browser, which is a poor operating system for a hard real time program to run under.
I did not criticize your app. I offered that your blanket statement that "The browser is an extremely poor medium to deliver applications" does not comport with my experience. And it looks like I nailed it, too. It is the nature of your application. Had you said "the browser does not offer a real time API which I need for my application", there would have been nothing to say. This is obviously true. Even native desktop apps provide an inadequate environment for "hard RT". So I suspect that is also not a true requirement, either.
Well, there are apps that you can only do native, not in a browser, we agree on that. But I also think that the browser is actually providing a very compelling standard OS with batteries included for many kinds of applications, and now there is even webGPU. I am currently building a local-first interactive theorem prover with built-in IDE as a PWA, in TypeScript, and you have really cool tools you can use as a foundation for something like this, such as ProseMirror and IndexedDB. Of course the raw prover can also be run from the command line via node. Claude Code is also very useful in this environment. Yes, different browsers are an issue, but so much works on all modern ones.
Back in the 80's and 90's he was pretty well known for noting that if you owe a bank enough money, it is in the bank's interest not to let you fail.
My guess is that it also helps to owe lots of money to lots of banks at the same time. That way when one goes after you, the others will help you out or risk losing their money, too.
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.
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).
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.
> Providing a web app with edit access to a local directory is really needed for this to be usable.
"This" what? sha256sum doesn't need read-write access for even one file to be able to compute a hash, let alone a whole directory. You're ignoring most of my comment, focusing on like 20%, and in so doing, missing (and/or deliberately misframing) 100% of the point.
We're talking about Simon's boosting of https://aifoc.us/the-browser-is-the-sandbox/ which is a prototype of Claude Cowork in the browser. That's what I'm saying needs read-write access.
Yup. That's the link, all right—the one we all read and that I'm citing examples from. Thanks for the reminder, I guess: it has been a whole 8 hours since I first looked at it.
What "we" are talking about here, in this subthread, is the fact that "Browsers have had widespread support for processing files" for a long, long time, and that although "Chrome team's new, experimental APIs [...] provide additional capabilities" which are undoubtedly useful for certain programs, they're overkill and don't offer anything new and/or strictly necessary for many, many programs that don't actually need that sort of access—including "A bunch of the applications in the original post [that] fall into this category. You don't need new or novel APIs to be able to hash a file, for example."
Which is to say, we're talking about POLP/POLA. And the point of my comment was to address the very worthwhile matter of POLA violations. But you seem insistent on shutting that discussion down with chatter that looks like it's an on-topic reply or refutation to something, but in reality doesn't actually meaningfully engage with what you're purporting to respond to, or at best comes come across as confused and not particularly attentive.
There are already and will continue to be plenty of opportunities to discuss the acknowledged upsides of the new APIs for the class of programs for which they are strictly necessary. There's a lot of them in this very comment section. It doesn't have to come at the expense of changing the subject in the middle of a different conversation—accompanied by undertones that you're putting some matter to rest.
Boy, this has been a really fun and rewarding experience.
> I agree we're talking past each other
You're exactly half right.
Let's make this dead simple: does anyone need any of these new APIs to compute the SHA-2 hash for a file? A simple answer will do. Simple, non-evasive, no "look thither" misdirection.
reply