All readmes are displayed whenever possible, and if there's no or poor readme, doc comments are shown too (example).
It combines information from multiple sources, e.g. byline is a compact amalgamation of Cargo.toml, crates.io accounts, and GitHub contributors, so you get an idea who wrote the code even if authors forgot to keep Cargo.toml up to date (example).
Crate popularity is displayed as top-N position in its most relevant category, e.g. "#5 in Cryptography", which is more meaningful than absolute download numbers.
Optional dependencies display which feature or platform they're for (example/example).
Version history is summarized to help see at a glance whether a crate gets regular updates and how often it has breaking changes.
Recognizes sys crates even if they're not called -sys and shows when build.rs is used (example). Shows how much non-Rust code there is in a crate.
Category pages fit more crates on screen despite looking less cluttered and having easier to read descriptions (example).
All categories and their representative crates are right there on the homepage.
Syntax highlighting everywhere, including inline `code` blocks (example).
Everything works without JS and gets indexed by search engines, so I'm hoping the site will help find crates. Give it some link juice, please
That's amazing, definitely can see myself using this (although I third the calls for some form of search box, even if it's just an embedded Google one :P)
Is it possible for any of this to be integrated into Crates.io? Or is the approach too different?
I clicked around a bit, and was impressed with how fast the delightfully bare-bones pages load on my midling mobile phone. Crates.io is a lot more sluggish.
I really like your idea of relative ranking inside categories (the "#5 in cryptography"). This nicely normalises across categories. e.g. clippy Vs bitflags, even though they're both #1 in their category, the download numbers are wildly different (35.935 downloads per month Vs 1.102.614, man bitflags is popular!)
How do you see this in relation to crates.io? Are you angling of being a replacement? Or more like a playground for ideas to be "upstreamed"?
crates.io is also a registry, primary database of crate metadata and an API, and it's doing well in these roles.
Crates.io front-end is heavy JS. It was easier for me to rewrite it in Rust than to get Ember working So these can't be merged, but crates.io can adopt some ideas.
If you decide to roll your own search, I'd be happy to brainstorm with you. The single most important piece of advice I can give is to design search alongside an evaluation framework for it.
I also see crates.io as accurate/objective representation of crate data. For example I search for any readme.* file in associated git repository, and crates.io shows readme only if author published it in the crate. I display github users as crate authors if they wrote arbitrarily significant amount of code, and crates.io displays exact metadata, etc.
This could also serve as a platform for experimentation. For example, one idea I've had for improving discoverability is for us to analyze dependencies to see what crates tended to be used together, so we can recommend related crates. Some of us are manually doing that today, like in assert_cli we have a "related crates" section.
Yes, crate suggestions would be great. It doesn't work well with simple co-occurence though, since it wouldn't be able to know failure is an alternative for error-chain.
So these can't be merged, but 
