2 ms·
Talking about 'libraries vs frameworks', tenderlove spoke about frameworks providing bare-metal interfaces for libraries and let libraries implement those inter
by iffyuva 14y ago
Talking about 'libraries vs frameworks', tenderlove spoke about frameworks providing bare-metal interfaces for libraries and let libraries implement those interfaces in whichever way they want. but its still not sure to what extent that would solve the problem.
Recently, bare-metal queue implementation in Rails https://github.com/rails/rails/commit/adff4a706a5d7ad18ef05303461e1a0d848bd662 https://github.com/rails/rails/commit/adff4a706a5d7ad18ef053... has been discussed 'for and against' extensively.
- parley 14y agoI'm not quite sure I understand. Speaking of the generic case, the (quite broad, I admit) statement that modular and composable functionality should enable both the unified-libraries-approach (or frameworks) and pick-and-choose-approach should (when applied) solve the OPs problem of not wanting to use what he/she doesn't need, shouldn't it? I support the idea of a framework essentially being a light-weight layer on top of libraries, but if the framework just uses a single monolithic library then little (but something!) is gained. If it uses one or more libraries that are all properly composed of smaller modules, etc, etc, then a lot of flexibility is gained. I'm not very familiar with Rails - especially its internals - so it's hard to comment on this particular case. However, making job queueing modular seems to have found the approval of most people in the commit comment thread you linked. But I agree that the distinction is never clear cut, and everything needs a discussion on a case-by-case basis...