Comment by Klathmon | Hacker News Reader

Comment by Klathmon | Hacker News Reader

Parent Full thread

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

I think these are good questions, and I agree with them regarding the downsides of binaries.

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!

And that's why I tried to avoid saying it's a bad idea in general.

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!

Agreed on WebAssembly... I'm thinking/hoping that a number of binary packages will be migrated to, or at least tested via webassembly. There are some modules in C that are impossible via webassembly, but a great number of them are.

Having the wasm versions in npm could be really useful.

I’d like to point out here that Sass was originally a Ruby gem.

It was then reimplemented in C and released as Libsass for a significant performance gain.

But it was again rewritten in Dart and the Dart version is now the reference implementation. And they did that because for a lot of Sass users, working with Ruby sucked, simply because they didn't have the tooling and knowledge built up to handle it correctly.

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!

I’m not really disputing any of that.

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.

We are on the same page! If the binaries are distributed over npm and work well in the npm ecosystem, them I'm all for it! My only reservations are about blindly writing things in compiled languages, or not using package managers at all because it's easier to distribute, which I don't think it is.

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

The Purescript compiler is built in Haskell, and they use NPM to distribute the binaries. npm i -g purescript fetches a platform-appropriate binary and installs 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.

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

But when 99% of your target audience (in this case JS and web developers) already have the runtime installed, then "just copy a binary" isn't easier, it's harder.

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

The just copy it argument doesn't really fly as far as Linux, Windows, Mac too. Not to mention incompatible versions of said OSes alone, not to mention others.

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.

> 1. Easier distribution (like I said, just copy a binary)

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.

Having to copy a binary is a downgrade. NPM is an xplat distribution platform.

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/

Reply on news.ycombinator.com