I want to praise everyone who worked on Opal

ruby-talk
1

You are fantastic, and need to be validated.

1 Like
2

I fully concur! I thank the Opal folks as well for providing such an
awesome option to the Ruby community! I'm surprised it's not the
default in Rails already (and hasn't been for years). I think the
Basecamp folks are missing out big time for not including Opal into
Rails as the default front-end language! It's like a bunch of rich
lords riding the fanciest horses and thinking that's the good life
just because they don't know there are cars in existence. Seriously,
using Opal is like space-age light-years-ahead technology compared to
everything else on the web front-end (I sincerely feel sad for people
who use React, Angular, or any [insert popular frontend technology
XYZ])!

···

On Mon, Oct 18, 2021 at 3:00 PM Gregory Cohen <gregorycohen2@gmail.com> wrote:

You are fantastic, and need to be validated.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

--
Andy Maleh

LinkedIn: Andy Maleh - Lexop | LinkedIn
Blog: http://andymaleh.blogspot.com
GitHub: http://www.github.com/AndyObtiva
Phone: 438-835-5602

3

On behalf of the Opal development team I want to thank you for the kind words :smiley:

In my opinion there are 3 reasons why Rails is no more the web framework to go as it was in its heyday.

- First is of course speed and complexity. This is the reason I myself pick light webserver libraries, like Roda or Sinatra and never actually learned how Rails proper works. I have used ActiveRecord in the past alone, but replaced it in my stack with Sequel for its superior relational algebra abilities.

- Second is the Twitter debacle, as in, "Rails doesn't scale". This references the first point. It may even be true on some level for applications like Twitter like, would it be really viable to use Ruby to write something as performance critical as a kernel or an SQL database? Oh well, that may be a too extreme example, as Twitter is mostly IO bound, but then the issue still stands. In those years Ruby's IO was really subpar to what we have currently due to work of Samuel Williams et al. (I still remember how back then he was struggling to understand why his Fibers entangle, and due to those issues, he actually had to do a real refactor of the Ruby IO himself).

- Third is... as you noted, while Rails innovated with some early ideas like builder API for generating JavaScript, it wasn't enough to do complex UIs and that was the direction where the web was headed. JS became more than just a tool to do basic interactivity. Spearheaded by Google, who promised to not SEO you down, a Single Page Application paradigm was born. And so the Ruby community responded to that with CoffeeScript. And then Node.JS which promised isomorphic code (ie. writing both the frontend and backend in the same language) and a great async IO on a heavily optimized JIT runtime. Later Microsoft added TypeScript and VS Code to the mix (tooling is king!). And suddenly, Rails, or Ruby for that matter, isn't needed anymore, it is even maybe making things more complex, introducing context switches for full-stack developers (every tried to use a Ruby construct in CoffeeScript or vice versa?) and possible performance issues due to a lack of a JIT - at least now the Shopify people are working on improving that issue.

But as I noted, things are getting better nowadays. It may not be enough to win back the mindshare. There are now other big challenges like Machine Learning where Python dominates and heavy resources are needed (and big dangers due to a tangible effect on human psychology). Static typing is a great tooling improvement, but it may finally not be viable for such a dynamic environment that Ruby is.

Right now, the Rails team responded with Stimulus and simplifying the asset system. When they choose the more hardcore way with Opal, the tooling is ready. If not, the integration is already done, requiring just a few lines of code to enable compilation of .rb files in the asset pipeline.

And back to the Opal topic, in a few hours we will be releasing either Opal 1.3.0.rc1 or 1.3.0 final.

···

On 10/19/21 05:27, Andy Maleh wrote:

I fully concur! I thank the Opal folks as well for providing such an
awesome option to the Ruby community! I'm surprised it's not the
default in Rails already (and hasn't been for years). I think the
Basecamp folks are missing out big time for not including Opal into
Rails as the default front-end language! It's like a bunch of rich
lords riding the fanciest horses and thinking that's the good life
just because they don't know there are cars in existence. Seriously,
using Opal is like space-age light-years-ahead technology compared to
everything else on the web front-end (I sincerely feel sad for people
who use React, Angular, or any [insert popular frontend technology
XYZ])!

On Mon, Oct 18, 2021 at 3:00 PM Gregory Cohen <gregorycohen2@gmail.com> wrote:

You are fantastic, and need to be validated.

4

This is a very interesting architecture too, and one which ruby could do as
well as python:

martin

···

On Tue, Oct 19, 2021 at 10:58 PM hmdne <hmdne@airmail.cc> wrote:

On behalf of the Opal development team I want to thank you for the kind
words :smiley:

In my opinion there are 3 reasons why Rails is no more the web framework
to go as it was in its heyday.

- First is of course speed and complexity. This is the reason I myself
pick light webserver libraries, like Roda or Sinatra and never actually
learned how Rails proper works. I have used ActiveRecord in the past
alone, but replaced it in my stack with Sequel for its superior
relational algebra abilities.

- Second is the Twitter debacle, as in, "Rails doesn't scale". This
references the first point. It may even be true on some level for
applications like Twitter like, would it be really viable to use Ruby to
write something as performance critical as a kernel or an SQL database?
Oh well, that may be a too extreme example, as Twitter is mostly IO
bound, but then the issue still stands. In those years Ruby's IO was
really subpar to what we have currently due to work of Samuel Williams
et al. (I still remember how back then he was struggling to understand
why his Fibers entangle, and due to those issues, he actually had to do
a real refactor of the Ruby IO himself).

- Third is... as you noted, while Rails innovated with some early ideas
like builder API for generating JavaScript, it wasn't enough to do
complex UIs and that was the direction where the web was headed. JS
became more than just a tool to do basic interactivity. Spearheaded by
Google, who promised to not SEO you down, a Single Page Application
paradigm was born. And so the Ruby community responded to that with
CoffeeScript. And then Node.JS which promised isomorphic code (ie.
writing both the frontend and backend in the same language) and a great
async IO on a heavily optimized JIT runtime. Later Microsoft added
TypeScript and VS Code to the mix (tooling is king!). And suddenly,
Rails, or Ruby for that matter, isn't needed anymore, it is even maybe
making things more complex, introducing context switches for full-stack
developers (every tried to use a Ruby construct in CoffeeScript or vice
versa?) and possible performance issues due to a lack of a JIT - at
least now the Shopify people are working on improving that issue.

But as I noted, things are getting better nowadays. It may not be enough
to win back the mindshare. There are now other big challenges like
Machine Learning where Python dominates and heavy resources are needed
(and big dangers due to a tangible effect on human psychology). Static
typing is a great tooling improvement, but it may finally not be viable
for such a dynamic environment that Ruby is.

Right now, the Rails team responded with Stimulus and simplifying the
asset system. When they choose the more hardcore way with Opal, the
tooling is ready. If not, the integration is already done, requiring
just a few lines of code to enable compilation of .rb files in the asset
pipeline.

And back to the Opal topic, in a few hours we will be releasing either
Opal 1.3.0.rc1 or 1.3.0 final.

On 10/19/21 05:27, Andy Maleh wrote:
> I fully concur! I thank the Opal folks as well for providing such an
> awesome option to the Ruby community! I'm surprised it's not the
> default in Rails already (and hasn't been for years). I think the
> Basecamp folks are missing out big time for not including Opal into
> Rails as the default front-end language! It's like a bunch of rich
> lords riding the fanciest horses and thinking that's the good life
> just because they don't know there are cars in existence. Seriously,
> using Opal is like space-age light-years-ahead technology compared to
> everything else on the web front-end (I sincerely feel sad for people
> who use React, Angular, or any [insert popular frontend technology
> XYZ])!
>
> On Mon, Oct 18, 2021 at 3:00 PM Gregory Cohen <gregorycohen2@gmail.com> > wrote:
>> You are fantastic, and need to be validated.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;