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

crates.io front-end and its 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<br>HTTP ERROR response 403 [https://crates.io/crates/thisdoesnotexist]<br>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<br>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...