Oh boy, another one of these. Cygwin is useful because it provides a POSIX C API on Windows. It is not useful because of its shell and coreutils. And saying it uses "pure ES6" is stretching it - it's using the plain ES5 Node.js require/export patterns instead of ES6 modules.
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?
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?
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.
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.
For my purposes, I don't need a POSIX C API. What I need are the shell commands that I commonly use as my IDE to be available on Windows without a massive hack.
Cash seems to be right up my alley, and I'm excited for this.
I'm not saying that it's not without use-cases. I'm saying the readme is pompous and overstates its usefulness and was clearly written by someone who doesn't have a clue about the tools they're replacing.
I personally haven't had a windows machine without git in years. Distribution for windows includes somewhat proper shell with unix utils. I can use the same .bashrc I have on my linux machines, write commit messages using vim, have colors in the terminal, etc...
Cygwin is overkill unless you are trying to mimic your exact non-Windows environment, and it doesn't mix well with Windows' vanilla CMD environment. For those of us who want to be working with more Windows than UNIX, but who are used to standard coreutil commands, 1/100th the functionality of cygwin actually sounds kind of great!
Not saying that the commands need to be written in JS, but it seems like every language gets at least one coreutils implementation, so why not?
So much negativity around here. Honestly I find it pretty neat that JS has come this far.
I also have Fortran, Cobol, SWI-Prolog, OCaml, Elixir and Erlang on my computer, so I guess we need to re-implement core utils in these languages too. Using the followings in any technical arguments is just plain stupid:
Maybe simplicity isn't exactly what I'm talking about, but yes. In fact, I couldn't run your hello world without running my OS. So from a practical point of view, me running your hello world has a dependency on my OS. From that perspective, it's easier for me to run my OS than your hello world.
No, I don't. I have a vague recollection that cygwin was a huge and confusing monolith, but I haven't looked at it in years. This new javascript thing sounded more straight-forward. It's not really objectively supported.
Yes, but - when you hit some bug or just need some specific combination of commands, there would be thousands posts on the web that explain how to do on unix that will work in Cygwin. Will they work in this environment?
More often than not, if I'm working on a windows machine, I'm not programming in C. I'm probably working on something in C# or Java. I don't care about the C API. I just want the terminal to work in more or less the same way it does on linux/osx.
Oh boy, another one of these. Cygwin is useful because it provides a POSIX C API on Windows. It is not useful because of its shell and coreutils. And saying it uses "pure ES6" is stretching it - it's using the plain ES5 Node.js require/export patterns instead of ES6 modules.
>1/15th of the size [of Cygwin]
Haha, and 1/100th the functionality