Oh, such a near miss! Unfortunately I’m flying back on 11th. I may have time on 10th. DM me if you’d like to meet.
Why are you serving Fira Sans as a web font, instead of using a system font stack? I don’t think you’re doing anything where it would make much difference, specifically, what font you use.
By the way, why does docs.rs specifically use Fira Sans? Is there something I’m missing here?
Crates.rs is completely lacking a color sheme and artistic style (you can help improve that), so I needed to give it some personality via the font, otherwise it would be as attractive as a tax form.
Tiny nit: you fall into the frequent trap of describing the project as “not the other” and not “what it is”.
“Unofficial, experimental, opinionated alternative to crates.io” does nothing more then making people ask “but why?” if they are not mentally aligned to you already.
I would remove that claim and put the goals of the project here. “A fast, lightweight, site to browse Rust crates” for example. (Exact form to be bikeshedded).
Maybe you can open-source the project without the bit pulling the data from crates.io and only the latest dump in it to avoid ddosing it? Either way, really good work!
@kornel This is great to see! While our API response times are very fast, the fact that we are a single page JS app and not server side rendered definitely limits how responsive we can appear to the end user. Let me know if I can help you with search at all. It’s fairly easy to get up and running at reasonable speeds for the current data set.
The website its absolutely great; the speed, long listings by page, intuitive and useful first page, the category pages turns all intuitive also, etc. So even unfinished its a great and really useful place, this are not just words, as a Rust newbie I had to comment it. Success.
By other side, when one visit crates_io, it is needed to employ a lot of time trying to figure out -besides I often get confused- if one crate, or one of the dependencies of its dependencies^n, require or makes use of a non Rust native code library (I mean non system related).
For me it is a very frustrating process, but I do it because in some cases can affect some long term decisions.
If some way it could be visualized the above in the listings, I think it would be really useful for all of us. A mere [Mix] flag or any visual in the listings would help a lot.
( a tiny box with [C], [CPP], [ADA], etc, would be better, but I guess that probably would require some code excessive analysis?, maybe would be an crate upload form mater).
I would also like to join the camp of those who want the search feature. Keep developing this site, it’s totally worth it.
I like it, lots! Some tiny tweak suggestions for the front page:
the “and 372 more…” could be a little more distinct from the rest of the list. Perhaps consider:
- a non-breaking space between the number and more?
- a slightly different style (perhaps just italic)?
- newline and right/bottom corner align as “… and 372 more”?
Unless I am mistaken, visual design is yet to be improved. I totally agree with your observations though!
You have two Encoding categories. Maybe the first one should be renamed to (De)Serializers.
I actually like the description at the top. This comment would have ended up a lot longer, for example, if you didn’t mention upfront that the lists are opinionated.
Good luck with implementing search. Combining relevance with scores will not be easy in some cases.
How often could you import them? Would it mean that crates.rs would never really be up-to-date with crates.io?
Crates index is on github, and for newly published crates it’s fine to update incrementally (just a few API calls). Only first run is a problem that needs to fetch all kinds of info about 16000 crates.
Wow, this is awesome. I’ve built something very similar, https://gitlab.com/est/cargo-local-serve
It similarly is very lightweight, taking tens of kilobytes per request not hundreds crates.io. Difference wise, its design is closer to crates.io than yours and the goal is slightly different (allowing people to self serve the interface without any internet). Also I haven’t bothered to set it up as public service unlike you did. It also offers minimal cargo API support that allows you to clone crates from it… not much needed for that.
Not having the dom creation implemented as SPA will fix so many issues I have with crates.io, like e.g. that there is no google preview support or that it’s so slow. I am very happy about any additional diversity in mirrors to crates.io. Good luck with crates.rs!
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.
That would be cool! I did a small prototype for determining which crates are commonly used together here:
I’d gladly help if you want to add search.
Nice! It´s super fast!
One bug i noticed that kinda ruined my exploration was that pressing “next” after scrolling in a category sent me to crates.io instead
Wow, that’s really cool!
Here’s an idea: is it possible to somehow display grouped crates as one? Let me show what I mean:
You can see that a bunch of
unic crates are shown separately. However, I think it’d be better to show only the main crate (
unic), which would free up more space for other crates.
If we can data dumps, is there a possibility we could have an offline crates.io site? Rust does very well with cargo doc having offline documentation. It would be great to browse likely crates offline. Maybe even have an indicator that that version happens to be cached on your system.
Sorry - maybe I’m over-prepping for skynet, but it’s great to be able to do as much as possible while offline.