4 ms·

As far as I understand JS code is being run natively in the browser. Node has been hooked to the native engine, so V8 is not involved. At LeaningTech we have s

As far as I understand JS code is being run natively in the browser. Node has been hooked to the native engine, so V8 is not involved. At LeaningTech we have since several months been able to run nodejs, but also python and ruby using our Wasm based x86 VM (CheerpX), the demo is available here: https://repl.leaningtech.com/?nodejs https://repl.leaningtech.com/?nodejs With our solution the full Linux x86 binary of nodejs is running including the whole of V8 and its JIT engine. Of course fully client side.

lsb 5y ago
> We are working on CheerpX, but it’s not yet available generally. If you are curious and want to know more, stay tuned, or get in touch! How close is CheerpX to getting (for example) an app that uses a PyTorch model running in the browser? :)
- apignotti 5y ago
  Not an expert on PyTorch in particular, the python + native (if any) components would work right now. If GPU acceleration is required some way to bridge into WebGL or (much better) WebGPU would need to be engineered, certainly doable but not existing right now.
  - lsb 5y ago
    Except for figuring out Pytorch's blas, the rest should be pretty straightforward to use CPU-only, I'd love to use that to (even pay to) compile some side projects to wasm apps in the browser :)
ampeter 5y ago
> As far as I understand JS code is being run natively in the browser. Node has been hooked to the native engine, so V8 is not involved. What is the "native engine" if not v8?
zamadatix 5y ago
It looks like the difference is you went for full x86 system call level emulation to handle existing binaries whereas stackblitz decided to build a container for things like Node compiled directly to WASM with no static assumptions of a base system. The latter approach with 1 less level of indirection should be much more efficient, as is evident by startup times of the 2 demos. Not to mention the ability to hook into things above the syscall level.

lsb 5y ago

> We are working on CheerpX, but it’s not yet available generally. If you are curious and want to know more, stay tuned, or get in touch! How close is CheerpX to getting (for example) an app that uses a PyTorch model running in the browser? :)

apignotti 5y ago
Not an expert on PyTorch in particular, the python + native (if any) components would work right now. If GPU acceleration is required some way to bridge into WebGL or (much better) WebGPU would need to be engineered, certainly doable but not existing right now.
- lsb 5y ago
  Except for figuring out Pytorch's blas, the rest should be pretty straightforward to use CPU-only, I'd love to use that to (even pay to) compile some side projects to wasm apps in the browser :)

ampeter 5y ago

> As far as I understand JS code is being run natively in the browser. Node has been hooked to the native engine, so V8 is not involved. What is the "native engine" if not v8?

zamadatix 5y ago

It looks like the difference is you went for full x86 system call level emulation to handle existing binaries whereas stackblitz decided to build a container for things like Node compiled directly to WASM with no static assumptions of a base system. The latter approach with 1 less level of indirection should be much more efficient, as is evident by startup times of the 2 demos. Not to mention the ability to hook into things above the syscall level.