5 ms·

Is this indicative of what's going on in the JS world today, with all the churn of packages and libs? Does it boil down to being sucky and not useful if it isn'

Is this indicative of what's going on in the JS world today, with all the churn of packages and libs? Does it boil down to being sucky and not useful if it isn't written in ES6/TypeScript/Whatever and not invented by your team? Why do the other things suck because they're not this? EDIT: I've said it on other threads- I like the creativity and exuberance in the JS community. I'm not putting it down. There's just a lot of churn/NIHS. (I didn't seem to be getting downvoted, but I also want to be clear that I'm not putting the community down) END EDIT I think it's a cool excercise. Why would I ever want to use this in the way it is saying it should be used? Why would I ever use this period?

AnkhMorporkian 11y ago
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.
- elmigranto 11y ago
  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?
  - zbuttram 11y ago
    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.
    - frutiger 11y ago
      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?
      - AnkhMorporkian 11y ago
        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.
        frutiger 11y ago
        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.
        AnkhMorporkian 11y ago
        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/6fc8631ba1aad718885151f4c2eb33596cc6fa45/src/Module.js https://github.com/rollup/rollup/blob/6fc8631ba1aad718885151...
- jdd 11y ago
  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 https://www.npmjs.com/package/babel-plugin-lodash.
spenuke 11y ago
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.)
- manyxcxi 11y ago
  > (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.
deleted 11y ago
[deleted]
oblio 11y ago
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.
- manyxcxi 11y ago
  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.

AnkhMorporkian 11y ago

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.

elmigranto 11y ago
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?
- zbuttram 11y ago
  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.
  - frutiger 11y ago
    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?
    - AnkhMorporkian 11y ago
      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.
      - frutiger 11y ago
        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.
        AnkhMorporkian 11y ago
        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/6fc8631ba1aad718885151f4c2eb33596cc6fa45/src/Module.js https://github.com/rollup/rollup/blob/6fc8631ba1aad718885151...
jdd 11y ago
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 https://www.npmjs.com/package/babel-plugin-lodash.

spenuke 11y ago

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.)

manyxcxi 11y ago
> (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.

deleted 11y ago

[deleted]

oblio 11y ago

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.

manyxcxi 11y ago
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.