`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.
* 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.
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).
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).
`npm install stylelint` is about as easy as it gets. copying a binary requires you to put it somewhere, make sure your path is setup correctly, find a way to automatically install it (or put it in the repo causing the size of the repo to bloat), and ensure you are downloading the right version for each platform.
And you still didn't address the other issues. How do you know when it has an update, or a security update! NPM warns you if the author deprecates a package version with big yellow warnings when you do something letting you know it's unsupported and has security issues. A binary won't do that.
And then you still have the issue of being unable to modify the code, or even see the code on your system.
And "much better code" is subjective as hell! Go sucks to work with and read for some because it's a bit verbose, especially when dealing with errors and some of the hoops that have to be jumped through to handle or make generic functions. Rust is a HUGE language IMO, I've never used it professionally, but I've been trying to learn it and every single time I see a rust codebase I'm looking up new syntax or some other feature I didn't know about. That's not to say those are 2 bad languages, but that all languages have their downsides. JS is no different, but again when your target audience is 99% devs that use JS on a daily basis, other languages, no matter how easy to understand and use, are going to be harder to work with for them.
I'd love to see more diversity in this area, but if you are telling me to "download and run this binary" as the install method, it's probably not going to be included in an app that I manage, because there's too much extra work that has to be handled, like installing it automatically on the CI server, installing it locally for devs, keeping it up to date, checking it for security issues or problems (if the dev even reports them), and a lot more.
While I wouldn't mind seeing more libraries as wasm for use with node in npm, I don't think the case is really made to have to have even broader tooling to use it alone. I mean, I still don't get why Python hasn't been displaced in Node.
I'm not sure how your system is setup, but most of us already have npm installed and using a package manager is about as simple as it gets to distribute tools. Since it's on npm you don't have to worry about apt, brew, or yum distributions. Just the one that is already installed on everyone's machine who will probably be using this, regardless of stack or OS.
Your other 2 points are moot. You don't get to pick the tools of other projects.
The majority of projects that would use this already use NPM to version their other tools/linters/formatters like eslint and prettier. So now this one tool doesn't integrate with their tooling. For very little upside beyond appeasing a few people on HN.
When you build something, you have to think about more than just your idea of absolute technical superiority. Distribution and toolchain integration and an understanding of your end-users are just as important. Also, would they have the same plugin ecosystem if they hadn't used NPM nor Javascript? https://stylelint.io/user-guide/plugins/
I do think there’s an interesting path here though, and that’s writing said tooling in a language like Rust, but distributing it in an npm package and have it pre-compiled as webassembly. It still feels native to JS people, you don’t have to deal with cross-platform issues, but you gain static typing and speed. There are other aspects of it too, like more consistent performance, and lower memory usage...
Interesting times!
I'd love to see more diversity in languages on NPM. Things written in Go but compiled and distributed as binaries over NPM (maybe with a small JS wrapper), or things written in Rust but compiled to wasm and distributed over NPM.
If the compilers in those other languages get a bit better at outputting WASM or JS, we get closer to the idea of being able to really use the best language/tool for the job, then cobble them all together near the end to make one truly great product where each part is written in a language which is best suited to the sub-task it's doing!
Having the wasm versions in npm could be really useful.
It was then reimplemented in C and released as Libsass for a significant performance gain.
Libsass's main "claim to fame" is that just about all languages (including Javascript on the backend) can interop with C/C++ pretty effortlessly. The rewrite was more about enabling more and more users to use the languages and package managers they are used to rather than about speed (especially since the Dart SASS implementation is quite often FASTER than the libsass version!) Take a look at the Sass perf benchmarks below for more info:
https://github.com/sass/dart-sass/blob/master/perf.md
Although keep in mind that a lot of the performance benefits go away when you run Dart Sass via javascript compilation in regular node. But IMO that gives you a lot of choice. You can get the best performance by installing the Dart toolchain and running it "natively" on dart, or you can run it via node for "okay" speed in most cases, or you can deal with native compilation via C/C++ and libsass for a mix of both. It's a nice setup they have going on over there!
My point is that the performance benefit of implementing a web UI build tool in a compiled language is not always insignificant.
And as you conceded in another comment in the thread, you can use npm to distribute pre-compiled binaries, so I don’t think the “it’s too cumbersome to download a binary” argument holds much water either.
One of the really good things sass did with the rewrite in dart was make the default installable package include the dart VM along with it. So the install process is almost identical to any other JS package, which is why IMO they did such an amazing job with it
I'm not affiliated with the project (I just dabbled briefly), but I would guess writing a language like Purescript in Haskell would probably be easier than writing it in Javascript.
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.
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.
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.
Not saying that's right or optimal, of course.
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.
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.
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.
Editors like Brackets are built from the ground up using JavaScript. Any plugin built for it is made using JS.
The front-end build system / tool-chain that I use has been coded by a handful of front-end developers and uses Gulp (previously Grunt but we migrated) as its base. The repository has 620 commits so far and does everything from minifying and bundling code to generating the 10+ of favicon images needed on modern projects.
Even big names such as Webpack are JavaScript based and maintained by JavaScript developers.
What was Gulp’s big idea? Streaming? Congratulations, your operating system has had this facility for over 40 years.
Some of the Gulp plugins are a hoot too. You can download and install a plugin to help you copy files. Our operating systems already know how to copy files. This is pretty basic stuff.
And Grunt? Grunt doesn’t even have streaming. All transformations are done with disk IO as an intermediary. No surprise then that it’s very slow.
Minifying code? Do you use jsmin by any chance? Because that’s written in C.
Generating your favicon images? Is it ImageMagick you use? Because that’s also written in C.
Does Brackets do anything novel? Does it outperform editors written in compiled programming languages? I would be extremely surprised if it did.
Then you declared that this is useless because no developers actually work on the products they will use for development. I responded by giving your examples where this happens.
Now, you are claiming that those tools are pointless because they use libraries in other languages or because there are alternatives in other languages.
What is your point exactly?
> First you claimed that having a toolset built using familiar technologies was useful to nobody (0% of developers!)
That's not exactly what I wrote.
> Then you declared that this is useless because no developers actually work on the products they will use for development. I responded by giving your examples where this happens.
Wrong again. A very small subset of developers actually build their own times. Writing a Gulp configuration is not an example of building your own tool. That would be an example of using a tool, and writing your own configuration for that tool.
This is the core of my argument. If you can't grasp this, then we can't get anywhere.
> Now, you are claiming that those tools are pointless because they use libraries in other languages or because there are alternatives in other languages.
That isn't what I am claiming. I am claiming that most web developers do not build their own tools. Writing some glue code (shell script, Makefile, Gulpfile, whatever), which calls out to another tool (like the aforementioned tools written in C), is not an example of writing your own tool.
Do you care what language your linter is written in? No. You do not. You only care about its API. You only care that it's easy enough to use from JavaScript. If you can write `gulp do-the-linting`, and it lints your JavaScript, you don't actually care what language the linting engine was implemented in. Almost — again almost — 0% of web developers care about that.
I have the impression that this is not an issue coming from me not being able to grasp this concept but from your inability to communicate efficiently without using a condescending tone.
I do all my CI/CD orchestration around node and JavaScript, even for applications/services not using JS.
React, material-ui, redux, react-jss etc, all JavaScript.
Express, cocket.io, hapi, etc... all JavaScript.
I'm not sure where you are coming from here. As to your reference of Make... you don't have to write npm before you can use npm... the same argument is true of JS tooling.
As to your shell scripts, do they (including your make configuration) run in Windows, Linux and Mac without issue? My Node/JS scripts do.
I also have never said that no developer tools are implemented in JavaScript.
If you like, feel free to tell me what proportion (as a percentage) of web developers in the world are actively contributing to the JavaScript projects you listed.
Not using.
Actually making.
> you don't have to write npm before you can use npm...
That is exactly my point.
Given that you don’t have to write npm before you can use it, it shouldn’t matter to you what language it is implemented in.
I feel someone is going to have to take over from me at this point, because I’m not sure how else to explain this very simple, uncontroversial point.
> Actually making.
I've read all your comments in this thread and I've come to the conclusion that your opinion of a "web developer" is about a decade out of date.
It's not.
Every web developer or frontend engineer I've ever worked with in the last decade has been a software engineer in every sense of the word. Focusing on web based applications or architecture is just what they have chosen or fallen in to.
> This isn’t a dig at web developers either (like I said, I am one)
Do you think the majority of people using make contribute to writing make?
Almost 0% of web developers.
As I have said. Repeatedly.
For every one person building one of these tools, there’s at least 100 developers using it, not actually contributing to it.
Not a difficult concept to grasp.
> Sure, many more will use than make, but that's true of EVERY tool that is made.
Yes. I know. Obviously
> Do you think the majority of people using make contribute to writing make?
Obviously not. And this further proves my point. JavaScript developers can use Make to build their JavaScript. It doesn’t matter what language Make is implemented in.
Are you following yet?
TFA chose to write a tool in THEIR platform of choice. If you want something different, write it your fucking self.
npm happens to run on windows, linux and mac with minimal problems.
Also, the tools in TFA are something someone spent time on creating, that serves a purpose that works within the tooling that most of the people that would use the tool already use... and all you've done is poop on that because it doesn't fit your preconceived notions of what the "right" language/platform is.
To clarify: I’ve been working with JavaScript for the better part of a decade. That’s not the only language I work with though, and specifically which languages I’m proficient in shouldn’t at all detract from the point I was making.
I don’t appreciate you telling me what I think either.
VS Code works better than any IDE with similar or more features that I've tried, including those in compiled or preferred languages. Most other Electron apps are good enough. Yeah, they use a little more ram.. I've got 32GB on my desktop at home... I'd rather use 1-2gb of ram for half a dozen apps than to not have said app.
I don't know what you think, but I, personally feel that you are presenting like a pompous asshole who wants to shit all over useful things that people make because it doesn't fit your arbitrary opinion on what is the right language to use. If you want something better, in your opinion, you make it, and watch people shit all over it because it can't match the features of a tool built in a lesser language.
As to Atom, I didn't care for it... VS Code is a better example of what CAN be done with electron in terms of decent performance. Yeah, it's slower to load than sublime or notepad, but I typically open against a project directory and leave it open for a considerable time.
[1]: https://raw.githubusercontent.com/chrisfinazzo/blog/master/g...
#!/usr/bin/bash
set -e
git push origin master
rsync -crz \
--exclude-from='rsync-exclude.txt' \
--delete _site/ \
cfinazzo1@chrisfinazzo.com:/home/cfinazzo1/chrisfinazzo.com
Make would be something similar. In fact your entire Gulpfile in Make would look like this:
.PHONY: doctor build serve deploy
doctor:
bundle exec jekyll doctor
build: doctor
time bundle exec jekyll build --incremental
serve: doctor
time bundle exec jekyll serve --incremental
deploy:
git push origin master
rsync -crz \
--exclude-from='rsync-exclude.txt' \
--delete _site/ cfinazzo1@chrisfinazzo.com:/home/cfinazzo1/chrisfinazzo.comOr even better, compile into a wasm binary.
[1] https://github.com/nexe/nexe [2] https://github.com/zeit/pkg
Most people don't respond well to willful ignorance or excessive arrogance.