JRuby VS sassc-ruby

As someone who has looked at Shoes several times but never dove in, it's confusing how Shoes 4 has been the "preview version" of Shoes for, like, a decade or more. It made me actively avoid getting invested in Shoes 3 (the release promoted on the linked website) because Shoes 4 requires JRuby and I am happy with CRuby (the Ruby interpreter most people think of when they hear "Ruby").

https://github.com/shoes/shoes4/

http://www.rubydoc.info/github/shoes/shoes4

No disrespect to the developers but to me it feels like taking over a GUI toolkit created "to teach programming to everyone" (to quote the Shoes 4 readme) and making it depend upon a super-complicated enterprise-focused Ruby was sort of Missing The Point™ in a huge way.

Heck I couldn't even switch to JRuby if I wanted to because I <3 Ractors and JRuby still lacks CRuby 3.0 feature parity: https://github.com/jruby/jruby/issues/7459

__callee__ now properly returns the name under which a method was called, which will be the new name in the case of aliased methods. #2305, #7702

Issue tracker: https://github.com/jruby/jruby/issues

rdoc has been updated to 6.3.3 to fix all known CVEs. (#7396, #7404)

Altering the visibility of an included module method no longer changes what super method gets called. (#7240, #7343, #7344, #7356)

It looks like the readme is copy pasta from jruby: https://github.com/jruby/jruby

Homepage: https://www.jruby.org/

Chris: Yeah, that's exactly right. So I was working at Sun at the time. I remember the JRuby guys. I saw them speak at one of the Java conferences, and they came to work for Sun. Just listening to them talk about JRuby...and then a lot of it was obviously about Ruby on Rails at the time. And I was like, wow, this was just mind-blowing the way they talked about it.

In fact, I built its GUI twice with two different approaches, one using the up and coming Glimmer DSL for LibUI on CRuby relying on a multi-canvas-grid (LibUI area) approach, and one using the very mature Glimmer DSL for SWT on JRuby by relying on a button-grid approach.

And I don't know if this is the same issue (it seems to be) but the solution suggested there that got a lot of thumbs-ups didn't work for me.

Generated make files now properly set the platform architecture when running on Linux/aarch64 and Apple's M1 family of CPUs. This allows sassc and other non-extension C-based gems to build and install properly. (sass/sassc-ruby#231, #7132, #7133)

This sprockets setup has always worked great, but lately some serious bit-rot has set in. Over the last few years, the Sass Team has deprecated both its original ruby-based version of sass, and more recently, the libsass/sassc library in favor of dart-sass. As of this writing, I could not find any sprockets compatible versions of dart-sass. Further, as time marches on, the sassc gem is beginning to accumulate some pretty nasty bugs and inefficiencies. With no fixes on the horizon, it's time to move on.