Removal of Badges

[memoryruins]

Previously opened an issue about formatting and badge use on the awesome-rust list rust-unofficial/awesome-rust#419.

For awesome-embedded-rust, I propose continuing with the format we have now, which is the "simpler alternative" in the above link, except without any graphical badges (the graphical logo at the top looks fantastic, however). Removing the noise of misaligned badges, It's easier to read and especially to load. Bringing up now before the lists begin to grow, especially with the many crates to be added for no-std #2.

[therealprof]

@memoryruins So you're proposing to revert #1? I'm more in favour to go with #20 instead which would also remove a lot of the badges from the entry page to unclutter the entry page.

[memoryruins]

Ah yes, my bad. I would have left a comment there if I saw earlier. Many awesome lists do without, and the ones that add structure and alignment, e.g https://github.com/bnb/awesome-hyper, still experience sluggish load times.

I’m also in favor of splitting certain sections into their own pages, and less badges may be best in the long run there as well.

[berkus]

I don't like those badges either, they're cluttering the page.

[RandomInsano]

Exhuming this thread from the dead, I do think removing the badges is a good plan. @japaric what was the original reason to add them? They’re neat but was there other reasons than the coolness factor?

The practical reason I can see is to check for newer versions of crates in one place.

[eldruin]

Aside from the coolness factor, it has been useful to me to distinguish which projects have a published crate and which ones do not.
Personally, for the ones with a published crate I assume that the library is usable, there is a reliable versioning and a somewhat thought-through API, even if it is not complete.
Without a published crate I expect more of an unstable and not very usable project.

The slow loading is somewhat annoying, though. Would this be better if we used pngs instead of svgs?

[therealprof]

@eldruin If this is done right (haven't checked) SVGs would be vastly smaller than PNGs. I think the main problem here is that each image is individually loaded from the server...

[RandomInsano]

vastly smaller

Depends on the resolution of the rendered image. A one pixel bitmap beats them all.

It could be the browser implementation of parsing and walking a new complex data structure each image that is the delay we’re seeing.

Update: (now with facts!)

-rw-rw-rw-@ 1 me  staff  3060 29 Sep 09:09 lpc82x.png
-rw-rw-rw-@ 1 me  staff   963 29 Sep 09:09 lpc82x.svg

Forced full refresh of:
SVG: 1.56MB, between 16 to 20 seconds
PNG: 1.69 MB, 9.5 seconds first refresh, 2 seconds

SVG:

PNG:

If I were to guess, the badge generator or one of it's content delivery network servers is not caching SVGs. I had the browser cache disabled for both tests and they were performed on Firefox 61.0.2.

Considering that drastic improvement, I've opened a PR for this change and we can keep arguing if it's ugly or not later.

[therealprof]

Sorry, but I don't see any improvement here. It neither renders faster for me nor would I consider it a fattening the already big page further a worthwhile tradeoff.

[RandomInsano]

Really?! Can you open your browsers profiler, disable caching (both FF and Chrome support this) and check the networking timeline?

Update: I just did it myself (for science!) and you're right. Yesterday I ran refreshes about five or six times per page and it seemed to be consistent. Today they're inconsistent in both browsers. As good as 1.07 seconds on one load and as bad as 20 seconds in others regardless of the content type served up.

I think these speed differences are mostly in the caching somewhere out on the Internet. I'll go close that one off.

[Israel-Laguan]

As there is already a failed test for this change, maybe this PR needs to be closed.

[berkus]

I'll go and close this - seems like the consensus is to not proceed.