There is the universal hate for flash because it was used for ads and had shitty security, but anyone I know who actually used AS3 loved it.

At its peak, with flex builder, we also had a full blown UI Editor, where you could just add your own custom elements designed directly with flash ... and then it was all killed because Apple did not dare to open source it, or put serious efforts on their own into improving the technical base of the flash player (that had aquired lots of technical dept).

I never really worked with it, but it seems whenever it comes up here or on Reddit, people who did, miss it. I think the authoring side of Flash is remembered very positively.

For a while RIM/Blackberry was using Adobe Air - on the Playbook and also the built-in app suite in the lead up to the launch of BB10. The latter never saw the light of day though, a late decision was made to replace all of the built-in apps with Qt/Cascades equivalents (if I remember right this was due largely to memory requirements of the Air apps).

Thus it isn't as if the browser plugins story is directly responsible for its demise.

Outside those sort of spaces it’s hard to name a popular piece of software still on native that isn’t a wrapped webapp.

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.

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).

Unix permissions remain a fundamental building block of Android's sandbox. Each app runs as its own unix user.

I see the datestamp on this early test https://fingswotidun.com/tests/messageAPI/ is 2023-03-22 Thinking about the progress since then I'm amazed I got as far as I did. (To get the second window to run its test you need to enter aWorker.postMessage("go") in the console)

The design was using IndexedDB to make a very simple filesystem, and a transmittable API

The source of the worker shows the simplicity of it once set up. https://fingswotidun.com/tests/messageAPI/testWorker.js in total is just

    importScripts("MessageTunnel.js"); // the only dependency of the worker
  
    onmessage = function(e) {
     console.log(`Worker: Message  received from main script`,e.data);
     if (e.data.apiDefinition) {
       installRemoteAPI(e.data.apiDefinition,e.ports[0])    
     }
     if (e.data=="go") {
       go();
       return;
     } 
  }
  
  async function go() {
      const thing = await testAPI.echo("hello world")
      console.log("got a thing back ",thing)
  
      //fs is provided by installRemoteAPI  
      const rootInfo = await fs.stat("/");
      console.log(`stat("/") returned `,rootInfo)
    
      // fs.readDir returns an async iterator that awaits on an iterator on the host side 
      const dir = await fs.readDir("/")
      for await (const f of dir) {
        const stats = await fs.stat("/"+f.name);
        console.log("file  " +f,stats)
      }
    
  }

It wouldn't take too much to have a $PATH analog and a command executor that launched a worker from a file on the system if it found a match existed on the $PATH. Then a LLM would be able to make its own scripts from there.

It might be time to revisit this. Polishing everything up would probably be a piece of cake for Claude.