2 ms·

IMO it's the "javascript way" to invent new tools instead of trying to improve others (when it makes sense to do so). Let me explain that a little bit... The j

IMO it's the "javascript way" to invent new tools instead of trying to improve others (when it makes sense to do so). Let me explain that a little bit... The javascript "ecosystem" takes the unix philosophy to the extreme in many ways. And one of the points of the unix philosophy is to try to avoid "bloating" tools with tons of options, and instead trying to create new tools where appropriate. Many of those are perfect examples of where "improving" a current tool with the changes they wanted would end up with a more complicated and difficult to use tool. - NPM makes tradeoffs that the majority of developers in the JS world want right now. Like it or not, deterministic installs isn't something that most people want or need (at least, they don't know that they might want or need it). Making a new tool that anyone can use when that is needed is a great solution, and it avoids bloating NPM with a hundred little flags and tons of code to cover edge cases. It's the perfect example because anyone can switch to using yarn when it's needed without any extra work. - Nuclide is actually just a layer on top of Atom. They wanted a bunch of things to all work one way, so rather than try to get Atom to change to include what they wanted, or require developers install a ton of extensions, they packaged them up on top of Atom as one system. - Jest had different goals at the start. Testing react components was ugly and difficult, and Jest wanted to solve that first (IIRC, i'm not very familiar with jest unfortunately). Again, it's something that can be used if needed, and can even be combined with other testing tools if you want (we almost did that at my work, used Jest to test the front-end components, and our current mocha+friends setup to test the "business logic").

deleted 10y ago
[deleted]
aikah 10y ago
> The javascript "ecosystem" takes the unix philosophy to the extreme in many ways. Bullshit, nix systems rely on stable global dependencies, not 50 versions of the same library installed locally. I don't buy the "unix philosophy" excuse. The nodejs community just doesn't care about API stability which is why there is that inflated number of modules with 90% never maintained more than a year.
- Klathmon 10y ago
  Come on now, I said that it's like the unix philosophy in many ways, not that it's unix... - Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Which is what this thread is about. - Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. JS has wonderful stream support, and it's used everywhere in many tools. This is probably where JS is the weakest out of these. - Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. I mean, if JS isn't this taken to the extreme, i don't know what is... - Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them. This also describes JS to a T. Tons and tons of tools, each often only usable by a small number of people in niche situations. Now i'm not saying that JS is as well designed as unix, i'm not saying that it's exactly the same as unix, i'm not saying that Unix doesn't do things better, or that JS doesn't have it's warts. I'm just saying that it's the "unix philosophy" taken to the extreme. It might not be good, it might not last, but it's working out pretty well for many people right now.
- GFK_of_xmaspast 10y ago
  > 50 versions of the same library installed locally Are you seriously telling me you've never had a linker (static or dynamic) choose the wrong library?

deleted 10y ago

[deleted]

aikah 10y ago

> The javascript "ecosystem" takes the unix philosophy to the extreme in many ways. Bullshit, nix systems rely on stable global dependencies, not 50 versions of the same library installed locally. I don't buy the "unix philosophy" excuse. The nodejs community just doesn't care about API stability which is why there is that inflated number of modules with 90% never maintained more than a year.

Klathmon 10y ago
Come on now, I said that it's like the unix philosophy in many ways, not that it's unix... - Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Which is what this thread is about. - Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. JS has wonderful stream support, and it's used everywhere in many tools. This is probably where JS is the weakest out of these. - Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. I mean, if JS isn't this taken to the extreme, i don't know what is... - Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them. This also describes JS to a T. Tons and tons of tools, each often only usable by a small number of people in niche situations. Now i'm not saying that JS is as well designed as unix, i'm not saying that it's exactly the same as unix, i'm not saying that Unix doesn't do things better, or that JS doesn't have it's warts. I'm just saying that it's the "unix philosophy" taken to the extreme. It might not be good, it might not last, but it's working out pretty well for many people right now.
GFK_of_xmaspast 10y ago
> 50 versions of the same library installed locally Are you seriously telling me you've never had a linker (static or dynamic) choose the wrong library?