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.
Not using wasm, but the opal project is already a ruby-to-javascript
transpiler.
···
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 mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info --
Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org
No body uses Vanilla Js to create front-end apps. We need better frameworks
using wasm or opal.
···
Em qui., 2 de fev. de 2023 às 17:17, Andy Nutter-Upham via ruby-talk < ruby-talk@ml.ruby-lang.org> escreveu:
Not using wasm, but the opal project is already a ruby-to-javascript
transpiler.
GitHub - opal/opal: Ruby ♥︎ JavaScriptOn 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 mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info --
Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org______________________________________________
ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info --
Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org
--
Fellipe Fingoli
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 (GitHub - ruby/ruby.wasm: ruby.wasm is a collection of WebAssembly ports of the CRuby.): 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
···
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 mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info --
Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org
--
Andy Maleh
LinkedIn: Andy Maleh - Senior Developer - Lexop | LinkedIn
<https://www.linkedin.com/in/andymaleh>
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
Twitter: @AndyObtiva <https://twitter.com/AndyObtiva>
Thanks for your informative post, Andy! I will expand on this a little bit more (I'm an Opal developer):
Yes. I've already experimented with that exact idea successfully on top of Ruby on Rails in this project:
GitHub - AndyObtiva/glimmer-dsl-opal: Glimmer DSL for Opal (Pure-Ruby Web GUI and Auto-Webifier of Desktop Apps)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 (GitHub - ruby/ruby.wasm: ruby.wasm is a collection of WebAssembly ports of the CRuby.): 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):
TryRuby playgroundMy 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):
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:
Code Master Blog: Using Opal Ruby with Rails 7
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.
···
On 2/2/23 22:16, Andy Maleh via ruby-talk wrote:
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 mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info -- Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org
I use vanilla js to make web apps.
···
On 2/2/23 15:00, Fellipe Fingoli via ruby-talk wrote:
No body uses Vanilla Js to create front-end apps. We need better frameworks using wasm or opal.
Em qui., 2 de fev. de 2023 às 17:17, Andy Nutter-Upham via ruby-talk > <ruby-talk@ml.ruby-lang.org> escreveu:
Not using wasm, but the opal project is already a
ruby-to-javascript transpiler.
GitHub - opal/opal: Ruby ♥︎ JavaScriptOn 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 mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info --
Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org______________________________________________
ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info --
Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org--
Fellipe Fingoli______________________________________________
ruby-talk mailing list --ruby-talk@ml.ruby-lang.org
To unsubscribe send an email toruby-talk-leave@ml.ruby-lang.org
ruby-talk info --Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org
I just saw this article a few days ago on how to write a simple example of
Ruby in the browser via WASM (WebAssembly):
···
On Thu, Feb 9, 2023 at 2:58 AM Jeremy Wood via ruby-talk < ruby-talk@ml.ruby-lang.org> wrote:
I use vanilla js to make web apps.
On 2/2/23 15:00, Fellipe Fingoli via ruby-talk wrote:No body uses Vanilla Js to create front-end apps. We need better
frameworks using wasm or opal.Em qui., 2 de fev. de 2023 às 17:17, Andy Nutter-Upham via ruby-talk < > ruby-talk@ml.ruby-lang.org> escreveu:
Not using wasm, but the opal project is already a ruby-to-javascript
transpiler.
GitHub - opal/opal: Ruby ♥︎ JavaScriptOn 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 mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info --
Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org______________________________________________
ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info --
Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org--
Fellipe Fingoli______________________________________________
ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info -- Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org______________________________________________
ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info --
Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org
--
Andy Maleh
LinkedIn: Andy Maleh - Senior Developer - Lexop | LinkedIn
<https://www.linkedin.com/in/andymaleh>
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
Twitter: @AndyObtiva <https://twitter.com/AndyObtiva>