3 ms·

Sigh. This is like that timecop thing -- dumping more stuff in core that lives better as part of a gem. Resque, DelayedJob, Sidekiq... All have their drawbacks

by kalleth 12y ago

Sigh. This is like that timecop thing -- dumping more stuff in core that lives better as part of a gem. Resque, DelayedJob, Sidekiq... All have their drawbacks/benefits. I know this can just work as a 'wrapper', but in an agency environment, i've used queueing on about 20% of sites. Absolutely no reason to want to put this in core imo.

unfunco 12y ago
It being included will have no performance overhead since it's only loaded if it's used. I'm personally for this idea, I've used DJ, Resque and Sidekiq, all in the same project (increasing load), and in that order; It would have been much nicer to have to only change the Gemfile when I made the switch. Your comment, whilst a perfectly valid concern, reminds me of an article DHH posted: http://david.heinemeierhansson.com/2012/rails-is-omakase.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...
- kalleth 12y ago
  Performance wasn't my concern at all. Overcomplicating the rails 'core' is my concern. I'd much rather start from a lightweight 'base' which solves most of the common cases and pull in extras as required for what i'm working on. Rails should be a framework that allows you to layer extra functionality ontop of it.
  - _pius 12y ago
    Overcomplicating the rails 'core' is my concern. I'd much rather start from a lightweight 'base' which solves most of the common cases ... Background jobs are a common case. How many web applications never send an e-mail?
    - mackwic 12y ago
      He probably sends emails synchronously.
amorphid 12y ago
Only seeking clarity here. Are you saying that adding ActiveJob to Rails code is bloat, and it should be an opt-in gem instead of having to remove it? Example, you'd prefer A to B? A) $ rails new foo_app # add 'active_job' if/when you want it B) $ rails new foo_app --skip-active-job # forced to rip it out EDIT: I think you answered my question in another sub-comment. No reply requested unless you have something new to add
- deleted 12y ago
  [deleted]

by kalleth 12y ago

unfunco 12y ago

It being included will have no performance overhead since it's only loaded if it's used. I'm personally for this idea, I've used DJ, Resque and Sidekiq, all in the same project (increasing load), and in that order; It would have been much nicer to have to only change the Gemfile when I made the switch. Your comment, whilst a perfectly valid concern, reminds me of an article DHH posted: http://david.heinemeierhansson.com/2012/rails-is-omakase.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...

kalleth 12y ago
Performance wasn't my concern at all. Overcomplicating the rails 'core' is my concern. I'd much rather start from a lightweight 'base' which solves most of the common cases and pull in extras as required for what i'm working on. Rails should be a framework that allows you to layer extra functionality ontop of it.
- _pius 12y ago
  Overcomplicating the rails 'core' is my concern. I'd much rather start from a lightweight 'base' which solves most of the common cases ... Background jobs are a common case. How many web applications never send an e-mail?
  - mackwic 12y ago
    He probably sends emails synchronously.

amorphid 12y ago

Only seeking clarity here. Are you saying that adding ActiveJob to Rails code is bloat, and it should be an opt-in gem instead of having to remove it? Example, you'd prefer A to B? A) $ rails new foo_app # add 'active_job' if/when you want it B) $ rails new foo_app --skip-active-job # forced to rip it out EDIT: I think you answered my question in another sub-comment. No reply requested unless you have something new to add

deleted 12y ago
[deleted]