David Nolen has made a compelling argument against “Modularity Shaming” – that is, rejecting a library or tool for being too bloated with features and not being modular enough. He argues that the main thinking behind Modularity Shaming is that the resultant production code also becomes bloated with needless dependencies, leading to poorer UX as users need to download more kb of data. The JavaScript community has come up with a couple of approaches to this problem, namely:
- Asynchonously load the JS library modules you need
- Use smaller libraries (e.g. Zepto as opposed to jQuery)
However, this problem can also be solved by using the Google Closure Compiler, a tool developed by Google for optimizing large JavaScript code bases such as the Google Closure library. It offers more advanced optimizations than the usual approach of minifying and concatenating JS code, in particular Dead Code Elimination aggressively strips out any code not being used by your application. In his post David gives a date time example with internationalization support built on Google Closure in 4kb of gzipped code, whereas the equivalent code using Moment.js would weigh at least 40kb.
In the original thread David links to where the term “Modularity Shaming” was coined, commenters raised additional concerns about how the batteries-included approach leads to documentation issues and “bitrot”, but on a technical level the Google Closure Compiler gives us a solid foundation to build large-scale web applications on.
Devvr 