I never really learnt Rails, to be honest. I dabbled, but never got fully into it. The thing is, the way I'm writing web apps now (nice API's over straight classes, composable libraries, and a routing layer over the top to give it a REST interface) doesn't fit my mental model of how Rails works.
Similarly, I've somewhat abandoned "MVC" for web-apps. Nice API's with the ability to have any front-end, not kicking out HTML from my framework, and the like -- that's what I'm doing now.
Don't get me wrong -- I know that Rails (especially 4) can do all this as well. Heck, there's not much stopping me from doing what I'm doing here with straight Ruby, a couple of libraries and Sinatra (I have a good friend who does exactly that). But for some reason, I've instead written off ruby entirely for that use-case.
I'm merely the n=1 here though, and as a non-ruby programmer, my opinion doesn't mean much I guess. But I find it curious how I ended up skipping it.
Interesting, as that's very much how my mental model of how Rails works:
1. The routing layer is all about declaring a resource which gives you all 7 major REST operations, and
2. there's a nice facility for responding_to any data format (html, json, js, text, etc) you want.
With rails scaffolding, you can pretty much get all boilerplate code written for you, and have it very simply implement a REST backend for a more "heavyweight" javascript framework (angular, ember, etc).
I wonder if the issue is that rails didn't originally start out this way, and now people assume that Rails is stuck in the past?
I think the article gets it right in that Ruby needs better concurrency primitives (promises are a nice idea), and esp better performance. If Javascript can be as fast as it is with V8, there should be nothing stopping Ruby from achieving similar levels of performance.
I think its not an issue of anyone thinking that rails can't do those things. Its just that there are other things out there that are not as thick, which can also do restful routing. Unless you're already entrenched in Rails, there isn't much benefit to using it over sinatra or express, which allow you to modularize the other components that you need, while also having a lower barrier to entry.
I don't think many Rails developers are abandoning the platform though, so dying probably isn't the right word for it.
> I wonder if the issue is that rails didn't originally start out this way, and now people assume that Rails is stuck in the past?
I don't think I got it across in my post correctly, but that's basically what I was trying to say, yeah! I even _know_ that I have that cognitive bias, and yet it remains. I even tried to pick up Rails 4 last week, and put it back down rather quickly again.
As someone who programs when the urge hits, rather than as a day job, I ended up playing catch up with Rails. Each time I went to start a project, there's be some new changes/features in Rails for me to learn.
These days, I'm happy coding away in Padrino, which seems to sit between Sinatra and Rails in terms of features and functionality.
For me, Rails just became too big to keep up with. It's more fun and productive with a lighter-weight framework that can get you 90% of the way there. For a newcomer to Ruby, it doesn't seem to be the old "watch me write a blog engine in 5 minutes!" anymore. That might be why the other popular frameworks are getting the attention...
If you're talking about single-page apps I don't think it's the new web programming paradigm. Most applications fit much better as classic sites which Rails is so good at. In fact I think most SPAs I've seen would be better off with a "traditional" stack. I always find myself thinking "why is this even a SPA?".
JavaScript is a messy language, but ignoring that, the module ecosystem is a mess. There are many duplicated modules, many of them done in a half-assed manner by inexperienced developers and rarely updated.
For example, the Node community absolutely loves MongoDB for inexplicable reasons, and support for other datastores is terrible. Despite Postgres supporting hstore for years and Node being popular for years, the two hstore modules are "node-postgres-hstore" (7 stars on github) which hasn't been updated in 1 year and "node-hstore" (17 stars on github) that hasn't been updated in 2 years. Everything I've seen indicates that this is typical for modules in Node.
Meanwhile, Ruby and Rails support Postgres extremely well at this point.
Similarly, node has several migration libraries, all of which are pretty limited. One of the popular ones, "node-migrate" by one of the most prolific node module developers, still has an open issue from 2 years ago about using timestamped migrations, with the developer commenting as if the concept is news to him (https://github.com/visionmedia/node-migrate/issues/2)
The greater robustness means that:
1. There are more high quality modules, so if you look hard enough, you are likely to find one for your tasks,
2. There is an even greater number of duplicative, half-assed, and poorly maintained modules than there were in 2007 (some of which existed but weren't half-assed or poorly maintained in 2007), and those are still quite often the first ones you'll run into when looking for something that does what you want.
> For example, the Node community absolutely loves MongoDB for inexplicable reasons, and support for other datastores is terrible
Right, because everybody uses Postgres, right? All of the major database vendors are supported quite well, and just because hash storage in Postgres (which is already a stretch) is not as well maintained doesn't mean "support for other datastores is terrible).
Node.JS is great when you simply need to move bits from disk onto the network with minimal processing in between and your app is otherwise I/O bound. This is what gives Node.JS its superficial appeal. The trouble comes when you need to write anything of complexity and you find yourself in callback hell and your code becomes difficult to reason about at an unreasonable rate. This makes adding new features to any large code base a ghastly nightmare.
JavaScript is also a really shitty, poorly conceived language with cruft galore, and this compounds the hell of event-driven programming.
I dropped Node.JS because it made me hate programming.
In defense of Node (God, there's a phrase I never thought I'd find myself writing), it's also much newer than Java is. Given ten or fifteen years for people to work on them, the docs almost certainly would get better.
To be honest, the Java API documentation is pretty stellar. I am/was a Python developer, and I remember hearing the claim that Django has great documentation. I don't know if I'm spoiled by Java or what but if Django passes for "great" then I think Java's docs should pass for legendary.
