Why We're Ditching Ruby on Rails for JavaScript and Node.js | Hacker News Reader

Why We're Ditching Ruby on Rails for JavaScript and Node.js

imaginarycloud.com

18 pointssandrobfc38 comments

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!

Yep - agree.

I write code to build businesses, not to follow code trends. If the business needs Node.js, you betcha. If the business doesn't, why not use something that has worked for 10+ years?

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.

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

> 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.

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.

I'll readily admit that part of the appeal of Phoenix is that it's shiny and exciting. But I'd also argue that it's much easier to defend switching from Rails to Phoenix over switching to Node.

It's not the point of being cool or not. If Java, Rails, etc works for you, please go ahead.

But we work on several projects by helping a lot of people at the same time. And need a solution that fits our and our client's purpose and context.

Rails did that to some extent, but I believe JavaScript will help us navigate a larger context.

To be clear, I have no stake in which tools you use to satisfy your clients' needs. I think it's great that Node and JavaScript work well for you, but you do compare Rails and JS/Node on this 'coolness' axis:

I also think that the [JavaScript] community is going through a "cool" phase, similar to what happened to Rails in the early days...[A]s Rails matured, it lost it's cool factor and the community stabilised.

You need to look under which title that is, and take the context into consideration. That is one of the reasons used to justify why the community is more active that the Rails one.

I tend to skip the "Why I did X" articles. They usually are less of an analysis of the technologies involved and more of a story of the decisions made in a particular project.

I could tell you why I chose to use POE access points in my house instead of plain Ethernet, it wouldn't tell you anything about when you should.

And he was mistaken when he suggested RubyMotion is not being maintained. Everyone is quite chatty on Slack so I encourage anyone interested to drop by there:

http://motioneers.herokuapp.com

A lot of other info is linked from the website, plus community members have been adding examples and other content elsewhere:

http://www.rubymotion.com

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.

When are you going to open source? will RubyMotion ported to Linux?

>When are you going to open source?

- Build, project templates, dynamic bindings generation (BridgeSupport) have all been open sourced.

- The repl is targeted to be open sourced in Q1 2019.

- The parser is targeted to be open sourced in Q2 2019.

- The rest is TBD. But I bought the website domain dragonruby.org :-D

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.

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 :-)

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

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.)

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.

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.

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.

> 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.

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.

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.

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.

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

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.

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

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

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.

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.

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…

Here: https://www.imaginarycloud.com/blog/node-js-admin-panels-str...

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

the willingness to be uncool may become a powerful competitive advantage

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

And that as C++ developers before that.

Reply on news.ycombinator.com