Opal VS truffleruby

It's been a long time dream for me since about 2013 when I started getting deep into Ruby and Rails, to be able to write Ruby code for the frontend instead of JavaScript. I was a lover and adopter of CoffeeScript (which had it's flaws and imperfections), but that mostly got killed by ES6. I wrote some PoCs with Opal[1] that felt pretty good to write, but the overhead was rough (this was many years ago so things might be different now) and I never really felt like I didn't have to know about or care about the underlying javascript. I tend to discard leaky abstractions as I feel they often add more complexity than they were meant to cover in the first place.

Has anybody used this or Opal or anything else? What is the state of "write your frontend in Ruby" nowadays?

[1]: https://github.com/opal/opal

Every time I see a respectable project use a Code of Conduct I remind myself that, unfortunately, Caroline Ada won[1]

[1] https://github.com/opal/opal/issues/941

But we shouldn't overstate the difference: the JS and Ruby object models are actually similar in how dynamic both of them are. This makes Ruby-to-JS compilers like Opal easier to implement, according to an Opal maintainer.

This is an interview with the author of Opal, here's the project:

https://github.com/opal/opal

Not the OP, but from what I remember they would seek out every possible opportunity in every single possible open source community they could find and propose the CoC that they wrote. 0 contributions to the projects, with the exception of demanding that people implement incredibly verbose CoC's in their projects under the guise of "protecting the minorities contributing to the projects".

Most infamous instance is probably this one, in the Opal repo: https://github.com/opal/opal/issues/941

As well as this thread in the Ruby issue tracker that devolves into pure chaos with Ada refusing to actually participate in any of the valid points others bring up: https://bugs.ruby-lang.org/issues/12004

And I'm sure there's many other instances if you look around a bit.

My experience with ruby for front end web dev is via https://opalrb.com/

Here's an example of the creator of the most adopted CoC (the Contributor Covenant) trying to get an open source contributor removed from a project due to his political opinions expressed on Twitter which she didn't like and found offensive.

So ruby has a JS transpiler - opal - https://opalrb.com/

I tried using it a little bit but the reality is if you need JS to make your app more interactable it's really worth it to just learn some JS. As soon as you need something complex the extra layer of abstraction just gets in the way and becomes more of a headache, and if you don't need anything complex then you don't need JS in the first place.

I stumbled upon this thing from years ago. I did some more digging to see what other communities thought about it. Turns out that a lot of people are really against Coraline's side.

I think it would be worth mentioning GraalVM and https://github.com/oracle/truffleruby in competitors section.

GitHub page has some info: https://github.com/oracle/truffleruby#current-status

My question is, how viable is TruffleRuby vs JRuby?

I wonder why GraalVM is not more often used for these speed critical cases: https://www.graalvm.org/python/

Is the problem the Oracle involvement? (Same for ruby https://www.graalvm.org/ruby/)

Looks like it’s still a WIP

https://github.com/oracle/truffleruby/commits?author=eregon

this comes at the cost of boxing ints inside Integer, though.

So, if you ignore for a moment primitives types, whenever you have generics, everything boils down to a single method accepting Objects and returning Objects. What the JVM does is to do runtime profiling of what actually you are passing to the generic method, and generate optimized routines for the "best case". In theory this is the best of the two worlds, because like in general you will have a single implementation of the method (avoiding duplication of the code), but if you use it in an hot spot you get the optimized code.

In a way, it is quite wasteful, because you throw away a lot of information at compile time, just to get it back (and maybe not all of it) at runtime through profiling, but in practice it works quite well.

A side effect of this is this makes the JVM a wonderful VM for running dynamic languages like Ruby and Python, because that information is _not_ there at compile time. In particular GraalVM/TruffleVM and exposes this functionality to dynamic language implementations, allowing very good performance (according to they website [1][2], Ruby and Python on TruffleVM are about 8x faster than the official implementation, and JS in line with V8)

[1] https://www.graalvm.org/ruby/

I opened a ticket some time ago about performance with Jekyll and liquid templates. At least in that case, yjit was way faster. I'm happy to retest though. Anything that would make my jekyll builds faster would help.

https://github.com/oracle/truffleruby/issues/2363

Here's a benchmark [1] done in Jan'22 against many ruby implementations, truffleRuby [2] seems to be way ahead in most, and at least ahead in all. Why truffleRuby isn't talk about much here?

[1] https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj...

[2] https://github.com/oracle/truffleruby