If you want more detail on Prio itself, I'd suggest http://blog.ezyang.com/2017/03/prio-private-robust-and-scala... as a more gentle introduction than the research paper.

I've been thinking about this for years, ever since I first read "A Small Matter of Programming" by Bonnie Nardi: https://mitpress.mit.edu/books/small-matter-programming where she explored the history of end-user programming systems, and concludes that spreadsheet and CAD software are the only examples that have had widespread and undeniable success.

ASMOP was published in 1993 and I think it is still just as relevant today.

Just as it's possible to write a terribly-architected and designed program in any language, I suspect that with the right engineering effort and insight, modern software engineering practices could bring the complexity under control.

We shouldn't expect to just take spreadsheets and stick them into production, just as you wouldn't take a hastily-written prototype written in any programming language and do the same.

ESR users are on a separate channel.

Would it feel less "[sneaked] in" if this were a core feature in Firefox?

- https://my.mixtape.moe/sjlprj.jpg - this is whether data is reported to mozilla servers

- https://my.mixtape.moe/sflqrh.jpg - this is data collected locally

You can see the latter in `about:telemetry`

https://developer.mozilla.org/en-US/Add-ons/WebExtensions

plibither8, would you mind adding instructions to load this into Firefox in your README as well as Chrome? Also please upload to addons.mozilla.org as well as the Chrome Store.

Nice work!

https://support.mozilla.org/en-US/kb/firefox-uses-too-many-c...

If it is still happening after you try those, use https://perf-html.io/ and share a profile.

There's interest in wasm-land about having "non-web embeddings", which wouldn't assume things like JS APIs exist at all.

I think in that sort of world, you could probably find nicer APIs to target than WebGL and WebAudio... however if you don't mind still having a JS interpreted available then it'd probably be easy to build this sort of thing today using Node.

Easier implementation of a browser? You might find it interesting to see what Servo has chosen to implement and what they have not. Some things you'd think would be easily removable (such as document.write) turn out to not be so simple to skip.

One of the most valuable things about the Web is the care taken around backwards compatibility.

I do think it'd be quite interesting if you had a user agent that did the DOM differently (not sure what you have in mind specifically re: "documents didn't automatically gain the same privileges as applications") and focused just on providing a GL canvas and audio APIs.

I think you might find that these APIs aren't quite as nice when it comes to re-implementing things that CSS and DOM make easy, and it'd be hard for such a browser to really compete with existing browsers given the backwards-compat situation on the web (mandating GL would leave some devices behind, and web authors as a whole don't really adapt all that quickly).

In any case I think it might still be useful as a reference implementation / proof-of-concept on how minimal a web user agent can be, if it was just focused on hosting applications.

The browser is indeed quite complex (and not just because of the massive historical baggage), but its job is to give the user control while safely downloading untrusted code and running it locally.

So, if your goal is to just have a simple standalone app I think you could stay largely compatible with APIs available in the browser environment.