Back in those days there were also the Filesystem API in discussion (and stage0/1 iirc).
From a web app devs perspective there was a huge need for file processing in the client, where the Blob API wasn't enough. The use case was e.g. batch processing or opening/uploading a folder with a bunch of files in them.
Sadly the limitations for web contexts were easily exploited by using dozens of subdomains, so you could DDoS the filesystem of the client with it and break out of the 80/100MB limit for each context in all browsers.
I am very sad to see the html5 manifest gone, because it was a superb way to describe online/offline assets that can/should/must be cached.
The combination of the removal of all those APIs basically pushed native apps again, because web apps are pretty useless as file selectors and all the hacks around input fields (even with WebKit's custom file picker). Even electron started at some point to offer custom APIs for file handling (and database handling) because of it, so I'd argue that the overall offline initiative was a huge disaster.
Now we have 10+ years outdated code in the devtools in browsers which use APIs that are not even available in web contexts anymore, and they are nothing more than a pointless maintenance burden.
I wish there was a smarter way to describe C ABIs inside C/C++ code, but sadly there isn't. The outdated headers and the data types serialization/deserialization from web context to web context is usually what results in use after free bugs in the C code that doesn't expect it. Add the casual heap spraying bugs and you've got a factory for RCEs that are easy to implement.
Servo and its idea of "how to program a browser that interacts with other embedded languages" could have changed so much about this state of program bugs and issues.
C ABIs are not enough anymore, yet they are the only way programs can interact with each other.
And I'd argue it's a huge fail of the software industry, and it has to change if we ever don't want to think about this anymore.
From a web app devs perspective there was a huge need for file processing in the client, where the Blob API wasn't enough. The use case was e.g. batch processing or opening/uploading a folder with a bunch of files in them.
Sadly the limitations for web contexts were easily exploited by using dozens of subdomains, so you could DDoS the filesystem of the client with it and break out of the 80/100MB limit for each context in all browsers.
I am very sad to see the html5 manifest gone, because it was a superb way to describe online/offline assets that can/should/must be cached.
The combination of the removal of all those APIs basically pushed native apps again, because web apps are pretty useless as file selectors and all the hacks around input fields (even with WebKit's custom file picker). Even electron started at some point to offer custom APIs for file handling (and database handling) because of it, so I'd argue that the overall offline initiative was a huge disaster.
Now we have 10+ years outdated code in the devtools in browsers which use APIs that are not even available in web contexts anymore, and they are nothing more than a pointless maintenance burden.
I wish there was a smarter way to describe C ABIs inside C/C++ code, but sadly there isn't. The outdated headers and the data types serialization/deserialization from web context to web context is usually what results in use after free bugs in the C code that doesn't expect it. Add the casual heap spraying bugs and you've got a factory for RCEs that are easy to implement.
Servo and its idea of "how to program a browser that interacts with other embedded languages" could have changed so much about this state of program bugs and issues.
C ABIs are not enough anymore, yet they are the only way programs can interact with each other.
And I'd argue it's a huge fail of the software industry, and it has to change if we ever don't want to think about this anymore.