Download page: can it be simplified? #7421
Comments
|
@nodejs/nodejs-website |
|
You want the source, go to GitHub. The downloads page is possibly not meant for that. The GitHub link is right on the top right corner, click it, select a tag and download a zip. We're not aiming on having a dedicated button for source downloads (as it adds more confusion). And the current downloads page is way simpler than it was before (based on studies and careful UX), so although I understand you find it harder, because you were not able to find a source download link which was intentionally removed; That doesn't make the download page necessarily "less simple" -- do not take your individual edge case experience as a blame, please; Although we'll keep an eye if we see more similar feedback. I don't think we intend to change this behaviour, although I'm neutral on adding a footer link within the download page (together with the rest of links) to download the source; But I'm slightly opposed based on how many people actually use that website to download the source. |
|
(take my commentary with 2 grains of salt; I understand why you are upset, but the tone here and phrasing isn't the best for addressing your issue and proposing a solution; The feedback at the bottom was totally fine, and you could have just said that 🙇) |
I feel that for the source it's better to document how to get it somewhere instead of relying on website pointers. It's usually used by embedders and distributions, in which case, they probably want to check the signature. I am not sure if the tarballs released by GitHub when a release is tagged can be verified with the signature properly? And in any case, to the get signature, they still have to get it from e.g. https://nodejs.org/dist/v22.13.0/SHASUMS256.txt |
|
Actually I am fairly sure that you can't use the GitHub release source tarballs for verification - they don't even have the same size as the source tarballs in the dist directory, as we remove quite a bit from the release source tarballs https://github.com/nodejs/node/blob/d0ff34f4b690ad49c86b6df8fd424f39d183e1a6/Makefile#L1224-L1251 |
So, should we add a link as the "solution"? 🤔 |
|
There are already a bunch of links on the download page, I guess it doesn't hurt to either add link to a document that describes how to build releases from source (which is less so for contributors but more for embedders, re-packaged forks and distributions) - I can't even find |
|
Frustrations I have with the current Download page:
It definitely happened when working with a colleague to reproduce a bug on different Node.js versions, we visited the Download page, try a few links, and we had to give up and manually go to https://nodejs.org/dist/, because luckily I knew of that index. |
The link goes directly to BUILDING.md on Node.js core repository, which is exactly where you get to know how to build from the source. If you believe Node core docs are insufficient, I doubt that's an us issue, although I'm more than happy to collaborate on making this better, even if it is a Learn material on Node.js Website
The link goes exactly to that section although for some reason it is not highlight/auto scrolling to said place. @bmuenzenmeyer something seems to have been broken as I cannot see it scrolling anymore. Looks like the URL itself is wrong. Let me fix it on a hot-fix. |
I'm not looking on documentation for how to build from source, I'm looking for the source files, i.e. the signed tarballs. (FWIW the tarballs contain
AFAICT it does not, only the latest version of each release lines are listed there (if I want to download e.g. 23.1.0). Disabling JS reveals the link I was looking for. |
Yes, that link you referenced aren't source links. The clearly says "Learn how to build Node.js from source"... And I already agreed with @joyeecheung into adding another sentence to reference source tarballs for a given version. I will open a PR shortly. |
Yes, because without JS determining your OS becomes impossible on the client-side. Regarding it only showing the latest version, I believe that's the only thing that makes sense here. I'd like @nodejs/releasers to chime in here, as it doesn't make sense for us to redirect to users to an UI that shows previous minor versions of a major release... It does tho make sense to show all previous major versions at their latest minors. |
I disagree; for example, there's no way I'm ever gonna need to download v0.12.18, on the other hand I have use cases for downloading older versions of 23.x or 22.x. (and I realize my use-case is not universal, I'm pointing it out to show that any filtering is arbitrary and is not going to accommodate everyone)
As a user: it would be perfectly fine to link to https://nodejs.org/download/release/ and let the user figure out what they need from it – users who need a specific version of Node.js are power users, they don't need to be babysat with some fancy HTML/CSS, and we don't need to decide for them what versions they should be looking for. As a releaser: it doesn't impact releasing at all, so whatever the website team wants to do is fine. |
I understand that, but you're a power user and an experienced Node.js maintainer. Most of people will immediately give up once they see an "index of" page. And most of the users will want just older major versions, not older minor versions. For users like you, it is easier to just go to nodejs.org/download/releases.
Yet, I believe it falls on Releasers domain of how they intended of releases being used. I appreciate your feedback, Antoine, but I unfortunately am not going to make said change. I believe most if not all website maintainers here will agree with me here. Appreciate your feedback tho. |
|
I've made a poll (not a representation of real user data, but can give some insights: https://x.com/wunderacle/status/1883634713912553509) |
IMO it's actually fine if non-power users are discouraged from installing a non-up-to-date version of Node.js |
That ain't discouragement, just bad UX. discouraging is a message saying please dont do that |
Wiktionary cites two meaning for discouraged:
I was meaning the former. I don't know why you argue with me, I think you understand what I mean and what is my suggestion, it's fine if you disagree – we clearly have different ideas for what constitutes a "good UX" for the download page. |
Im not doing a bad faith argumentation, just trying to find a baseline and better understand your points. Everyone has a different understanding of UX, fortunately, I've been pushing this initiative successfully, and I ask for a bit of trust. I genuinely don't think redirecting to said page is good. We could get experts involved, because this is not the such of thing that a personal opinion should prevail 😅 |
|
While I don't think https://nodejs.org/download/release/ is, by itself, all one needs for information about how to download Node.js, I think @aduh95 's point is probably more about that the lack of this information on the downloads page is a pity for situations where none of the options provided among the drop downs work for the reader, and I agree. Personally the dropdowns send a very limiting vibe to me, as if there are no other ways to download Node.js besides the options listed, when in reality there are many people who don't get Node.js using any of the suggestions there (especially Linux users). I don't get this vibe from the download page of most similar software because it's a lot more common to just see a document describing all the ways to download this software with some instructions about how to get the source in the end as a fallback, instead of just seeing dropdowns with very limited options that you need to choose from. As far as I can remember, Node.js is the only software that I've seen that lists download options this way. |
With all due respect, that page has 0 information about how to download Node.js; It is just a huge directory listing. Most of users will have no idea what that is about.
That is a hard claim to make that I really do hope you have data to back that up. Plus, the current downloads page lists all possible installation methods, including for Linux and all its variants, including IBM-Z for example. Have you even checked that? The current downloads page has all available installer and prebuilt options for all OSs that we support...
The main difference is that the top of the downloads page first and foremost recommends using version managers, as this was an agreement and recommendation by the TSC, upheld by several TSC votes. So apologies my little frustration when you make such claim 😭 |
Node.js is kinda unique in this way as most competitors have an all in one Bash or Powershell script made to install it on the system. We don't have something like that and the closest to that are the community-based version managers. Node.js also has one of the largest amount of out of the box (and officially supported and 1st-party maintained) prebuilt binaries, which definitely makes having a consolidated and consistent, that shows all options yet is easy and newcomer friendly quite the challenge. |
|
(Apologies if Im missing something. Also, Im going to remove myself from this discussion... Ive said all I had to say. Opened a PR to address some of the only concerns I deemed valid and opened a poll on Twitter) Have a good one y'all 🫶 |
|
We should definitely link to https://nodejs.org/download/release/ if user is looking to previous versions. |
I definitely see your point there. But I just can't agree with the fact that we should avoid redirecting people to a directory listing. What I believe makes sense:
I am just trying to find alternatives that do not include redirecting someone to a confusing page where they don't even know what to find. |
|
When I click on previous release: 
Then I click on a release: 
It redirects me to a folder. Its just extra steps to arrive to the same conclusion, and I cannot even find the previous minor or patch. Let's just link to https://nodejs.org/download/release/, its an advanced use case and it doesnt seem confusing. Its a directory, if you are looking for v22.5.1 you find it right there. |
|
Right the UX point here is to find the release you want and have quick links. The "releases" button pointing to the directory listing is a temporary workaround as we would like to have it going to the current downloads UI with the version selected. But I'm not going to die on this battle. If y'all have strong opinions about this, Im fine making this change. But I genuinely believe we should have a better UI here. |
|
I'm not opposed to a better UI, I think we can temporaly link to https://nodejs.org/download/release/ which is better than the current situation imho, and then improve it. |
|
FWIW ~2 years ago the Previous Releases page looked like this:
i.e. it paginated listed all releases with a search box to quickly locate if you knew what you were looking for. The search box was responsive -- if you started typing it would filter the releases accordingly. |
Yup, that is what I am also trying to fight for, and Id love to make something like this again. For context the current table looks like this because we didn't have the time to implement a pagination during the migration. I'm all in for a Client-Side version that has these exact same features back. |
|
@joyeecheung @aduh95 @marco-ippolito how would you feel if the page listed all versions, including minors; I’m curious to know your thoughts on this:
|
|
fwiw the current page could probably work fine as-is without JS enabled by adding a submit button (to submit a GET form that wraps the dropdowns) |
The website is statically generated, it cannot handle this, it does not support form submission as it is done on the server side. |
|
@ljharb I understand the feeling, but being static was a requirement done by the TSC. But we can do said simpler non-JS friendly version of downloads page that could also used for the above. |
Noted. I missed this comment. I'll update my existing open PR linking to this page for the meantime. |
|
Addressed on 2ee664f |
|
I am late to the party because I was trying to enjoy Chinese New Year, but just to respond
You can find information from the next-10 survey: https://github.com/nodejs/next-10/blob/main/surveys/2024-04/Node%20Next%2010%20Survey%20Results%20OVERVIEW.pdf a significant amount of users get their Node.js releases through system package manager or use a Node.js package manager to install Node.js (yes it's a thing). There are also several other Node.js version managers that are not listed in the official download page (of course, it is not possible to list all of them; but to me a dropdown sends a more "there are no more" vibe than a document). If you cross-check the supported platforms in BUILDING.md you'll probably also find many OSes missing from the the download page e.g. FreeBSD, SmartOS. I also know from support issues from the issue tracker that people have all kinds of custom builds of Node.js that are either provided by the system, or that they build themselves from source. Again it's not possible to list them all, and they are kind of niche with a difficult to measure user base (e.g. there is a pretty extraordinary amount of bug reports coming from FreeBSD, but it doesn't show in the survey). But my point is that we should be able to admit it's not possible to list them all on the download page. I also happen to have worked with some big companies that deploys Node.js internally. It's very common for enterprises to have re-package and build their own Node.js build in their own production environment (e.g. to dynamically link to certain dependencies). There are also popular Node.js embedders including Electron, Photoshop, mongoDB etc. In the case of these environments, their maintainers could be looking for signed source tarballs. For Linux distribution maintainers, this is also useful information. That's why listing release source tarballs is important to extend the reach of Node.js.
I am not sure what you think about when you think about Node.js's competitors, but when I think about its competitors, these come to mind: https://www.python.org/downloads/ (In many settings, these are still more popular than Node.js) |
|
And, to that point - what happened to https://nodejs.org/en/download/package-manager/all ? If we are talking about "listing all available options", this looks a lot more extensive compared to the dropdowns. It seems worthy to dust that page up and link to it as a "Installing Node.js using a package manager of your choice", that kind of thing. IIRC when we were discussing the redesign the dropdowns were only discussed as "listing recommended ways to install Node.js". I don't recall at any point this was discussed as "listing all possible ways to install Node.js", even if we don't talk about the UI, listing all possible ways to install Node.js is just obviously impossible and can only be done as best-effort. And I always expected that below those dropdowns we'd have more information for the case where "if none of the above works for you". |
I'm aware of that and never contested that, our primary method of installation on the website is via version managers 😅
Hmmm, I believe (as you mentioned yourself) that these methods are extremely niche, and do not make sense to be listed there, they weren't either on the old download page (afaicr) but all "major" Linux installation methods are there; Don't get me wrong, I'm 100% open into listing SmartOS and FreeBSD installation methods through the prebuilt chooser or version manager approach. Things just need to be properly thought of in a way that feels organic (which is what we accomplished with the redesign of the redesign)
Shocked... Would never have thought of that, but indeed it is really hard to assess those methods when Node.js itself doesn't provide telemetry.... I swear that we should have opt-in telemetry by default as Deno and Bun are doing (Or I think I recall them doing so) -- but that is another controversial topic haha!
I was mostly referring to Bun, Deno, or JavaScript ecosystem impact projects such as webpack and eslint or even VSCode. PHP and Python have a release page format that resembles a lot our blog posts. Having that said, Python is bundled on most OSs (but in general one of the most tricky packages to self-manage as it is an OS dependency in many cases... Making it extremely hard to have alternative versions without using containers or virtual environments etc... And PHP is mostly installed either on bundled web servers (such as LAMPP/XAMPP) or installed through OS package managers; I rarely ever seen someone downloading PHP standalone binaries on my almost 1 decade of developing PHP (from 4.X to 7.X)
Indeed! |
That is an interesting point. Being honest I do believe that page should over time be deprecated, we shouldn't list all the ways the universe provides to install Node. I for example am against showing OS package managers (such as But I definitely believe that most relevant ways or installation methods that are known for being well maintained and not changing their way of installation intermittently so we have less chances of providing instructions that are either deprecated, old, not recommended or outright do not work. I believe curating what we host within our website to be more in line "less content but higher chances of being relevant" is better than "more content that can be outdated/wrong" as it frustrates the user and can also have side-effects (think about learn content for example... The balance of amount vs quality is thin) |
I 100% agree with you. Dropdowns should be a best effort situation. However, a page containing all other methods should also not include every possible method. Hence I'm thinking on a another version of the page (also non-JS friendly) that can be used to list all prebuilt/installer/officially provided by our infra links + 3rd parties such as Nodesource and RedHat + a list below with direct links for these various different ways (think of apt, dnf, etc...) This is the next step, and that is a page meant to also be used by /about/previous-releases so that people do not need to use the directory listing. This page would eventually replace the /download/package-manager/all page, and be more for power-users and advanced methods. I do believe the current main download page is genuinely the best for most users and average users. |
|
(If we're telling people to use |
💯 -- And that's why in general I would strongly recommend to either discourage people from using OS package managers... Except the ones we recommend. Winget, apt, dnf, so many of them with their official repositories are extremely outdated, and for reasons, at least on the Linux side because they attach a major line of Node.js to the OS's major line (like what macOS does with Safari lol) OR "show" options with our third party repositories, but again, those can change, and might not work on all variations of a distro. For example, it's not because a distro has |
|
If one thing I learned within my years at the GNOME Foundation is that the Linux ecosystem is extremely fragmented. If we think JavaScript is fragmented, heh, Linux is way worse on that regard (not Linux's fault) |
|
This follow-up issue was created to follow-up on the numerous commentary made here #7442 Since we already chatted enough here, I'm locking this issue for collaborators for the time being. Please follow-up any idea/suggestion on the linked issue and its sub issues. Thank you! |
|
(Also closing this issue as the initial complaint proposed by the author is now fixed) |
It seems someone has recently changed https://nodejs.org/en/download.
I can no longer find what I am looking for.
In the past I tried to download the source.
We had simple links such as:
https://nodejs.org/dist/v20.18.0/node-v20.18.0.tar.xz
These were made available on the download page.
Could someone please have a look at the new download page there,
and simplify it in that we can quickly and easily find a direct link to
the source release? I now have to click on some weird buttons such
as "linux". And still not find it. The old layout was sooooo much simpler.
I also now seem to get a combo-box. This is actually less efficient
UI design, because now I have to scroll to the version I want (stable
or unstable) and then still not know what is the real URL.
I figured out the URL by using this one:
https://nodejs.org/dist/v22.13.0/node-v22.13.0.tar.xz
But I did so manually. If you don't want to add this information
back, perhaps you could add a separate link with the direct
URL as-is, just like it used to be in the past.
The text was updated successfully, but these errors were encountered: