New subject: [ruby-talk:444121] Re: Let Ruby Have The Same Front-End Capabilities as JavaScript

2 Feb 2023

Thanks for your informative post, Andy! I will expand on this a little 
bit more (I'm an Opal developer):

On 2/2/23 22:16, Andy Maleh via ruby-talk wrote:
> Yes. I've already experimented with that exact idea successfully on 
> top of Ruby on Rails in this project:
> https://github.com/AndyObtiva/glimmer-dsl-opal
>
> 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.
Exactly - Opal compiles Ruby code to JavaScript. One website I develop 
is 458kiB minified, 103kiB compressed (uses opal-browser, but not 
opal-parser - ie. it doesn't bundle a compiler itself, though it could). 
We are further working at reducing the footprint. Keep in mind - though 
- that Opal is an alternative Ruby implementation, one that is unlikely 
to be 100% compatible with MRI at any point.
> - 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.
Not necessarily - Ruby code is served verbatim. Ruby - the MRI - is 
compiled to WASM. There are some Ruby bundles available, the smallest 
one is 10MiB (3MiB compressed).
>
> Check out this try-ruby playground that lets you try both options 
> (Opal & WASM):
> https://try.ruby-lang.org/playground/
>
> 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.

The biggest framework is Hyperstack (having all the things you 
described, integrating React, Rails, Opal, ActiveRecord):

https://hyperstack.org/

It does exactly that. But it is unlikely to be merged with Rails.

>
> 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:
> https://andymaleh.blogspot.com/2022/01/using-opal-ruby-with-rails-7.html
This is great, but as of now it uses a Sprockets pipeline. We are 
currently working on Opal 2.0 release which will add proper and 
idiomatic support for jsbundling-rails, but even earlier we will submit 
it upstream, so perhaps starting a Rails + Opal application will be much 
much easier. If it gets merged, that'd be a good start. There's not much 
wrong with Sprockets in particular (well, there kind of is, but let's 
not expand on it for now :D), but what I describe is future proofing in 
general. The website you write today will be easy to migrate to the new 
stack.
>
> 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.

The problem with Opal in 2014 was that at the time it was actually too 
heavy for the contemporary web. But not focusing on that has in my 
opinion costed us a lot of developers who migrated to Node.js.

It may change one day and even Ruby WASM will be small enough. It is 
already small for certain usecases like creating games.

Opal 2.0 will introduce a common JS API, so you will be able to write 
libraries and websites that will work on both Opal and Ruby WASM.

>
> 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.
Yes. Once you learn what isomorphism is about, you will love it forever.
>
> 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.
Great to hear that! Opal itself is low level and can be used with any JS 
engine and any Ruby backend (or JS backend, or none, even). All you need 
is that your backend supports Sprockets or Tilt (or you can spin up 
building Opal applications yourself if it doesn't have this). Opal 
certainly is production ready, but there's still a lot of room for 
improvement.
>
> Andy Maleh
>
> On Thu, Feb 2, 2023 at 3:13 PM lizhongyou2013--- via ruby-talk 
> <ruby-talk@ml.ruby-lang.org> wrote:
>
>     Just an idea: Can we use the latest wasm technology to make ruby
>     code almost completely replace JavaScript (only a few calls like
>     Document.getElementById remain, of course they will also be
>     wrapped in ruby). We can even replace html and css, as long as a
>     part of the code runs before going online, and html and css are
>     generated. In this way, we have both the front end and the back
>     end just like node. Although this is just a guess, if it is
>     successfully implemented, we can get rid of the inelegant
>     JavaScript, and it is also an impact on the market, bringing Ruby
>     to more people. Disclaimer again: the above is just my immature
>     conjecture, if there are any omissions, please accept it.
>

[ruby-talk:444120] Let Ruby Have The Same Front-End Capabilities as JavaScript

lizhongyou2013＠126.com

Andy Nutter-Upham

Fellipe Fingoli

Jeremy Wood

Andy Maleh

Andy Maleh

hmdne

tags

participants (6)