LLVM is bounded by what its IR can express, and what it can express is constrained by what is portable and what it can prove. There is a reason `ffmpeg`, OpenSSL, OpenBLAS, glibc's string routines, LuaJIT's interpreter, etc. all still leverage hand-written assembly.
As for the editor, even if it isn't necessarily optimal assembly (I have no clue), a reduced feature set and relying on OS APIs instead of frameworks will still probably result in something which feels faster than Electron programs like VSCode.
It's not using the File System Access API, on Firefox it uses for file-picking, and the save just downloads it. It's not synchronizing anything with your filesystem.
Firefox unfortunately does not support the File System Access API. You can try by calling the most fundamental function, the one that asks the user to select a file:
window.showOpenFilePicker()
What Firefox supports is a "File System API" which creates something similar to the other old ways of storing data in a browser, like cookies and indexeddb. You cannot use it to edit normal files on your disk.
This is my main gripe with Firefox. They force their users to either store everything in the cloud or go through the arcane "download" workflow where you have to manually save files.
> Firefox unfortunately does not support the File System Access API.
I would not call it unfortunate. Browsers should not have access to the file system, USB ports, etc. Perhaps in "PWA"s, if the user has a way of giving and withdrawing consent.
Why is that true? Some applications require file system access. People would grant the application the permission to access files like any other resource like camera, mic, location.
Because vulnerabilities, coarse access granularity and lazy or ill-informed users. E.g., you now grant cam access per domain. Changing functionality on that domain doesn't revoke permission, so a simple bait and switch is already possible. Now imagine granting access to your file system to some Microsoft domain and finding out that there was a change of heart and some new script has uploaded your files to OneDrive and deleted them from your disk.
Taking that logic of protecting users from themselves to the extreme, a website should not be able to display text either. Because it can use text to ask the user to open their explorer and delete the files manually.
I think the flow of Chrome where the user has to select a file from disk and then acknowledge a prompt that the site will have access to that file until they close the window is fine. But if Mozilla wanted to protect users from themselves even more, they could make it as strong as they like. For example, by requiring to turn the functionality on in about:config.
Not giving the user the choice at all, if they want a cloud only browser or a browser that lets them work with local files is the wrong way.
Iirc the File System Access API should always originate File objects from an input picker so that the user selects the file to be opened and not give more access to apps than users allows?
You can, however, design rings that can have their comparatively cheap batteries replaced, and be transparent about the expected life span of your $500+ ring that requires a subscription and whose warranty specifically excludes the battery (https://support.ouraring.com/hc/en-us/articles/360025439534-...).
In isolation, yes, that does seem like it would have been the better decision for Claude Code, but it also would have severely diminished the value of their Bun/oven.sh acquisition.
Claude Code isn't the only user of Bun (it's probably not even the only user of it internally at Anthropic), and this way they get to keep the Javascript runtime (and other tooling) that their coding models may one day, if not already, prefer to use when given the opportunity. For those kind of apps, you'll probably also eventually find that--what do you know!--Anthropic also has their own cloud offering (instead of Bun being the one to build one) that specializes in running and managing those applications for you. Even if all they get is a community of developers that choose to use Bun over other options, that gives them power and seats at tables they wouldn't have if they just rewrote Claude Code in Rust.
reply