Comparison with other node version manager

[siutsin]

Looks promising 👍. Any comparison to the existing node version manager like nvm and n?

[Schniz]

Hi! I used to work with nvm, but decided it is too slow for my use. fnm is focused on speed and performance, and therefore much faster (about ~40x for initialization + switching versions)

I'm not sure about n but I'm gonna leave this issue open until we'll have a benchmark for everything (maybe even in CI?)

[bompus]

I'd love to see a benchmark that includes n. It's my current go-to, and while I love trying new things... you know how that goes. I believe that n is actually quite fast, so very curious how fnm compares.

[vcfvct]

Yes. Would also like to see some comparison. Currently using the fish-nvm, whose previous name also happened to be 'fnm'(fish node manager)😂

[Schniz]

That would be great. I hope I'll have the time to do some scientific benchmarks soon. I want to merge the multi-shell feature first 😄

[gaui]

At least it's not a bash alias like nvm :smile:

[Schniz]

At least it's not a bash alias like nvm 😄

Let's not bash nvm...

😉

but really, nvm's a great product 😄

[gaui]

Hehe yes indeed, but getting it to work inside a Docker container can be tricky. But I'm not bashing (pun intended).

[ljharb]

@gaui theres a dockerfile in nvm’s repo, so it shouldn’t be difficult.

[paambaati]

I’ve worked with nvm and n before, and had problems getting them to work correctly, especially with automated scripts — they’re usually executed by a CI/CD system that doesn’t use a shell by default.

@Schniz Does fnm work well without a shell?

[Schniz]

Yes:

• fnm is executed as a binary, compared to a bash function in nvm. So it doesn't need a shell to install or replace node versions
• installations are always stored in $FNM_DIR which you can set on CI. All environment variables are public API and you can see them in fnm --help. These are the environment variables that fnm env spits out.
• if you run in docker and automated scripts won't clash, setting PATH=$HOME/.fnm/current is all you need (more on that in the next comment). We probably need to also provide fnm exec or make fnm env get more arguments so it'll run your command with the environment variables from fnm env to make it as seamless as possible.

If you need any help setting up your CI/automated scripts, let me know. I'd be happy to help

[Schniz]

When fnm is not being used with the --multi flag, it stores a symlink to the current version in ~/.fnm/current. I'd rather that to stay an implementation detail, this is why I want to provide a fnm exec so fnm exec node --version will always run the correct node version.

[paambaati]

@Schniz Makes sense! Also I’d rather not even use ~ anywhere in my scripts.

Quick questions —

1. Is fnm exec on the roadmap? Is there a branch or a PR I can look at to get started with contributing?
2. Is the fnm output directory configurable? Or rather, can I get the currently installed Node to go to a globally-available-inPATH directory like /usr/local/bin?

[Schniz]

Also I’d rather not even use ~ anywhere in my scripts.

Makes sense 😄 it's not easy on the eyes

1. Is fnm exec on the roadmap? Is there a branch or a PR I can look at to get started with contributing?

Frankly, we don't have a roadmap therefore it's not really planned. 😅 but I thought about doing so because I thought I needed it for gpkg, my global node package manager.

I might have some time in the near future to implement it in the near future. However, There are open issues which I'd be happy to accept PRs for, and happy to provide any mentoring needed to make them a reality. If you want to try, hop in the Reason discord and chat with me there! (or you'll also find @tatchi which may help as well 😜 ).

2. Is the fnm output directory configurable? Or rather, can I get the currently installed Node to go to a globally-available-inPATH directory like /usr/local/bin?

It is configurable by altering $FNM_DIR but it won't work the way you expect: we store all the versions in a custom directory structure.

For your situation, I'd suggest:

1. Changing the $PATH because it is safer than anything else
2. Symlinking ~/.fnm/current/bin/node into /usr/local/bin/node. But again, I wouldn't do it.

[paambaati]

@Schniz Whoa, gpkg looks great!

Symlinking ~/.fnm/current/bin/node into /usr/local/bin/node. But again, I wouldn't do it.

Can you expand on this? Why is this a bad idea?

[Schniz]

Can you expand on this? Why is this a bad idea?

I love to avoid mixing my own binaries from the operating system's one.

I already started a POC with #194 :)

[Sparkenstein]

Just saw this repo in trending, kudos to the authors for a great tool. you mentioned that fnm targets speed and performance as primary goals. I personally use NVS myself. I was wondering where does speed come into picture when switching versions. How did you reach to the number ~40x faster. is it just because it's written in rust? I am not really sure what happens in background in any of these version managers (nvs, n and fnm) :P, the nvs tool I mentioned just changes the link in bashrc/zshrc

[Schniz]

Hey @Sparkenstein! Happy to see you here. I'll answer one question at a time 😄

is it just because it's written in rust?

No no, I'm not that kind of boy. The ~40x faster was for Reason and I tested it with time use_with_nvm.sh vs time use_with_fnm.sh. For Rust, it looks like it's about 50 times faster 😄 check out the latest comparison I had. It was a GitHub action that ran for each commit in the archived repo:

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
basic/nvm	1441.5 ± 51.0	1354.2	1625.7	214.44 ± 25.63
basic/fnm_reason	98.1 ± 10.1	87.6	141.2	14.60 ± 2.24
basic/fnm_latest_master	6.7 ± 0.8	5.6	13.0	1.00
basic/fnm	6.7 ± 0.8	5.7	14.7	1.00 ± 0.16

The script is here: https://github.com/Schniz/fnm.rs/blob/master/benchmarks/run

---

I personally use NVS myself.

NVS looks like is running on Node.js — I wanted to write fnm using TypeScript before using Reason. And the reason why I didn't was because Node.js used to have a 200ms boot time penalty. Now it looks like it's about 50ms but I think that once you start adding more libraries it can get slower.

200ms for a "hello" world is unacceptable to me. Initializing nvm was something that took more than one second (if not 2 or 4 seconds) and I didn't want to write a tool that starts off by being slow.

---

the nvs tool I mentioned just changes the link in bashrc/zshrc

All fnm does is changing symlinks too. And installing Node.js versions. Other than that... nothing!

---

I am not really sure what happens in background in any of these version managers (nvs, n and fnm) :P

That's cool and as long as you are happy with the tool you use, you don't need to investigate. From what I know:

• nvm is written in Bash as a function, so it can alter your environment variables and is full of features. This is what I used previous to fnm. It does not support Windows or Fish shell (or any shell that isn't POSIX compliant)
• n is written in Bash as well and it is like a stripped version of nvm
• fnm is another take on nvm but is a binary so it can run everywhere. It modifies the file system and not your current environment and all the logic is very contained in the binary: when you run eval "$(fnm env)" you practically set up your environment and the next time you will use fnm is if you call it explicitly. No magic in your shell. No way of slowing down your startup time.

---

I really like the fact there are lots of tools that do the same job. I wonder what is the difference too. We all should write blog posts explaining how we solved these problems. 😄

I hope it answered!

[ljharb]

@Schniz itd be really helpful to me if you could also run those benchmarks on https://github.com/nvm-sh/nvm/pull/2317 - my hope is that will address the primary slowness in nvm use (calling npm)

[Schniz]

@ljharb Woah! looks great. I'll try benchmarking it too tomorrow!

[thibaudcolas]

Here are up-to-date results using the same methodology as above, comparing nvm 0.38.0 and fnm 1.26.0, both latest as of today. This is on a MBP from 2019 with lots running in the background for what it’s worth.

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
basic/nvm	1751.7 ± 105.7	1605.6	2195.6	49.83 ± 7.35
basic/fnm	35.2 ± 4.7	30.5	60.2	1.00

Test command (otherwise using the same setup as the run script):

 hyperfine \
  --warmup=2 \
  --min-runs=40 \
  --time-unit=millisecond \
  --export-json="./results/basic.json" \
  --export-markdown="./results/basic.md" \
  "basic/nvm" \
  "basic/fnm"

[waldyrious]

Interesting, @thibaudcolas. With the release of 0.37.0, I assumed the speed difference would be much lower between nvm and fnm, but apparently that isn't the case.

[ljharb]

A factor of 214 down to 50 is a pretty ridiculously huge speed increase. That there’s still room to go isn’t surprising - shell scripting isn’t designed for performance. The only thing that matters tho is whether a tool is “fast enough” or not - ie, under the threshold where it bothers people.

@thibaudcolas thanks for running that!

[Schniz]

A factor of 214 down to 50 is a pretty ridiculously huge speed increase.

Kudos for the hard work! Very impressive 😃

[ModischFabrications]

Was about to ask for a comparison, just noticed this issue. Any plans to get a summary into the readme? Looking at the raw statistics like stars or followers would give nvm an (unfair?) advantage, especially for a simple, clueless user like me.

[Schniz]

in short,

• fnm is fast (nvm might catch up, haven't used it since starting fnm)
• fnm supports Windows natively (aka cmd.exe and powershell, not just posix-based shells)
• fnm supports fish shell natively
• fnm supports all the above because it's a binary and not a shell function. this comes with trade-offs. But that's mostly an implementation detail.

I am gonna close this issue because I see no reason to maintain a list that compares this tool to nvm anymore. With almost 10k stars and many organizations using it as the default Node version manager, I don't see a reason to feel like an underdog.

Try fnm -- you can try and use it if it fits your usecases. If you think nvm fits your needs best, use it. We're fortunate to have many flavors of tools in our ecosystem. I personally don't miss using nvm but I understand and respect people who use it as their go to tool. Same for n, and similar tools.

[Schniz]

btw I'm closing this because it's a never-ending issue. Hope y'all understand. If you have a specific question, feel free to open a new issue or hit me on twitter/email/whatever.

[waldyrious]

We're fortunate to have many flavors of tools in our ecosystem.

I think that's precisely why it is helpful to provide information for those surveying the space to be able to make a decision on which one to use.

That said, I think the Features section of the README already neatly summarizes the differences you mentioned above. (In fact, the section could be titled "Why fnm?" to make this more evident.)

[ModischFabrications]

I agree with @waldyrious. Renaming the section, especially with a "in relation to nvm vX.Y" or similar, would have helped me. I don't want to critizise fnm or nvm, I want to offer the perspective of a newcomer, that has never worked with any of them and is clueless about their differences. I'm unaware of the history and who improved on whom, I just want to pick the best/easiest/fastest without having to research forums and blogs. There must be a reason why fnm exists, which is exactly what I would have liked to see.

That said, feel free to ignore. Not my repo, not my choice.

[thibaudcolas]

Personally I’d also welcome seeing some of what’s discussed here featured more prominently in the README. The benchmarks in particular are the kind of information anyone comparing those tools would find interesting. And the README would be a much more obvious place to look for those than past issues. Performance isn’t necessarily a big deciding factor, but with both tools being very similar, might as well pick the fast one. fnm being more interoperable is also an important factor that should be contrasted with how other tools fare.

I don’t think this has to be something that’s high-maintenance – at worst, just a link to this issue ("🚀 Built with speed in mind (see community-provided benchmarks)") would be useful.

---

And on that note here is a new benchmark from my 2019 MBP,

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
basic/nvm	2101.2 ± 86.3	2027.4	2439.9	44.43 ± 3.68
basic/fnm	47.3 ± 3.4	45.2	66.7	1.00

This is with the latest version of both. nvm v0.39.2, fnm v1.32.0. Same test setup as the last. TL;DR; either my computer got slower or both tools did. Important number is 44.43 – fnm now appears to be "only" 44 times faster.

[Schniz]

@thibaudcolas thanks for this. Looks like I need to optimize it again. Will run the benchmarks too.