3 Feb
2023
3 Feb
'23
1:06 a.m.
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. >