UPDATE: just use nodenv. As of now (2017 May), I have used nodenv since I published this post in 2015 with zero complaints.

TL;DR: use the packages nvm or if you're feeling brave, n to install node. The problem with n is that as of now it does not isolate global packages to the version (see issue), which can create problems if the package doesn't work with the node version you installed. Plus, n is less commonly-used. However, nvm may not be the end of the story: rbenv style node version managers, of which OiNutter/nodenv is the most prominent,^[1] are probably a better model. But since there are relatively few users and I haven't really used it, I'm reluctant to recommend it.

Version managers are becoming standard for languages, with Python and Ruby leading the innovation.^[1:1] This is sort of a trivial post, but for a community to become mature and stable, it has to establish customs ("idioms") and make sure that things work properly when you follow those customs. Package management is one of the thorniest problems in the open-source world. I've heard it said that to up half the time as a practicing engineer can be spent dealing with packages and incompatibilities.^[1:2] It is important to for the community get at least one way right before veering off into more adventurous possibilities.

If you're new to programming or node, it might be best to skip this complexity and follow the download instructions on the homepage. But in the real world, sooner or later competing versions of node will create pain if you're juggling multiple projects (e.g., my ReactJS project required node.js 0.10 but I wanted to have the newer 0.12 version readily available), so this is one of those areas where it is a good idea to get used to this extra complexity early.

---

1. Note that there is a modern fix to the packaging problem: semantic versioning. ↩︎ ↩︎ ↩︎