Yes. I've already experimented with that exact idea successfully on top of Ruby on Rails in this project:
That said, you have two options:
- Opal Ruby (
https://opalrb.com/): compiles Ruby to JavaScript, thus resulting in a small footprint (just kilobytes) by only including what is needed of Ruby for a specific app's code. It supports Ruby 3.2 & Ruby wrappers for JavaScript APIs like the DOM.
- WASM Ruby (
https://github.com/ruby/ruby.wasm): compiles Ruby to Wasm, thus resulting in a heavy footprint (megabytes not kilobytes last I heard). It supports Ruby 3.2 & Ruby wrappers for JavaScript APIs like the DOM.
Check out this try-ruby playground that lets you try both options (Opal & WASM):
My experiment (mentioned above) was done in Opal Ruby as it is the lighter-weight solution.
What would push this idea forward though is to contribute Ruby frontend support to Rails as a very simple configuration option to enable it out of the box effortlessly, or better yet, make it a default. From that point forward, Ruby developers could become accustomed to writing Ruby code on both the frontend and backend (including sharing of models with non-sensitive data), thus improving productivity and maintainbility immensely.
Whoever makes the effort to integrate frontend Ruby into Rails as a basic option would greatly help the Ruby community thrive through simpler more maintainable code on the frontend in addition to the backend.
By the way, I've already documented how to get started with Opal Ruby and Rails 7 with this blog post:
If anyone wants to collaborate on making the use of Ruby in the frontend even simpler to activate from a Rails app (e.g. by including commented gem lines and post install instructions to help Rubyists discover frontend Ruby options), I'd be happy to contribute some of my time for this.
Ruby WASM requires megabytes for the initial load of the site as far as I know, so it can be put on hold for a little while for now, and tackled a bit later when it's become more mature.
Ruby WASM might need to be improved first to figure out what parts of Ruby are used by application code so that it produces a much smaller downloadable during compilation instead of precompiling everything.
To be frank, this problem (Ruby in the frontend) should have been fully solved back in 2014 when Opal Ruby was still new. It should have become a default standard in the Rails framework back then. That would have helped Ruby leapfrog all the JS technologies that came out since then, rendering them all useless.
Businesses could profit greatly from the productivity benefits of having a generally unified codebase between the frontend and backend just like how that was always the case in the 90's with network-enabled desktop applications.
In any case, with Matz (creator of Ruby) getting excited about Ruby in the browser and embracing the idea of replacing all JavaScript frontend code with Ruby, as mentioned by him during RubyConf 2022's keynote speech (which I attended and presented at), the Ruby community is now more than ready for having Ruby in the browser be a common standard in web application frameworks, whether it's Rails, Sinatra, Hanami, or Roda.
Andy Maleh