Not Invented Here Syndrome has been around a long time. But it used to indicate a sort of conservatism and fear in corporate culture.

This NIHS seems more the result of ADHD and impatience, sprinkled with a little enlightened precociousness.

You can see it in the satire surrounding computer programming. In the 90s, Dilbert had insight into the causes of NIHS. These days, Silicon Valley hits closer to the target.

(PS: the creator of this package looks to be getting a lot of flak here. Kudos to them for doing it, but they would benefit from understanding why it's such a shallow "replacement" for Cygwin.)

> (PS: the creator of this package looks to be getting a lot of flak here. Kudos to them for doing it, but they would benefit from understanding why it's such a shallow "replacement" for Cygwin.)

I agree. Like I said, I think it's a cool excercise. I'm all for doing things just to learn and explore. Which is what I'd classify this as. The things you learn doing stuff like this will likely help you in the future in some tangential way. No one should be excoriated for practicing their craft, especially in a case like this where it's a nifty project.

The problem is when you put down other projects or even OSes in this case that, frankly, are immensely more powerful and useful than what you've put forth. I think lacking the 'without the suck', it probably wouldn't have gotten much attention, especially the negative.

In instances like this, there's no issue with it being ES5.

However, in the web world, ES6 modules have a huge (pardon the pun) advantage that's just being realized. Because of the static nature of ES6 imports, you can eliminate unused code when you package it all together. The newest Webpack versions and Rollup are both taking advantage of this, and it can result in huge savings in filesize.

For example, lodash is a large library with hundreds of methods, and a lot of the time people only use 3 or 4 imports from it. If you use an ES5 version, you'll get all of those functions in a compiled bundle no matter what. If you use an ES6 version with Webpack 2, all the methods you use will end up being the only ones that are actually included in the final code.

I imagine most libraries has some common functions that ones from public API rely on (and of course some exports can be used within module itself).

Let's say you never import `helperX` and `helperY` from a library, but you import `usefulFunction` which relies on `helperX`. How would webpack know to exclude `helperY` but not `helperX`?

Unless it does some kind of code analysis, or lib is split in "module per function" or similar manner, I can't really see a way to achieve it. And if library is common core plus a bunch of modules per function it exports, how is that different in CommonJS versus ES6 modules?

Am I missing something?

I believe they are doing code analysis, at least that's what the README for Rollup says:

> Rollup statically analyses your code, and your dependencies, and includes the bare minimum in your bundle.

I don't think that's possible in all cases:

    var mod = {};
    module.foo = function () { return 42; };
    module.bar = function () { return -1; };

    module[Math.random() > 0.5 ? "foo" : "bar"]();

How can `Rollup` determine that I need both functions here?

That's why it only works with ES6 imports. ES6 imports must be made at the top of the file, and aren't dynamic. You must explicitly import what you need.

Additionally, this method only works with named imports. So for example, you can have two files:

File a.js

    export a = 5;
    export b = 6;
    export c = 7;
    export d = 8;
    export default {a, b, c, d};

File b.js

    import {a, b} from "./a.js";

    console.log(a);
    console.log(b);

c/d will never be included in the output file, nor will the default export. However, if you do:

    import a from "./a.js";

Then it won't optimize at all, because all of those objects are referenced in the default export.

Note that it's possible I'm wrong as to the specific optimization method, but largely speaking this is how it should work.

That much makes sense, but if I understand GGGP's example properly, they are talking about pruning unused internal references within a module, but GGP's response implies that somehow Rollup will prune those out.

Ah, I understand the confusion now. I'm not 100% sure how that code works, but I do know it uses estree and that case is tested for, nearly verbatim. Here's a link to the source which handles that sort of stuff.

https://github.com/rollup/rollup/blob/6fc8631ba1aad718885151...

Webpack 2 and Rollup don't support tree-shaking with Lodash yet. You'll need to use https://www.npmjs.com/package/babel-plugin-lodash.

The same thing has happened in the Python/Java/Ruby/etc. world. There's a reason "written in pure Foo" was an expression even before Node.js.

Granted- I've only been actively developing for about 18-20 years (not being facetious, I was about 14 and wouldn't have been privy to or really involved enough to perceive the thrashing or lack there of with Java 1.0 or Python 1.0, etc) but I don't think they ever really thrashed like what we're seeing with JS, I don't think they could have.

You didn't have broadband, you couldn't really share entire libraries of code freely, and package managers were not around at the very beginning. In 1995/96 you certainly had message boards and forums, but there wasn't a StackOverflow/whatever like community that made it easy to find an answer to your problem AND/OR a lib to help solve it.

You needed to know how to write a linked list, because you had to write your own. Well maybe not, but you had to write a lot of your own things that just don't need to be written today. God I remember my StringUtils jar from when I was a teenager. That damn thing followed me through college, and I gave the source to friends who then iterated on it (or not). But I didn't have a GitHub to post it to and an NPM to announce, and make it available to anyone looking for a new StringUtils library. It was just mine, free to anyone who asked, but no one knew to ask.

Now your ideas and code and spread to millions of people instantly AND they can find it, which is letting people start from an idea and iterate on it rapidly. Everybody is announcing their StringUtil as the next best thing since taking vowels out of words became cool.

So, I guess yeah- we did thrash 20 years ago, but we thrashed silently and alone.