How many of these things are fundamental limitations of plugins? (Besides the "can start native programs," of course; though I thought one of the Vim-keybinding-plugins had an optional native component that exposed an HTTP interface to allow that.)
I could imagine an extension that's modal and allows its own plugins to be written in JS and then loaded. This doesn't seem at all to be a fundamental limitation, just "Vimium et al aren't designed this way."
Similarly, couldn't an extension use Web Workers to do the intensive processing tasks without blocking rendering, with the only on-main-JS-thread actions being bridging the Web Workers to the DOM?
I guess extensibility is much easier with CLOS methods than with... however people write extensible programs in JavaScript. Prototype hackery? But one could again port CLOS methods to JS as a library, so that's not a fundamental limitation either, IMO. (Maybe the fundamental limitation is the JIT being able to optimize them? I think a normal method cache on the GF might work, though I'm unfamiliar with how JS engines optimize indirect calls in general.)
> I could imagine an extension that's modal and allows its own plugins to be written in JS and then loaded. This doesn't seem at all to be a fundamental limitation, just "Vimium et al aren't designed this way."
Currently yes. When Chrome eventually mandates Manifest V3 extensions, they will no longer be able to run code not contained in the signed extension package.
I could imagine an extension that's modal and allows its own plugins to be written in JS and then loaded. This doesn't seem at all to be a fundamental limitation, just "Vimium et al aren't designed this way."
Similarly, couldn't an extension use Web Workers to do the intensive processing tasks without blocking rendering, with the only on-main-JS-thread actions being bridging the Web Workers to the DOM?
I guess extensibility is much easier with CLOS methods than with... however people write extensible programs in JavaScript. Prototype hackery? But one could again port CLOS methods to JS as a library, so that's not a fundamental limitation either, IMO. (Maybe the fundamental limitation is the JIT being able to optimize them? I think a normal method cache on the GF might work, though I'm unfamiliar with how JS engines optimize indirect calls in general.)