| While I agree about the "no reinventing the wheel" part (after all that's one of the benefits of our product), I think Cappucino had made some choices that the random developer could not come to terms with. I don't think that this is due to laziness or rouded-corner cravings (although the "new shiny toy" effect is very much existing). I think this has more to do with the different timelines web developers face when building apps. Not all of them can afford the long learning curves required by Cappucino and the fact that objective-J is only useful for Cappuccino. Not all of them need to build app-looking apps or spend lots of time bending the defaults to look like something else So the web community turns to low learning curve libraries as a side effect of not having the time to commit (as opposed to not wanting), better ones coming out all the time (things moving at a whole order of magnitude faster than in other software development areas), and using only 10% of the power brought by cappuccino. This encourages more quick, single feature libs, which in turns brings more developers into that worldview. Note that this argument is not about wether this is right or wrong. More about the why. One can note that making those micro libraries work together is getting harder and harder, and that some folks (full disclaimer, we are one of those) are building glue layers and light architectures to guide developers and ease integration and make those libraries interact together seamlessly. Take http://github.com/aurajs/aura (that's the one we're working on). It acknowledges both the fact that small, single-feature libraries are the way the web is heading, and that making those interoperable, and easy to load (a clean module system is central to aura) needs work. Maybe small, badly written, non interoperable, single use libraries are just a step on the way to a truly modular, flexible and light web development process. |