Mojo IPC instead of Proto? about deno HOT 5 CLOSED

Interesting - I didn't know about Mojo.
I won't do this (now) because

• the project is very bug and non-functional and the serialization layer isn't part of that bugginess
• the reasons they list to use Mojo instead of protobufs is to "support transfer of native object handles (e.g. file descriptors) across process boundaries." This is not a feature deno would need - the IPC is just for communication in the same process between V8 and Go. Even if they were different processes, V8 is supposed to be a complete sandbox in Deno and not make syscalls itself. So there's would be no need to send it (functional) file descriptors.
• Deno is trying to be minimal and thus I'm afraid of diving headfirst into Chrome infrastructure - because it can get interdependent and large quickly.

but thanks for the links - it's good to know about.

from deno.

@ry thanks for looking into it! I think the benefits from this project using Mojo would be around the web compatibility goals. Offering web APIs like Bluetooth, NFC, WebAudio, fetch(), etc., might be easier if you could just use the Chromium implementations. Maybe worth thinking about again in the future.

from deno.

Mojo is also used by Flutter (or at least was used extensively back when it was called Sky, but I wouæd assume that didn't change)

from deno.

https://chromium.googlesource.com/chromium/src/+/master/mojo/README.md

from deno.

Good list of things being modulized inside blink via Mojo:

https://chromium.googlesource.com/chromium/blink/+/master/Source/modules/

from deno.