Just a thought experiment...<p>Would this allow for full stack ruby apps?<p>Writing a client side router and controllers in Ruby on Rails compiled to web assembly?<p>If you could just toggle in production.rb if you want your routing to be client side or server side and the framework could transparently manage that for you.
Why would someone go through so much trouble to use a language that will run much slower than JITed javascript?<p>I think most people miss that right now webasm is good for run speed, size, and loading speed, but is not geared nearly as much towards using any language in a web page, since IO needs to be exposed to javascript.
Curious how fast/stable Ruby->wasm is on the frontend. I had a horrible experience with scaling a large rails app, but the usage patterns for server vs client are very different.<p>I haven't played with wasm yet and am waiting a bit for a "best language" consensus to emerge. If I was to bet on a winner, my money wouldn't be on Ruby, but I've been wrong many times.
Mruby has captured my attention for quite a while now, especially the ability to compile and run its own bytecode as a module. The memory handling seems good and want to try running it with Cairo GL for iOS sometime for some immediate mode rendering.
How would you use features like event listeners and other web APIs from client-side mruby? I guess this is a question about WebAssebly in general: does each language that gets ported over have to re-implement those APIs?
Rubies magic evaporated when I realized that its logic is unintuitive / broken:<p>```
puts true and not true
>>> true
x = true and false
>>> true
if 0; puts 'true';end
```<p>breaking backwards compatibility with every rails upgrade didn't help.<p>Similar bad behaviour in kotlin