
Why We're Ditching Ruby on Rails for JavaScript and Node.js - sandrobfc
https://www.imaginarycloud.com/blog/ditching-ruby-on-rails-for-javascript-and-nodejs/
======
aaronbrethorst
Here's how I interpret the author's points:

1\. Rails isn't cool.

2\. If you spend enough time hunting around, you can find Node libraries that,
collectively, do everything Rails does out of the box.

3\. Node is "cool."

4\. A third party product which has nothing to do with Rails for building
native iOS apps in Ruby is no longer actively maintained.

5\. Write once run anywhere, but this time it'll really work!

~~~
jmcgough
Yeah, it felt like justifying wanting to play with newer, more exiciting tech.
That's fine, I've rewritten Rails apps in Phoenix and had a blast, but be
honest with yourself that that's why you're doing something. Both Rails and
node will solve his problems.

~~~
tfranco
Sort of. How do you justify the fact that the corporate world is not coping
with the technology very well?

~~~
jmcgough
> Despite the great advantages of using Rails in a new project, there was an
> area where Ruby was not able to penetrate, and not even Rails was a good
> ambassador. I'm talking about the corporate world. There are of course some
> exceptions, and one can always point some successful corporate use cases
> where Ruby was adopted either for new projects or as a rewrite of existing
> ones in. But we're still to see a mass adoption of the technology by well
> established companies. There are several reasons for this, but this opinion
> was developed based only on gut feeling and I have no clear data to validate
> it. Thus, I'm not going to elaborate on the reasons why Ruby is not
> massively used on the corporate market.

I found this paragraph really hard to grep given how vague it is, but I'm
assuming that he's euphemistically saying that his team/company was either not
interested or not able to learn the language/framework. That would have been a
more interesting article to me if he'd expanded on that.

If the team isn't interested in using some tech, then that's a sufficient
reason itself to not use it. If they don't want to learn _any_ language beyond
what they're comfortable with, I'd be pretty concerned about that kind of
culture, because it'll hurt them in the long-run.

If the issue is actually that they can't deliver rails projects to clients
because corporate people can't write ruby, then that's more important than any
other reason given in the article.

~~~
tfranco
I've been using Rails since 2008, and participated in more than 100 projects
in these last 10 years. Either by coding or managing them. Most of these were
Rails projects. Moving to node is part of planning the tech that we're going
to propose to our clients during the next 10 to 20 years.

I didn't conduct a thorough analysis on the reasons why I've seen big corps
rejecting Rails, so what I'm about to say is based on the the experience of
being through all these projects.

But most Rails projects are connected to the innovation departments and once
they passed through the PoC stage, their IT departments asked for a re-write
on a tech already in their ecosystem. Supporting additional techs raises
complexity and forces them to support another stack.

We were indeed able to push some Rails apps to production on enterprises, but
these were usually apps that performed a specific goal for one of the
departments, and once we went for the big projects within their core, tech
stack was always an issue.

------
amirrajan
Owner/CEO/Steward of RubyMotion here.

1\. Laurent did sell RubyMotion off (to basically retire). He sold it to me.
The guy that built the mobile adaptation of A Dark Room with RubyMotion (which
hit the number one spot on the AppStore _and_ the number two spot on Google
Play).

2\. Since the acquisition, there have been monthly updates to the platform,
and measures to slowly open source RM under a _sustainable_ open source model.

3\. I have since released 4 other apps using RubyMotion. Combined they have
approximately 3.5 million downloads.

4\. RubyMotion is _actually_ native (unlike React Native).

5\. RubyMotion is definitely not cool anymore. It's battle-hardened, "just
works", fast (faster than Swift in fact), and can leverage all the existing
Android and iOS libraries out there (which React not-Native can't do out of
the box).

6\. Email me and I'll hook you up with an Indie license <3.

~~~
tfranco
Amir, thanks for following up. Like I said in the article, I've used
RubyMotion in production in the past. We were one of the early adopters and
launched at least half a dozens apps in it. We payed for all our licenses. I
love the product and this was money very well spent. It allowed us to use the
same language (Ruby) in a larger portion of the projects. This was
particularly important when some of our clients were small startups with an
existing Rails app, and it was important for them to keep the same language
for the mobile app.

I just think the support for Android should have happened a lot sooner. But of
course this is easier said than done.

Moving forward to React Native is part of the same approach. It's important
for us to use a technology that delivers fast in multiple channels and has a
great chance of still being relevant in the next 10 to 20 years. And for me,
these are the strongest points on Javascript.

And you're correct, React Native is not truly native, but it does the job
pretty well without major impacts on usability. RubyMotion is truly native and
very well designed IMHO.

Best of luck for the future.

~~~
amirrajan
I totally understand the need for Android support back then (and to your point
should have happened sooner).

With regards to relevancy, RubyMotion is built on top of LLVM. With regards to
Ruby the language itself, it's been around for decades and won't be going
anywhere (granted the same can be said for JavaScript).

I'm waiting to see how web assembly will shake things up.

Best of luck to you man (I genuinely mean that). And if you ever decide to
come back to RM, I'll be here to help :-)

~~~
tfranco
Thanks. Same here. I truly respect the work that has been done on RubyMotion.
Like I said in my post, brilliant people there.

------
niftich
Here's how I interpret the author's points:

1\. Rails was a breath of fresh air over the explicit-rather-than-implicit web
frameworks of the time, but while making a splash in the startup world, it
didn't seem to be embraced in legacy bigcorp settings.

2\. JS is an ecosystem that is mandatory on the frontend and has become viable
(and actually novel) on the backend, and was eventually able to make inroads
in bigcorp settings unlike Ruby. This ubiquity and agreeableness, combined
with its rich array of libraries and active community, makes it compelling. As
the Ruby community matured, the hype around it has died down, leading to less
buzz but also less prominent innovation.

3\. React Native is the killer SDK for making one codebase work on every
relevant (mobile) platform. (Presumably, if the author were concerned with
lives-on-desktop applications too, Electron would be mentioned as well.)

4\. The core JS language is actually being worked on now and isn't nearly as
quasi-abandonware or as horrendous as it once used to be. (Some credit paid to
browser-makers is missing, as every browser-maker has done their part in both
trying to move the ecosystem forward in divergent ways, and then much later
coming together to harmonize their implementations and resolve to work in a
more coordinated way. This 10-year evolution ultimately made duct tape shims
like jQuery unnecessary, which paved the way for more holistic frameworks like
Ember, Knockout, Angular, and React to set a different architectural model for
JS code, landing the community where it is today.)

~~~
tfranco
Thanks for summing it up.

I avoided desktop because the last time I don't develop for desktop since
2008.

But I take a look at some options for Ruby near that time, and I don't think
the ecosystem is much different now. There were a couple of options but very
incomplete.

Regarding the JavaScript ecosystem, yes. Electron is a perfect killer.

I see the JavaScript ecosystem at the same level that Java was in 2006. If you
pick it, you can virtually deliver to any channel.

------
karmakaze
I had my doubts but read the post to see where I could be enlightened. Two
points sums it up for me:

    
    
      1. Phoenix+Elixir [a modern Rails successor]
      2. [satisfy] both corporates and startups
    

I don't know who needs point 2. Perhaps consulting or a dev who only wants to
learn a single stack? Not me.

I've used Rails at a scale where it hurts. Phoenix+Elixir is great if a little
learning curve is okay. Spring+Java is bloated for many use cases so I have
found and used microframeworks such as Javalin+Kotlin+JDBI which is far
superior to Node on the back-end. For even smaller projects Go is a fine
choice if you don't mind the simplicity which is simultaneously it's strong
and weak point.

~~~
mercer
I completely agree. I'd stick with Rails or opt for Elixir, Clojure, or maybe
Go instead. I'm balls-deep in the Node.js ecosystem and the only reason I
would choose it over Rails or the others is because of React + TypeScript.
React is by far my favorite 'templating language' and TypeScript makes JS
pretty decent.

Basically, if I can get away with it I'd go for Phoenix+Elixir, followed by
Clojure/ClojureScript. If I can't, I'd go for Rails. If for whatever reason
that isn't an option, C# or Java. Node inhabits this weird in-between world
that doesn't offer quite enough of anything, and has some serious drawbacks.

------
ksec
> Corporate world is not coping with Ruby Rails very well.

Now I know DHH will mention Github and Shopify as examples. But I believe both
tends towards "startup" and aren't very cooperate. So I will give two
_Cooperate_ " examples,

Bloomberg News - I really wish they share more about the Rails Stack.

Apple Music - Not sure that is changed, but their first version of Apple Music
I believe was on Ruby Rails.

The main reason, or the main point the author was _trying_ to get across,(
some interrupted as not being _Cool_ ) I think are Ruby, and Rails, as one or
as separate subject, lacks the direction, and more importantly the momentum.
It is definitely not dead, far from it, but it is not growing either. And I
guess the author simply bet on node.js is more like Javascript will continue
to grow and survive for the next 10 years.

Python and Go had Google, PHP had Facebook, Java had Oracle, .Net had
Microsoft, Ruby and Rails manage to come this far without any major backing,
all just open source and works from communities. And the communities should be
proud of this.

P.S - I still believe TruffleRuby will make Rails Great again.

------
natecavanaugh
While I agree with the general sentiment only because I could never really get
into Ruby beyond basic loops, and am beyond comfortable with JS, but it's hard
to take this JS evangelism seriously when their site doesn't even scroll right
on mobile. That pattern of behavior is often indicative that the engineers
care more about their concerns than their users, and in that case, why should
we care? If you're not using the tech to solve your users problems, but just
using it to hammer your perceived nails, the choice of tech is unimportant,
IMHO. I'm probably nitpicking things, but if you're going to proselytize one
path, show the best usage of it, not show off the worst usages of it in the
presentation of it's benefits.

------
galaxyLogic
You can do it both in Node.is and Rails. But the cool-factor matters because
cool means momentum.

And you have to make the choice of which platform you will be building your
company's expertise on. If it is yesteryear's tech that's not good in the long
run.

No need to migrate your existing systems but for new development the platform
with momentum behind it (= cool-factor) is often better businesswise.

~~~
sandrobfc
It's somewhat similar to what happens in design. Trends come and go and anyone
who is seeking a new design at any given time will want what's mainstream at
that time. It's not exactly the same that's happening with Rails and JS, as
here the difference also concerns the quality of the end product, but it
follows the same logic.

------
drum
It seems like the core of the argument is Javascript has wider adoption than
Ruby, in enterprise and startups.

I was expecting a more technical comparisons to Rails and Node. The point made
about Ruby not being adopted by well established companies seems half true
considering adoption of Rails - AirBnB, Twitter, Coinbase, Github, etc

~~~
tfranco
I avoided the tech part because, to be honest, I don't think it is relevant
now. There is many information about that on the web. And from the technology
standpoint both are fit for purpose if you're going to develop a web app.

The central point for me is exactly the adoption on the startup and enterprise
world.

------
pcarolan
Good idea. This approach should definitely drive recurring consultancy
revenue!

~~~
sandrobfc
The main point behind it is assuring that the best frameworks are being used.
It's both relevant for both sides of any project.

~~~
pcarolan
I would like to read that article which talks about feature parity and
support. This felt more like a hit piece. I didn't see a lot of evidence of
'best' other than broad generalizations. Would love to hear your followup in a
year. I truly hope node.js can become as mature a choice as Rails, but even
Ryan Dahl doesn't seem to be convinced that will happen.

~~~
tfranco
We're on the verge of baselining a reference architecture in JavaScript for
all our projects. We did the research with parity of features that already
exist in Rails (Rails Admin, Devise, Sidekiq, etc).

You might not need a year to, at least, get my thoughts on that.

~~~
kwood
Do you mind sharing what back office solution you guys found?

Did somewhat the same kind of research for our projects, but unfortunately
didn't find anything decent that could really compete with ActiveAdmin/Rails
Admin/Trestle in terms of features and maintenance…

~~~
tfranco
Here: [https://www.imaginarycloud.com/blog/node-js-admin-panels-
str...](https://www.imaginarycloud.com/blog/node-js-admin-panels-strapi-and-
express-admin-reviewed/)

~~~
kwood
Ah, didn't realise there is a blog article about it. Thanks!

------
e67f70028a46fba
the willingness to be uncool may become a powerful competitive advantage

~~~
gacba
We said that as Java developers back in 2004. I'd say we got mixed results on
that.

~~~
tfranco
And that as C++ developers before that.

