Re:V8 is Faster and Safer than
by jauntywundrkind on Monday January 15, 2024 @01:00PM
(#39003911)
Tons of excellent stuff here. Amazing.
One thing I'm particularly thrilled about is wasm multi-memory. On first seeing wasm I assumed it was the intent, but for a while it seemed like single memory was going to be the only path forward.
But in the vision of wasm being a lightweight private secure sandbox, being able to give a module more than one bit of memory seems essential. If I have a web handler, I probably need to map in some kind of request object and probably have some other application context that would also be good to map in. Re-crafting a new memory, copying in pieces, seems unideal! Maybe passing these in via function call works in this case, but being able to reference multiple memories of stuff feels like such a powerful option too.
This freedom to combine a bunch of different memories is so so so good to see.
JSPI gets honorable mention, for working to lower impedance of wasm<->js. So many new web apis were being designed with blocking sync interfaces, to make emscripten folks happy, and this was such a necessary proclamation that the runtime would help make introducing that kind of jank unnecessary!
Re:V8 is Faster and Safer than
by iTokio on Monday January 15, 2024 @01:25PM
(#39004195)
That multi tier compiler architecture is a marvel of engineering but I wonder if the added complexity and surface for bugs and security issues has been seriously considered?
Re:V8 is Faster and Safer than
by spankalee on Monday January 15, 2024 @04:05PM
(#39006098)
It's not actually V8, but mentioned in the post: the fast path HTML parser is great for client-side rendering with <template> elements.
<template>s content is often created with .innerHTML and because the contents are inert they're always on the fast path as parsing doesn't have to create any DOM associations.
One thing I'm particularly thrilled about is wasm multi-memory. On first seeing wasm I assumed it was the intent, but for a while it seemed like single memory was going to be the only path forward.
But in the vision of wasm being a lightweight private secure sandbox, being able to give a module more than one bit of memory seems essential. If I have a web handler, I probably need to map in some kind of request object and probably have some other application context that would also be good to map in. Re-crafting a new memory, copying in pieces, seems unideal! Maybe passing these in via function call works in this case, but being able to reference multiple memories of stuff feels like such a powerful option too.
This freedom to combine a bunch of different memories is so so so good to see.
JSPI gets honorable mention, for working to lower impedance of wasm<->js. So many new web apis were being designed with blocking sync interfaces, to make emscripten folks happy, and this was such a necessary proclamation that the runtime would help make introducing that kind of jank unnecessary!
<template>s content is often created with .innerHTML and because the contents are inert they're always on the fast path as parsing doesn't have to create any DOM associations.