4 ms·

What I don't understand is that Ruby already has the purported benefits that node.js provides. If you're doing networking stuff, we've got EventMachine for doi

by cmelbye 15y ago

What I don't understand is that Ruby already has the purported benefits that node.js provides. If you're doing networking stuff, we've got EventMachine for doing event-driven architecture, and that's a heavily proven library in production. Sinatra pioneered the microframework niche, and most microframeworks in other languages like node.js are almost a carbon copy. And, of course, we have the highly mature full-blown frameworks like Rails, which is becoming more modular by the day. It's dead simple to pull out the default "cruft" that Rails comes with to make it easier for beginners and custom build your models, routing, controllers, templates, assets, etc. I just don't see the appeal in switching to a less mature platform that doesn't have any benefits that I'm aware of.

fluorid 15y ago
Performance.
chc 15y ago
This reminds me of what people said when Rails was the new hotness, only the Rubyists were on the other end of it. All the Java devs and the Pythonistas were calling us late to the game and slow. The simple fact is, people enjoyed Rails more than what they had to offer at the time, so it grew and became what you see today. The fact that something is possible in two environments doesn't mean it's equally enjoyable in both. Never discount the impact that love can have on a project.
- tferris 15y ago
  I agree. People who are both afraid and little lazy to learn new stuff.
- cmelbye 15y ago
  I'd say that Rails made it much more quick to get started with web development than Java and Python did at the time, maybe. Certainly, I could do the same things with PHP as I could with the new hotness that was Rails, but I did it much more quickly with Rails and I ended up with nicer code. Node.js hasn't helped me in a similar way, but maybe I'm missing something.
  - deleted 15y ago
    [deleted]
tferris 15y ago
> If you're doing networking stuff, we've got EventMachine for doing event-driven architecture There's a big difference. EventMachine is an asynchronous library built with Ruby. EventMachine has nothing to do with Rails apart from them both being written in the same language. Now, go and try use both EventMachine and Rails in one project: it's a nightmare because they both follow different design principles. If you want to do event-driven architecture with EventMachine you will miss an ecosystem because a) there is none like around Rails and b) you cannot use Rails' ecosystem. Compare this to Node's ecosystem of 8,000 packages which follow all the event-driven architecture. > ... that's a heavily proven library in production. Heavily? Source? > Sinatra pioneered the microframework niche, and most microframeworks in other languages like node.js are almost a carbon copy. You are right and Sinatra was groundbreaking. But what's the goal of a microframework if the underlying stack is too complex for easy deployment or breaks with every patchlevel?
- cmelbye 15y ago
  I'm not sure if you fully understand the subject matter in question. EventMachine powers Thin, which is one of the most popular app servers in the wild. It's extremely easy to hook into EventMachine in Rails, and I encourage you to give it a try if you haven't yet. Even if you're not using Thin, EM can run in a thread and you can use it alongside Rails. As for a source for the "heavy use in production" comment, I suppose I can't provide one off the top of my head. However, if you're a Rubyist you know how often Thin is used in production. For a while, it seemed like every deployment guide suggested the use of Thin cluster to run the app. I'm not sure how you reached the conclusion that Sinatra (and thus, Rack apps, including Rails, in general) is difficult to deploy. We have mod_rails which makes it as easy as setting the apache DocumentRoot to your app. If that's not your cup of tea, it's a simple command to start up a cluster of Thin or Unicorn processes, and it's a few lines of nginx configuration to proxy. Essentially identical to how one would deploy node.js or any web development platform in existence for that matter.

by cmelbye 15y ago

fluorid 15y ago

Performance.

chc 15y ago

This reminds me of what people said when Rails was the new hotness, only the Rubyists were on the other end of it. All the Java devs and the Pythonistas were calling us late to the game and slow. The simple fact is, people enjoyed Rails more than what they had to offer at the time, so it grew and became what you see today. The fact that something is possible in two environments doesn't mean it's equally enjoyable in both. Never discount the impact that love can have on a project.

tferris 15y ago
I agree. People who are both afraid and little lazy to learn new stuff.
cmelbye 15y ago
I'd say that Rails made it much more quick to get started with web development than Java and Python did at the time, maybe. Certainly, I could do the same things with PHP as I could with the new hotness that was Rails, but I did it much more quickly with Rails and I ended up with nicer code. Node.js hasn't helped me in a similar way, but maybe I'm missing something.
- deleted 15y ago
  [deleted]

tferris 15y ago

> If you're doing networking stuff, we've got EventMachine for doing event-driven architecture There's a big difference. EventMachine is an asynchronous library built with Ruby. EventMachine has nothing to do with Rails apart from them both being written in the same language. Now, go and try use both EventMachine and Rails in one project: it's a nightmare because they both follow different design principles. If you want to do event-driven architecture with EventMachine you will miss an ecosystem because a) there is none like around Rails and b) you cannot use Rails' ecosystem. Compare this to Node's ecosystem of 8,000 packages which follow all the event-driven architecture. > ... that's a heavily proven library in production. Heavily? Source? > Sinatra pioneered the microframework niche, and most microframeworks in other languages like node.js are almost a carbon copy. You are right and Sinatra was groundbreaking. But what's the goal of a microframework if the underlying stack is too complex for easy deployment or breaks with every patchlevel?

cmelbye 15y ago
I'm not sure if you fully understand the subject matter in question. EventMachine powers Thin, which is one of the most popular app servers in the wild. It's extremely easy to hook into EventMachine in Rails, and I encourage you to give it a try if you haven't yet. Even if you're not using Thin, EM can run in a thread and you can use it alongside Rails. As for a source for the "heavy use in production" comment, I suppose I can't provide one off the top of my head. However, if you're a Rubyist you know how often Thin is used in production. For a while, it seemed like every deployment guide suggested the use of Thin cluster to run the app. I'm not sure how you reached the conclusion that Sinatra (and thus, Rack apps, including Rails, in general) is difficult to deploy. We have mod_rails which makes it as easy as setting the apache DocumentRoot to your app. If that's not your cup of tea, it's a simple command to start up a cluster of Thin or Unicorn processes, and it's a few lines of nginx configuration to proxy. Essentially identical to how one would deploy node.js or any web development platform in existence for that matter.