| There are some fundamental issues with running dynamically typed languages on top of wasm. Those issues can be resolved somewhat, but there's quite a bit of work to be done before they can be supported. For basic support these languages need support for GC - some degree of stackwalking if they don't want to use shadow stacks. That support should be coming soon. But you can't get around the fact that you need to ship a runtime to support these languages, so you're not just shipping your code, but the runtime required to run it. But a runtime alone doesn't give you fast execution - you need to jit. And JITs require a lot of deep access into the architecture. You need to be able to generate and inject executable code into the program. You need to be able to patch code at runtime. For security purposes you'd ideally like a separate process that manages the codegen to provide fast w^x support for jitcode. For the forseeable future, any real dynamic language support on the web will require direct runtime support, namely the regular JS engine. Disclaimer: I'm a JS JIT developer at Mozilla, have worked on the IonMonkey optimizing compiler and did a good chunk of the design and implementation of our baseline JIT. I'm excited at the prospect of wasm being a portable, tight runtime that'll eventually be a good cross-platform target for writing dynamic language, but there is quite a bit of infrastructure required within wasm before it can support that. |