4 ms·
Well they could work any way the author wanted, but if it were me, I'd make the plugins WASM. That's how my favorite code formatter (dprint) does it. For that
by veidr 3y ago
Well they could work any way the author wanted, but if it were me, I'd make the plugins WASM.
That's how my favorite code formatter (dprint) does it.
For that matter though, it's how I would implement just about any plugin, these days, except those that need to exchange large info rapidly (e.g. an editor plugin that needs to operate on every key press).
It's dead easy to implement on the app side, and plugin authors can use an increasing number of higher-level languages to build plugins.
- mtsr 3y agoAnd on top of that it’s also easy to mostly guarantee the plug-in can only access the APIs you give it. Which is quite nice for third party code.
- CWIZO 3y agoWould love to learn more if you have any resources available?
- rob74 3y ago...which would have the advantage that plugin authors could also use other languages that compile to WASM.
- crabmusket 3y ago> except those that need to exchange large info rapidly I've seen attempts at zero-copy memory sharing between JS and WASM, but I'm not sure if the same approach would allow different plugins to share memory and communicate via e.g. Cap'n Proto? https://observablehq.com/@kylebarron/zero-copy-apache-arrow-with-webassembly https://observablehq.com/@kylebarron/zero-copy-apache-arrow-...