| This is exactly what I thought when I saw this on the front page. I'm wouldn't be surprised if they eventually add a kitchen sink library. Choosing a monolithic framework doesn't encourage separation of concerns and clean interfaces. It also makes scaling horizontally more difficult. So many ruby gems are built around rails instead of being built as separate discrete libraries. This means that once Rails get really long in the tooth (it has already started to) that it's going to take a bunch of libraries that could have been timeless along with it had they not been so deeply integrated with Rails' architectural features. The fact that a document like this exists...
https://github.com/radar/guides/blob/master/sprockets/sprock... This is a detailed guide to the internal workings of Sprockets. Hopefully
with this information, somebody else besides Josh Peek, Sam Stephenson,
Yehuda Katz and (partially) myself can begin to understand how Sprockets works.
... that connects so many parts of rails isn't a good sign.node.js, or more specifically npm, got things really right by making the inclusion of libraries really trivial and easy to separate concerns. I can't begin to imagine the complications with trying to do proper async around a framework that wasn't designed from the ground up to be async. I'd expect that you'll often have to dig into the internals of Rails to discover where something is functioning synchronously where you didn't expect it to. Don't get me wrong, I love the opportunity to dig into other people's code that I rely on, but that is only fun with libraries, not frameworks. When digging around in frameworks you often spend tons of time having to investigate glue code between parts to even understand the part you need to understand. |