> Finally, at the end of the day, if a JS framework becomes a better solution than anything else I use, I will certainly switch.
I'd recommend Matt just to dive deeper into Node, Express, Flatiron and all the 8,000 packages and he will discover tons of better solutions instead of sticking to the current status quo. And Node often feels faster, easier and less cumbersome than Ruby/Rails (once getting used to callbacks). I didn't mention performance which would be one reason to use Node—Matt wrote he would use it because being the new cool framework.
Ruby mainly exits because of Rails. Rails is the most automated web framework on earth, it's great and paved the way. We use both every day as first choice because of its maturity, the community, the high day rates we get, ten thousands of great gems seaming-less working together, the convention everybody knows.
Definitely Rails is the best full-blown solution for web development but real innovation happens somewhere else.
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.
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.
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.
> 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.
> 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?
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.
I think Matz should focus on the language and the (very outer) ecosystem. Ruby is powerful enough for many innovative new libraries, but not necessarily professional enough. I wish a huge company would enforce some convergence here.
* Ruby Core is a black box that produces tarballs. Point releases and even patchlevel releases will happily break code without warning. The only way to test if your code still runs is to run it, all of it. This is complicated by the fact that mod_rails cannot run each project on its own version of Rails.
* The professional Ruby world (=Rails scene) is a different beast. Most projects are open source, but linked to a single name (person or company). There is little incentive to maintain projects cooperatively, because if the project isn't yours, then how do you present it on your github-based resume?
* And then there are the hobbyists (with some overlap of course), many of which honestly cannot understand why some companies are still running 1.8.7 or Rails 2 and don't have their employees live on the edge all the time.
Add all these individually amazing but uncoordinated programmers together..and suddenly every line has to be prefixed by "bundle exec"; .rvmrc will specify your Ruby version, except if you use rbenv; your gemspec contains your dependencies, and so does your Gemfile (with subtle differences); your project info is spread across github, ruby-doc, ruby toolbox, rubygems and your own domain (to advertise yourself)...and often enough, the only documentation to guide you are blog entries, which sometimes omit the timestamp for stylistic reasons.
Ironically, the Rails Core - which gets the most flak by far - provides documented and tested fixes for each recent major and minor version of Rails.
Hm, I think my third bullet was a bit off. There are plenty of vocal "Edge Ruby" enthusiasts on IRC - people who care (too?) deeply about the language, mostly - but there are also some great projects that are completely independent of Ruby Core and the Rails world. I'm pretty sure about (1) and (2) though.
Ah, I think we may have been talking cross purposes.
Languages themselves are innovative, but I guess I don't see people using the language as the innovation there, but rather the creator and maintainer. More specifically I don't see my early adoption of Ruby as innovative.
No to the flamewars! I love Ruby and miss it every day (though C++ is growing on me).