crates.io front-end and its accessiblity issue(s)

Before we start, a disclaimer: this blog post is me venting out because I think crates.io could be much better than what it currently is. Of course, this is very subjective. And finally: this is not an invitation to go lash out or complain to the crates.io team. I told them everything that is listed here multiple times so no need to repeat it to them.

Some context: I talked with the crates.io team about the listed issues here for years (since the creation of the first version to be exact, so quite a long time), proposing my help to implement the changes I suggested. It was either ignored or rejected. I did that multiple times along the years and since nothing changed, I think it's time to talk about this publicly (again: not an invitation to go lash out on the team!).

One person from the crates.io team and one person from the Rust moderation team read this blog post before publication and made suggestions I applied.

With all this in mind, let's go!

Only possible to authenticate with Github

Just: why? There is no valid reason to force people to have Github accounts in order to publish Rust crates. The fact that it's still the only way 11 years later is bad.

lib.rs exclusive features

Surprisingly enough, lib.rs provides some really nice features that crates.io doesn't, like:

• The list of features for each crate.
• Dependency changes for each release (you can see it here).

Rust platforms unification

We talked about unifying styles for a more unified experience across official Rust websites at the 2026 Rust all-hands. This means having similar themes, icons and going toward a somewhat similar "layout feeling". The idea is to let users know that they are on a Rust website just by looking at the website. The work was started (and quite advanced) on:

• mdBook
• rustdoc
• docs.rs
• clippy lints page

crates.io didn't start this work. Interestingly enough, lib.rs did.

Duplicated features

As mentioned, during the 2026 Rust all-hands, we discussed about a more unified experience across Rust websites. However, docs.rs and crates.io now both have a source code viewer feature:

However, with the current implementation, I'm against removing the feature on docs.rs for a few reasons. Now comes my personal opinion: crates.io source code viewer is a less good implementation of this feature. Let me describe why:

• It requires JavaScript (I'll write it "JS" from now on). More about why making JS mandatory to browse a website is not a good idea if you can avoid it below.
• Inline style instead of using CSS class, which would also allow web extensions to simplify the style overloading while also allowing to make the web browser do a lot less work (CSS classes are defined once, inline style needs to be handled on each DOM element).
• They use CSS Grid, hard-limited to 10.000 rows in web browsers implementations.

Just to be clear, all the points I described here were discussed with the crates.io team here, it's just not an issue for them. They discarded the arguments by mentioning they picked this approach because of "tradeoff" (although they didn't mention between which approaches), but since alternatives with better outcome exist, it cannot be qualified as such. It's a choice they made knowing full well that (better) alternatives exist.

Wrong HTTP codes

If you go to a page which doesn't exist, one would expect to get the 404 HTTP code (not found). So let's try when we query a crate which doesn't exist:

$ wget https://crates.io/crates/thisdoesnotexist
HTTP ERROR response 403  [https://crates.io/crates/thisdoesnotexist]

Instead we got 403 (forbidden). What's forbidden here though? No clue.

It's the same for all non-existing pages:

$ wget https://crates.io/thisdoesnotexist
HTTP ERROR response 403  [https://crates.io/thisdoesnotexist]

JavaScript

In case you didn't know, crates.io doesn't work at all without JS enabled:

In my opinion, this is a major issue because:

• Some users may disable JS for a long list of reasons. Here are a few:
  • Because they use a very old device which either use very outdated JS engine or doesn't support JS at all or even doesn't have enough RAM so it's disabled.
  • Completely blocking ad trackers and ads in general without relying on ad blockers (which are now disabled in Google Chrome in any case). Some websites use JS to detect if you used an ad blocker, so the only solution there is to completely disable JS.
  • A website using too recent JS that your web browser doesn't support (because your organization forces you to use one specific version of one specific web browser, sadly not that uncommon), so you disable your JS and hope that it will still work with JS disabled.
  • Once upon a time (didn't check if still true today), Google Chrome on Android automatically disabled JS if you were on a 2G connection.
  • Around 1% of the users have JS disabled (based on gov.uk stats).
  • JS download might be blocked by local network (corporate environment, looking at you).
  • Text-to-speech web browsers have issues with JS (hopefully it got better since I last checked, 4 years ago).
  • Text-based web browsers (like Lynx) don't support JS.
  • JS is often used to track users across websites so they can create a profile out of you to be sold. See the numerous meta cases and the whole ad industry. Some web browsers extensions help with that, but it's often imperfect.
• Accessibility: as I mentioned above, text-to-speech and text-based web browsers have poor JS support, at best.
• And the most important point: almost all content on crates.io is static. It could be served as plain HTML/CSS and you wouldn't see a difference. If you didn't know, there is an equivalent website (with a different style but mostly same features) which already exists: lib.rs. The only case I encountered that would actually require JS is the download graph (there could be others though!), even though lib.rs provides graphs without JS, so...

JS is supposed to improve the experience, not being central to it (there are exceptions obviously where JS is impossible to not use, but they don't apply here). For example, the only feature that requires JS on crates.io (as far as I can see, I might have missed a few) is the download graph. The syntax highlighting could be also done with JS too (but docs.rs does it in the back-end, so again it's not mandatory, just a choice).

Just to compare:

• rustdoc works with JS disabled.
• mdBook works with JS disabled.
• clippy lints page works with JS disabled.
• rust-lang.org works with JS disabled.
• docs.rs works with JS disabled.
• rustup.rs works with JS disabled.
• rustfoundation.org works with JS disabled.
• rustlings.rust-lang.org works with JS disabled.
• lib.rs works with JS disabled (although not an "official" Rust website).

Some of them have less features with JS disabled, but they remain completely useable, like rustdoc search and settings need JS to work, but otherwise you still have access to (almost) everything. It proves that JS is not a requirement or mandatory, it's a choice.

Here are other languages equivalent for crates.io:

• JS: npmjs.com works with JS disabled (yep).
• Python: pypi.org works with JS disabled.
• Ruby: rubygems.org works with JS disabled.
• Go: pkg.go.dev works with JS disabled.
• Fortran: fortran-lang.org/packages/ works with JS disabled.
• PHP: packagist.org works with JS disabled.

So far, I actually couldn't find any other programming language package website which has a JS requirement to browse their website.

The only other Rust website which actually requires JS to work is play.rust-lang.org. And it's part of the exceptions: without JS, you cannot have nice syntax highlighting, you cannot send AJAX queries to run commands on a server, etc. To be noted, we could make it work without JS, but then you would have potentially "out of time" queries when the query is running on the server, no more syntax highlighting when you're typing, very big (data and time) exchanges with the server whenever you run a command... So in this case, JS is actually providing a much better experience that we couldn't get otherwise.

I offered an alternative reimplementation of the website front-end which wouldn't require JS to work. It would be the same as the one we use for docs.rs, making them closer and likely easier to maintain as the two teams could help each others. It was denied. If you're interested in knowing why, the discussion was here.

Conclusion

So again, it's just me venting out, built-up frustration along the years when I feel like most technical choices they made for the front-end were wrong ones (again, it's just my opinion). I do hope they will change course in the future and finally drop the JS-requirement for the front-end as I think everyone deserves accessibility to such a central website as crates.io is for Rust.

Apart from that, well, I think I did everything I could to change things, even suggesting to do the work myself. It was rejected/ignored. Nothing more I can do except vent out as I did.

Words of the end

And now here is a picture of my cat to make everyone more relaxed: