Imagine something like "base system" with WebAssembly, bare bones HTML engine with canvas support and no CSS. So now you can just download your favourite JS engine, your favourite HTML, CSS engines. But browser does not necessarily need to sheep those. It would allow to lower the bar for entry into browser market. I think that even a single person could implement that kind of base browser.
Of course there're many hard questions. For example downloading an entire JS+HTML+CSS engine with every website is not a good approach, some caching must be done. There should not be version hell with every website asking for a different version of engine. But those questions could be approached as a more general web library issues.
Check out Geminispace https://gemini.circumlunar.space - one of the design requirements of the protocol is that it be simple enough that a single person can implement a browser for it in a weekend.
But convergence on a minimal set of solutions is inevitable. Even though Geminispace could have hundreds of browsers, most people just use one of the most popular ones, like Lagrange.
Your solution wouldn't lead to a vibrant marketplace of competing web engines, everyone would just ship the equivalent of Chromium like they do now and call it a day.
Not sure if I'd trust the wasm runtime. If someone breaks out of that it's game over. QuickJS in a unikernel in something like Firecracker VM would be the most secure approach and still provide good performance and startup time.
Another thing is resource consumption where you likely want to limit cpu- and mem-usage.
I recommend Lambda as an easy way to create ephemeral Firecracker VMs and set overall limits on host + guest. For casual use, the memory and CPU limits available in the library should be enough.
I use it on both client and server. A easy way to get excellent security in the server is to run inside AWS Lambda or similar FaaS that uses strong VM isolation; ideally with a lambda instance per user.
The npm package isn't working in the browser. I get `process is not defined`. There is a commit that fixes that issue, but no npm publish was made after that.
27 comments
[ 2.4 ms ] story [ 68.0 ms ] threadThe performance was quite adequate.
QuickJS JavaScript Engine - https://news.ycombinator.com/item?id=30598026 - March 2022 (67 comments)
A small but complete JavaScript engine - https://news.ycombinator.com/item?id=24867103 - Oct 2020 (146 comments)
QuickJS JavaScript Engine - https://news.ycombinator.com/item?id=20411154 - July 2019 (261 comments)
QuickJS JavaScript Engine - https://news.ycombinator.com/item?id=20404503 - July 2019 (3 comments)
Of course there're many hard questions. For example downloading an entire JS+HTML+CSS engine with every website is not a good approach, some caching must be done. There should not be version hell with every website asking for a different version of engine. But those questions could be approached as a more general web library issues.
https://web.archive.org/web/20150405004057/http://apple2info...
But convergence on a minimal set of solutions is inevitable. Even though Geminispace could have hundreds of browsers, most people just use one of the most popular ones, like Lagrange.
Your solution wouldn't lead to a vibrant marketplace of competing web engines, everyone would just ship the equivalent of Chromium like they do now and call it a day.
If site A can tell based on timing information that you probably visited site B recently, that's a pretty big privacy issue
This has largely killed cross-origin caching on the web, as I understand it
https://github.com/Shopify/javy/tree/main/crates/quickjs-was...
https://github.com/taowen/define-function
This repo in particular is for JavaScript host environments
Another thing is resource consumption where you likely want to limit cpu- and mem-usage.
WASM probably doesn't add much there.