5 ms·

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, d

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!

buf 8y ago
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?
jmcgough 8y ago
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 8y ago
  Sort of. How do you justify the fact that the corporate world is not coping with the technology very well?
  - jmcgough 8y ago
    > 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 8y ago
      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.
- mercer 8y ago
  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.
tfranco 8y ago
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.
- aaronbrethorst 8y ago
  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.
  - tfranco 8y ago
    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.
ASalazarMX 8y ago
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.
stephenhuey 8y ago
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 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 http://www.rubymotion.com

buf 8y ago

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?

jmcgough 8y ago

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 8y ago
Sort of. How do you justify the fact that the corporate world is not coping with the technology very well?
- jmcgough 8y ago
  > 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 8y ago
    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.
mercer 8y ago
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.

tfranco 8y ago

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.

aaronbrethorst 8y ago
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.
- tfranco 8y ago
  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.

ASalazarMX 8y ago

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.

stephenhuey 8y ago

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 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 http://www.rubymotion.com