Same people who shame other's work for not being modular enough for their taste, would worship a one-line module[0] that is modular down to every subroutine.<p>[0]: <a href="https://github.com/blakeembrey/is-upper-case/blob/master/is-upper-case.js" rel="nofollow">https://github.com/blakeembrey/is-upper-case/blob/master/is-...</a>
I'm a fan of ClojureScript and one reason being how easy it makes it to take advantage of the Closure compiler. But it can be a double edged sword. At times the advanced compilation mode breaks your code, and it can be <i>extremely</i> difficult to track down why. The combination of symbol renaming and dead code elimination usually means final JavaScript that looks utterly nothing like the ClojureScript you started out with.<p>Just today I had an issue where the Closure compiler decided my call to (set!) wasn't necessary, and so it removed it, completely breaking my app. The best solution I could find was a work around involving a pretty large let block. I was just happy to get it working, debugging optimized Closure compiled code is not fun at all.
Relevant discussion thread on github[1].<p>Max Ogden's last comment irks me. After a long and fairly productive discussion, he generalizes / calls out people, and doesn't explicate on what he's trying to point out.<p>[1] <a href="https://gist.github.com/substack/68f8d502be42d5cd4942" rel="nofollow">https://gist.github.com/substack/68f8d502be42d5cd4942</a>
This is an area where the new syntax for modules in EcmaScript 6 does really well. Since exports are static, a dead code elimination tool can figure out which exports from a module are being used and remove the ones that are not being used. As mentioned in comments about how the Closure Compiler works, you can't really do this with purely dynamic code, but you can do it with static imports/exports.
This is a strange post, it's about two completely separate things.<p>I do agree with the "modularity shaming" idea though, the JS community does seem to be overzealous about that. However I think it better to err in that direction than the other direction.
Is the Closure Compiler specifically good at dead code elimination in Closure libraries? Theoretically I would imagine that it could be applied to anything, though I'm sure there are many Javascript tricks that would make dead code detection ineffective.
Why don't we just let browsers treat javascript files as modules, just like we have shared libraries on our OS?<p>This way, libraries such as JQuery, could be cached, and shared between websites.
I had a twitter convo with David DeSandro about this exact thing today <a href="https://twitter.com/thomasreggi/status/552903079142883329" rel="nofollow">https://twitter.com/thomasreggi/status/552903079142883329</a>. I've really taken to projects like <a href="https://github.com/tjmehta/101" rel="nofollow">https://github.com/tjmehta/101</a> where you are forced (there's an error if you include the index) to include the files / functions that you need directly. He raised some good points.
Of course GWT and Dart also do dead code elimination (also known as tree-shaking). There's a reason Google's JavaScript-targeted compilers implement this.<p>On the other hand, the consistent dedication to writing tiny libraries in JavaScript ecosystem is not a bug. Tree-shaking compilers make it somewhat harder to tell where the bloat is coming from, and that encourages people writing libraries to get sloppy.
I responded a while back in another thread about "small modules" in npm. Filesize is only one (rather small) facet of why some people prefer this approach to the "put everything under the same hood".<p><a href="https://news.ycombinator.com/item?id=8830058" rel="nofollow">https://news.ycombinator.com/item?id=8830058</a>