mirror of
https://github.com/rust-embedded/awesome-embedded-rust.git
synced 2026-03-09 07:12:05 -05:00
Removal of Badges #9
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/awesome-embedded-rust#9
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @memoryruins on GitHub (Apr 29, 2018).
Previously opened an issue about formatting and badge use on the awesome-rust list https://github.com/rust-unofficial/awesome-rust/issues/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 commented on GitHub (Apr 30, 2018):
@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 commented on GitHub (Apr 30, 2018):
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 commented on GitHub (May 1, 2018):
I don't like those badges either, they're cluttering the page.
@RandomInsano commented on GitHub (Sep 16, 2018):
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 commented on GitHub (Sep 28, 2018):
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 commented on GitHub (Sep 28, 2018):
@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 commented on GitHub (Sep 29, 2018):
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!)
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 commented on GitHub (Sep 29, 2018):
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 commented on GitHub (Sep 30, 2018):
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 commented on GitHub (Jan 18, 2023):
As there is already a failed test for this change, maybe this PR needs to be closed.
@berkus commented on GitHub (Jan 18, 2023):
I'll go and close this - seems like the consensus is to not proceed.