Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> your list of 30 random npm packages does not satisfy the requirement

I like Rails, but to be fair, doesn't Rails also require a list of 30 random gems? Unless things have changed, authorization and authentication aren't even built-in, so people have to navigate random third party gems, and remember, you don't want CanCan, but you want the fork, CanCanCan. Again, I like Rails, and maybe it's still the nearest to an all-in-one framework, but I think somebody who took the next step and created a truly all-in-one framework would win big.

My current project:

  $ grep -c ^gem Gemfile
  75


It's not a matter of how many packages are required; that isn't the issue. The reason "30 random npm packages" doesn't satisfy the requirement while Rails does is that Rails provides a high-level framework for integrating those disparate packages into a single cohesive application, while with npm packages you have to write that framework yourself.

Perhaps the best example I can give for this difference is Devise, an authentication plugin for Rails. Have a look at the instructions for setting up Devise on Rails: https://github.com/plataformatec/devise#getting-started You just add the dependency and boom, you instantly get a database migration for storing authentication data in your database, automatic integration with Rails's email notification system, a single command you can run to generate all boilerplate files, and a single line of code you can add to your controllers to automatically enforce authentication for any particular action. With a similar authentication package in a Node application you'd most certainly have to set all that up manually.


> doesn't Rails also require a list of 30 random gems?

    my-MacBook-Pro:production-web-site me$ grep ^gem Gemfile | wc -l
      74
I have mixed feelings about this. On the one hand, the framework isn't strongly coupled, tested as a whole, and opinionated like in Java and .NET land.

On the other hand, overriding the "default" Rails behavior for e.g. logging or SAML is pretty easy as long as you can find a gem compatible with the versions of all your other gems. This can easily spiral into out of control technical debt where you're stuck using gems from 6 years ago out of fear you'll tug on one of them and bring the entire house of cards tumbling down, but I've consistently been surprised at how little effort has been required to do gem upgrades as long as they're planned carefully.


Authentication is built into Rails, albeit in a less "batteries included" way than something like Devise. You'll have to code your own user model, but `has_secure_password` will give you perfectly fine security around storing passwords.

And while gems like CanCanCan are great, not every application needs them, and it's relatively straightforward to set up authorization logic directly for most simple cases (i.e. something like "users control their own things, admins control everything".

You're right in the sense that I've very rarely seen sizeable apps that are mostly "stock" Rails outside of things literally developed by Basecamp.


Django fits that description.


Came here to say the same thing, and add that with Django, you have access to the amazingly vast landscape of Python libraries. Just being able to spawn Celery jobs is a huge plus.


Couldn't see any advantage over Sidekiq, Resque and friends. Not saying it's bad but just that the Ruby community has got your back for any web development need you might have...when working with Django I didn't get the feeling I am working with superior libraries.


An advantage of Celery is that it doesn't require payment for an enterprise version to add things like scheduled tasks.


If you're talking about Sidekiq there's free open source solutions for that in Rails world. https://github.com/moove-it/sidekiq-scheduler https://github.com/ondrejbartas/sidekiq-cron Besides Sidekiq is just one out of many.


Good to know, cheers


One thing I'll say about Node is that the module names seem to be semantic for the most part, unlike the cute names gems seem to get. Walk into a Ruby developer's office and if you see a white board scribbled with random words, you don't know if they have reached the point of stress where their mind has started to break with reality, or if it's just a list of gems for their new project :-)




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: