8 ms·

This is neat, but: `npm install stylelint --save-dev` I really wish people wouldn't write cli tools in Javascript. Npm is a disaster and will pollute my syste

This is neat, but: `npm install stylelint --save-dev` I really wish people wouldn't write cli tools in Javascript. Npm is a disaster and will pollute my system with all kinds of dependency libraries if I run the above command. It would be great to see more tools like this written in Go, Rust or something else that compiles to a static binary.

Chernobog 8y ago
Afaik with that command you will not pollute the rest of the system, since there is no global flag. It will end up in node modules/.bin and can be executed with npm scripts.
- malvosenior 8y ago
  I still find that pretty tacky. Is there a reason someone would build something like this in JS instead of a more suitable language? I get that front-end developers probably know JS best from a user perspective it's a bad language choice just from the distribution alone.
  - austinjp 8y ago
    I kinda agree about JS CLI tools. However, I'm guessing the target market is JS-led front-end developers. Installing via npm makes it simpler to drop in to a toolchain that's already oriented around npm. Not saying that's right or optimal, of course.
    - tracker1 8y ago
      Not to mention that JS isn't an inherently bad language in the first place. Which is an absurd presumption. Most languages have some nice, good and really ugly parts in practice. Modern JS is pretty nice to work with, and often I can get far more done with it far faster than with anything else I would choose. Node + NPM are second to none in terms of productivity IMHO. I've used and worked with other languages and tools and find that JS tooling is just plain less friction most of the time. If I had to switch contexts to 3-4 other languages day to day again, I'd hate it... I remember it being so bad working with 3-4 languages every day that It'd sometimes take me 2-3 minutes just to be able to actually listen to a question by a peer and be able to answer. It can not be underestimated. Node tooling is probably not the best at anything... that said, it's good enough for almost everything.
  - StellarTabi 8y ago
    Unfortunately, we live in a free society where I need to base all my actions on keeping myself employable. This means I'll spend 4 hours writing a small tool in JS instead of 1000 hours trying to learn semantic modern c/c++/rust/golang. That's 990 hours I could spend making more tools, learning new technologies that employers would find relevant on my resume, or spending time with friends and family.
  - noidea_ 8y ago
    No it's not. The problem is you're grossly misinformed about languages in general (a more suitable language? wtf?). There's nothing wrong with NPM and distributing packages used by the majority of the ecosystem. And for all of NPM's problems, it works literally better than every other garbage package manager. But I suspect your criticism is more because you read some comments about NPM, not that you know what you're talking about.
- mhd 8y ago
  Or "npx".
Wintamute 8y ago
The above command just installs a folder with plain JS files in it, I'm not sure what system pollution you're talking about. It's very convenient for web developers to use cli tools written using the same languages and stack as their end products. I'm guessing you're not a web developer ...
- yakshaving_jgt 8y ago
  I’m a “web developer”, and I can say with a good deal of confidence that almost 0% of web developers have any special utility in any of their tools being implemented in a language they’re familiar with.
  - Raphmedia 8y ago
    Anyone who actually takes the time to lint their styles will likely have a customized build system. This is not aimed at the person with no experiences who make static websites using notepad in their free time. This is aimed at people who already have their hands deep in the front-end ecosystem.
    - yakshaving_jgt 8y ago
      Yes, I’m well aware of that. But web developers don’t build their own tools. They don’t build their own text editors. They don’t write their own operating systems or web browsers. They don’t need to write their own linters. Sure, they might enjoy writing their configuration of those tools in JavaScript (grunt, gulp, webpack, etc), but that’s not the same as writing your own tool. If the analogy isn’t already obvious, I’m saying that while a non-trivial UI project’s development pipeline may include a build tool, e.g., Make, you don’t have to implement Make before you can use Make. This isn’t a dig at web developers either (like I said, I am one). I write shell scripts, and I lint them with Shellcheck. I don’t need to know the language that Shellcheck is implemented in to use or configure it. It could be implemented in Rust, C, Prolog, or even Brainfuck for all I care. I’m guessing the people that downvoted my previous comment misunderstood my point.
hiccuphippo 8y ago
I wonder if CLI tools could be put into a single zipfile with all the dependencies inside and just ran from there. Just like php's phar files. Or even better, compile into a wasm binary.
- thangngoc89 8y ago
  1. Yes. If your CLI tool is written entirely in JS, you can even bundle all files into a single file and ship the JS file. With native dependencies, you need to use other solutions. 2. Compile into a wasm binary is not possible because JS is an dynamically typed language. No type at compilation time
- folkrav 8y ago
  There are things like nexe[1] and pkg[2] but the resulting executables end up pretty bloated (30+ MBs for a simple hello world, cause they all end up bundling Node in some way with every executable). nexe doesn't support native Node modules either, IIRC. [1] https://github.com/nexe/nexe https://github.com/nexe/nexe [2] https://github.com/zeit/pkg https://github.com/zeit/pkg
- tracker1 8y ago
  And when you need to support Linux, Windows and Mac for developers?
  - hiccuphippo 8y ago
    They still need to install Node. This is just a zip file that Node would run that contains all the dependencies inside the zip.
    - tracker1 8y ago
      So, you need to include the linux, windows and mac versions in your zip file at the very least for binary dependencies?
Klathmon 8y ago
I'm not so sure that'd be a good idea. A few questions: 1. what benefits would a statically compiled binary provide? Would it be significantly faster? Would it be easier to manage? Would it be easier to modify? I'd guess the answers to those last 3 would be "yes, but not significantly so", "no" and "no" respectively, but that is a complete guess. 2. Would it be cross-platform? I work in windows and macos, our CI server uses linux. Would your alternate languages/methods work across all those platforms? if not it's almost a non-starter, because we aren't going to require our devs and CI system change entirely to accommodate one smaller package. 3. how would it be installed and kept up to date? NPM has the tooling built up for managing this. We have a bot that can ping when new versions come out after a delay, we can see install numbers and gauge when it's safe to install vs when it's brand new and still might be buggy or have un-found issues. We have CLI tooling that can parse the package.json and determine what is out of date, and in one command can update many of them and have the tests run to ensure there aren't any major breakages. Would your method work on all platforms? How would it differ per platform? Can I install it without having to install and setup the developer tools for Go and Rust? NPM isn't perfect, but it does a LOT of things right. Being able to `npm install` something, have it go to a local folder, then have it just run on all platforms is one that it does VERY right in my opinion. It's installed alongside node.js, and the install process is quick and painless in 99% of cases. And considering this tool is probably fast enough as-is in javascript right now, I don't think there would be any significant gains by rewriting it in some other compiled language to offset the downsides (like not being able to easily inspect and modify the code that was installed, which I have done on many occasions to find and fix bugs in 3rd party libraries).
- malvosenior 8y ago
  If it was written in a compiled language you could just copy the binary over to your system. You wouldn't even have to mess around installing the language or build tools. Golang and Rust are both very cross platform and compile to Mac/Linux/Windows natively. The main benefits to using a more modern language would be: 1. Easier distribution (like I said, just copy a binary) 2. Better performance (but like you said, often doesn't matter) 3. Much better code (subjective, but static typing offers real benefit as does having a very nice standard library).
monkeynotes 8y ago
* on the command line * in your text editor, for example in VS Code * in for your build tool, for example in webpack * via the Node.js API * as a PostCSS plugin ^ If I was trying to meet compatibility with the above requirements I'd probably pick JS too. It's easy to complain about npm but the fact is it get so much done every day. I don't want to be compiling binaries and all the compatibility crap that goes on there. I have no problem with well written JS or Typescript. Yes NPM dependency can be a bit crazy, but it doesn't pollute your system. Using nvm everything is contained in a modules directory. I can literally delete that folder and be back to square one in two seconds flat. Compiling binaries, well, that's where I feel like you end up pulling your hair out. I have to compile binaries for a certain version of a capybarra gem, to do that I had to roll back x-code. Never had to do anything like that for a straight forward npm.
Raphmedia 8y ago
When I worked at a web agency as a dedicated front-end developer, the projects would use any language from .NET, PHP, Ruby, etc. I don't want to depend on the back-end of the project in my front-end stack. All of my work in the front-end ecosystem is made using JS+CSS. Why would I want to install Go or Ruby to build those? Running JS to manage my JS and CSS makes more sense... One big bonus being that I can actually lift the hood and tweak my build system because it uses the same language as the one it will be parsing.
- Klathmon 8y ago
  You just reminded me of a really good point. We already have "previous examples" of people trying to make CSS tooling in another language! sass was written in ruby originally, and it sucked so much to manage and work with for many devs that they literally re-wrote the ENTIRE thing in Dart so they could gain the benefits of the JS ecosystem (like npm)! It isn't a compiled language, but it is an example of someone having done this at least once, and ending up regretting it to the point that they spent multiple years rewriting it in a language that compiles to JS and deprecated the ruby version.
  - Raphmedia 8y ago
    Indeed, requiring Ruby to build SCSS files used to be a pain. Every other part of our toolchain was done via NPM. You could install all of it in seconds via one command... and then people had to hunt the correct and compatible Ruby binaries for their system. Our .NET developers on Windows hated this. "Why do I need to install Ruby to build your front-end?!" Dart Sass was a godsend.
z3t4 8y ago
With a interpreted language you do not have to worry about losing the source code. Static binaries can also be large.
jannes 8y ago
I don't understand why this comment is so downvoted. It's a very valid point.
- tracker1 8y ago
  Mainly because it's a bit condescending, elitist and snobby. There's very little reason for a tool surrounding front end development to not be built/deployed with the vast majority of tooling for front end development outside of ignorance, arrogance or both. Most people don't respond well to willful ignorance or excessive arrogance.
- yakshaving_jgt 8y ago
  Because some developers feel insecure about their level of skill. You’ll spot a few of those in this thread.
- albedoa 8y ago
  For one thing, a significant portion of it is completely wrong, which makes the sibling comment by yakshaving_jgt particularly rich.

Chernobog 8y ago

Afaik with that command you will not pollute the rest of the system, since there is no global flag. It will end up in node modules/.bin and can be executed with npm scripts.

malvosenior 8y ago
I still find that pretty tacky. Is there a reason someone would build something like this in JS instead of a more suitable language? I get that front-end developers probably know JS best from a user perspective it's a bad language choice just from the distribution alone.
- austinjp 8y ago
  I kinda agree about JS CLI tools. However, I'm guessing the target market is JS-led front-end developers. Installing via npm makes it simpler to drop in to a toolchain that's already oriented around npm. Not saying that's right or optimal, of course.
  - tracker1 8y ago
    Not to mention that JS isn't an inherently bad language in the first place. Which is an absurd presumption. Most languages have some nice, good and really ugly parts in practice. Modern JS is pretty nice to work with, and often I can get far more done with it far faster than with anything else I would choose. Node + NPM are second to none in terms of productivity IMHO. I've used and worked with other languages and tools and find that JS tooling is just plain less friction most of the time. If I had to switch contexts to 3-4 other languages day to day again, I'd hate it... I remember it being so bad working with 3-4 languages every day that It'd sometimes take me 2-3 minutes just to be able to actually listen to a question by a peer and be able to answer. It can not be underestimated. Node tooling is probably not the best at anything... that said, it's good enough for almost everything.
- StellarTabi 8y ago
  Unfortunately, we live in a free society where I need to base all my actions on keeping myself employable. This means I'll spend 4 hours writing a small tool in JS instead of 1000 hours trying to learn semantic modern c/c++/rust/golang. That's 990 hours I could spend making more tools, learning new technologies that employers would find relevant on my resume, or spending time with friends and family.
- noidea_ 8y ago
  No it's not. The problem is you're grossly misinformed about languages in general (a more suitable language? wtf?). There's nothing wrong with NPM and distributing packages used by the majority of the ecosystem. And for all of NPM's problems, it works literally better than every other garbage package manager. But I suspect your criticism is more because you read some comments about NPM, not that you know what you're talking about.
mhd 8y ago
Or "npx".

Wintamute 8y ago

The above command just installs a folder with plain JS files in it, I'm not sure what system pollution you're talking about. It's very convenient for web developers to use cli tools written using the same languages and stack as their end products. I'm guessing you're not a web developer ...

yakshaving_jgt 8y ago
I’m a “web developer”, and I can say with a good deal of confidence that almost 0% of web developers have any special utility in any of their tools being implemented in a language they’re familiar with.
- Raphmedia 8y ago
  Anyone who actually takes the time to lint their styles will likely have a customized build system. This is not aimed at the person with no experiences who make static websites using notepad in their free time. This is aimed at people who already have their hands deep in the front-end ecosystem.
  - yakshaving_jgt 8y ago
    Yes, I’m well aware of that. But web developers don’t build their own tools. They don’t build their own text editors. They don’t write their own operating systems or web browsers. They don’t need to write their own linters. Sure, they might enjoy writing their configuration of those tools in JavaScript (grunt, gulp, webpack, etc), but that’s not the same as writing your own tool. If the analogy isn’t already obvious, I’m saying that while a non-trivial UI project’s development pipeline may include a build tool, e.g., Make, you don’t have to implement Make before you can use Make. This isn’t a dig at web developers either (like I said, I am one). I write shell scripts, and I lint them with Shellcheck. I don’t need to know the language that Shellcheck is implemented in to use or configure it. It could be implemented in Rust, C, Prolog, or even Brainfuck for all I care. I’m guessing the people that downvoted my previous comment misunderstood my point.

hiccuphippo 8y ago

I wonder if CLI tools could be put into a single zipfile with all the dependencies inside and just ran from there. Just like php's phar files. Or even better, compile into a wasm binary.

thangngoc89 8y ago
1. Yes. If your CLI tool is written entirely in JS, you can even bundle all files into a single file and ship the JS file. With native dependencies, you need to use other solutions. 2. Compile into a wasm binary is not possible because JS is an dynamically typed language. No type at compilation time
folkrav 8y ago
There are things like nexe[1] and pkg[2] but the resulting executables end up pretty bloated (30+ MBs for a simple hello world, cause they all end up bundling Node in some way with every executable). nexe doesn't support native Node modules either, IIRC. [1] https://github.com/nexe/nexe https://github.com/nexe/nexe [2] https://github.com/zeit/pkg https://github.com/zeit/pkg
tracker1 8y ago
And when you need to support Linux, Windows and Mac for developers?
- hiccuphippo 8y ago
  They still need to install Node. This is just a zip file that Node would run that contains all the dependencies inside the zip.
  - tracker1 8y ago
    So, you need to include the linux, windows and mac versions in your zip file at the very least for binary dependencies?

Klathmon 8y ago

I'm not so sure that'd be a good idea. A few questions: 1. what benefits would a statically compiled binary provide? Would it be significantly faster? Would it be easier to manage? Would it be easier to modify? I'd guess the answers to those last 3 would be "yes, but not significantly so", "no" and "no" respectively, but that is a complete guess. 2. Would it be cross-platform? I work in windows and macos, our CI server uses linux. Would your alternate languages/methods work across all those platforms? if not it's almost a non-starter, because we aren't going to require our devs and CI system change entirely to accommodate one smaller package. 3. how would it be installed and kept up to date? NPM has the tooling built up for managing this. We have a bot that can ping when new versions come out after a delay, we can see install numbers and gauge when it's safe to install vs when it's brand new and still might be buggy or have un-found issues. We have CLI tooling that can parse the package.json and determine what is out of date, and in one command can update many of them and have the tests run to ensure there aren't any major breakages. Would your method work on all platforms? How would it differ per platform? Can I install it without having to install and setup the developer tools for Go and Rust? NPM isn't perfect, but it does a LOT of things right. Being able to `npm install` something, have it go to a local folder, then have it just run on all platforms is one that it does VERY right in my opinion. It's installed alongside node.js, and the install process is quick and painless in 99% of cases. And considering this tool is probably fast enough as-is in javascript right now, I don't think there would be any significant gains by rewriting it in some other compiled language to offset the downsides (like not being able to easily inspect and modify the code that was installed, which I have done on many occasions to find and fix bugs in 3rd party libraries).

malvosenior 8y ago
If it was written in a compiled language you could just copy the binary over to your system. You wouldn't even have to mess around installing the language or build tools. Golang and Rust are both very cross platform and compile to Mac/Linux/Windows natively. The main benefits to using a more modern language would be: 1. Easier distribution (like I said, just copy a binary) 2. Better performance (but like you said, often doesn't matter) 3. Much better code (subjective, but static typing offers real benefit as does having a very nice standard library).

monkeynotes 8y ago

* on the command line * in your text editor, for example in VS Code * in for your build tool, for example in webpack * via the Node.js API * as a PostCSS plugin ^ If I was trying to meet compatibility with the above requirements I'd probably pick JS too. It's easy to complain about npm but the fact is it get so much done every day. I don't want to be compiling binaries and all the compatibility crap that goes on there. I have no problem with well written JS or Typescript. Yes NPM dependency can be a bit crazy, but it doesn't pollute your system. Using nvm everything is contained in a modules directory. I can literally delete that folder and be back to square one in two seconds flat. Compiling binaries, well, that's where I feel like you end up pulling your hair out. I have to compile binaries for a certain version of a capybarra gem, to do that I had to roll back x-code. Never had to do anything like that for a straight forward npm.

Raphmedia 8y ago

When I worked at a web agency as a dedicated front-end developer, the projects would use any language from .NET, PHP, Ruby, etc. I don't want to depend on the back-end of the project in my front-end stack. All of my work in the front-end ecosystem is made using JS+CSS. Why would I want to install Go or Ruby to build those? Running JS to manage my JS and CSS makes more sense... One big bonus being that I can actually lift the hood and tweak my build system because it uses the same language as the one it will be parsing.

Klathmon 8y ago
You just reminded me of a really good point. We already have "previous examples" of people trying to make CSS tooling in another language! sass was written in ruby originally, and it sucked so much to manage and work with for many devs that they literally re-wrote the ENTIRE thing in Dart so they could gain the benefits of the JS ecosystem (like npm)! It isn't a compiled language, but it is an example of someone having done this at least once, and ending up regretting it to the point that they spent multiple years rewriting it in a language that compiles to JS and deprecated the ruby version.
- Raphmedia 8y ago
  Indeed, requiring Ruby to build SCSS files used to be a pain. Every other part of our toolchain was done via NPM. You could install all of it in seconds via one command... and then people had to hunt the correct and compatible Ruby binaries for their system. Our .NET developers on Windows hated this. "Why do I need to install Ruby to build your front-end?!" Dart Sass was a godsend.

z3t4 8y ago

With a interpreted language you do not have to worry about losing the source code. Static binaries can also be large.

jannes 8y ago

I don't understand why this comment is so downvoted. It's a very valid point.

tracker1 8y ago
Mainly because it's a bit condescending, elitist and snobby. There's very little reason for a tool surrounding front end development to not be built/deployed with the vast majority of tooling for front end development outside of ignorance, arrogance or both. Most people don't respond well to willful ignorance or excessive arrogance.
yakshaving_jgt 8y ago
Because some developers feel insecure about their level of skill. You’ll spot a few of those in this thread.
albedoa 8y ago
For one thing, a significant portion of it is completely wrong, which makes the sibling comment by yakshaving_jgt particularly rich.