These guys nailed my point pretty good: http://www.perfectline.ee/blog/optimizing-ruby-on-rails-appl...
These guys nailed my point pretty good: http://www.perfectline.ee/blog/optimizing-ruby-on-rails-appl...
What is node equivalent of: "rails g resource User email:string password:string"? AFAIK there is none. At least not one that would take care of migrations, validation, security, logic and views.
And if I want to use postgres? Sure, there's a npm package. But it's for queries, I still need to define models and validation manually.
....
http://stackoverflow.com/questions/9897017/railwayjs-vs-towe...
But the point is another: the npm world is much more modular than the Rails mononblock, there is much less magic involved. You setup your own stack which is simpler than setting up Rails, rvm, gems. Rails isn't bad—it's great but getting off track or looking behind the magic can get a tedious task ...
As far as passportjs goes, that's pretty much it.
On the other hand, devise handles A-Z when it comes to auth: it sets up models, routes, views, validation, different built in plugins like remember me, different encryption types, retry limits on failed logins,...
Googling for tutorials also reveals the true situation. There are like 2-3 good tutorials on passportjs. On the other hand there's hundreds of articles/posts on how to use devise, how to implement it, how to use it with omniauth...
I could make a comparison like this for almost every gem/module and I bet 95% of times, rails gems will win over npm modules in terms od popularity, completeness, community support and in-the-wild usage.
I'm not trying to bash node.js here. It's a wonderful tool and I use it. almost on a daily basis. But only where it makes sense to me.
Oh and about the 'magic'. You have two options:
1: start with bare language and proceed to magic as you learn
2: start with magic and dig into nitty gritty as you learn :)
Which of the two produces results faster? To me it's 2.
You use Rails because you want and understand the magic, not because it's magical. You might be initially allured by the terseness of Rails, but the learning curve of what Rails is doing is why you use robust frameworks in the first place -- because you want shortcuts and optimize away from trivial things like form parameter passing and route generation. Learning what `resources :topics` does is "tedious" in a much different way than the tedium of scoping out:
app.get '/topics'
app.get /topics/:id'
app.del ...
...
Because then you see an npm package like `express-namespaces` that lets you do this: app.namespace '/topics', ->
app.get '/', ->
app.get '/:id', ->
And after a while, some people agree to consolidate this into: app.resources 'topics'
And soon a part of the community decides that they might prefer these sort of conventions and it becomes the seed that blooms into a robust framework....And then another part of the community will complain that it's "too magical" while I do the Jackie Chan 'wtf' gesture because there's a crystal clear API and they'd rather form a Cloud Chorus against alleged "magic" than humbly accept that they might not appreciate the same things that other people appreciate.
Yes Rails does all that for you automagically but you can use a lightweight ORM like FastLegS. A model is as simple as this:
UserDao = FastLegs.Base.extend({ tableName: "users", primaryKey: "id" });
To expose it:
app.get("/user/:id", function(req, res) { UserDao.find(req.params.id, function(err, result) { res.json(result.rows[0]); }); });
Let's not forget about unit tests. I can run well over 100 test cases in just over ONE second! Rails is PAINFULLY slow at this.
I've done enough Rails to know how productive it is, and there are many things I miss. I'll argue though I'm more productive with node.js since we do most GUI with Backbone on the client. I can share code between client and server, for example validations.
http://rakeroutes.com/blog/the-problem-with-completely-clien...