Re:The state of JavaScript modules
by bryanlarsen on Monday May 29, 2017 @09:32AM
(#14438997)
The article explains the approach that the node.js ecosystem is taking to bend over backwards and maintain full backwards compatibility. Javascript from 1997 still works; write your code 2015 style and it'll still work 20 years from now. You don't have to live on the bleeding edge -- you'll lose tree shaking but you'll gain some sanity.
[ Parent
| on HN ]
No disagreement on that point. I am talking about new and maintenance projects. My pet peeve is "just install this, just use that, oh and by the way also definitely install this" for things that should either be built-in, or well-standardized (minifiers, tree-shaking, transpiling). And they are not.
If I get into a new team and there are 3 devs already writing JS, it's highly unproductive because it feels like you have to very regularly catch up with the JS ecosystem. Not to mention the strong peer-pressure factor of "cool kids use X, Y or Z". And this is a very underestimated phenomena by so many devs -- and it exists in almost every team.
Re:The state of JavaScript modules
by bryanlarsen on Monday May 29, 2017 @09:47AM
(#14439060)
"minifiers, tree-shaking, transpiling" should not have been part of 1997 Javascript so they have to be added at some point. And this post is part of that standardization that you're asking for.