3 ms·
as spyder posted there are npms providing this functionality. there are 8,000 packages for all your needs. But the point is another: the npm world is much more
by tferris 14y ago
as spyder posted there are npms providing this functionality. there are 8,000 packages for all your needs.
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 ...
- tzaman 14y agoYeah but let's compare two relatively popular solutions for authentication in each frameworks: Rails has devise, Node.js has passportjs. They both support numerous 'strategies' (local, facebook twitter, openid...). They also both support the login/logout functionality. They are both ok documented too (there's always room for improvement there). 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.
- danneu 14y agoThere really isn't a Rails vs Node dichotomy, though. More like Sinatra vs Express -- you can write glue code in the Ruby ecosystem as well if that's what you want to do. 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.