38 ms·
Not having tons of libraries means that my team doesn't have to fight bitrot regularly though. Also bug reports / PRs are actually handled adequately by the big
by Rygu 12y ago
Not having tons of libraries means that my team doesn't have to fight bitrot regularly though. Also bug reports / PRs are actually handled adequately by the bigger frameworks and their bigger pool of contributors, so code quality, which I find an important aspect of the software I deliver, is very much guaranteed.
- encoderer 12y agoI don't see much point fretting about bit rot. That's a murky future problem and there is little to guarantee the code we're writing today will outlive the libraries we're using. Instead what I care about is productivity and my experience as an engineer and engineering manager is that the simple, small, annotated source of libraries like Backbone and Underscore will beat the monolithic uber frameworks 9 times out of 10. The trouble is that people often use examples of what you can accomplish with a framework if you follow the common path. But we've all been there -- a 20 hour feature where you build 90% of it with heavy framework support in the first 10 hours, then spend the next 10 fighting the framework for whatever it is that you need done differently than the framework prescribes. This blunts that seemingly-huge time save that a framework appears to provide when you watch a 5 minute build-a-blog screencast. So in the end, it comes, as it usually does, to mastery. The guy who has developed mastery over his tools will outperform, and I think it's a lot easier to master these small libraries with accessible source code.