kill-sticky VS .NET Runtime

Threw together a bookmarklet that sends a page over to a personal, private subreddit the other day that I've been using a ton. Also a HUGE fan of kill-sticky.

Would love to throw some other good ones up there.

-

  javascript:(function()%7Bdocument.querySelectorAll(%22body%20*%22).forEach(function(node)%7Bif(%5B%22fixed%22%2C%22sticky%22%5D.includes(getComputedStyle(node).position))%7Bnode.parentNode.removeChild(node)%7D%7D)%3Bdocument.querySelectorAll(%22html%20*%22).forEach(function(node)%7Bvar%20s%3DgetComputedStyle(node)%3Bif(%22hidden%22%3D%3D%3Ds%5B%22overflow%22%5D)%7Bnode.style%5B%22overflow%22%5D%3D%22visible%22%7Dif(%22hidden%22%3D%3D%3Ds%5B%22overflow-x%22%5D)%7Bnode.style%5B%22overflow-x%22%5D%3D%22visible%22%7Dif(%22hidden%22%3D%3D%3Ds%5B%22overflow-y%22%5D)%7Bnode.style%5B%22overflow-y%22%5D%3D%22visible%22%7D%7D)%3Bvar%20htmlNode%3Ddocument.querySelector(%22html%22)%3BhtmlNode.style%5B%22overflow%22%5D%3D%22visible%22%3BhtmlNode.style%5B%22overflow-x%22%5D%3D%22visible%22%3BhtmlNode.style%5B%22overflow-y%22%5D%3D%22visible%22%7D)()%3B

Kill Sticky bookmarklet[1]. Also works on mobile. Get in the habit of clicking it, you'll start using it a lot to recover that extra inch of vertical space that web devs love to take away from you for some bizarre reason.

https://github.com/t-mart/kill-sticky

I'm going to change your life: https://github.com/t-mart/kill-sticky

Works in every browser (I use it in Safari on iOS and Firefox on desktop). These fucking stupid sticky elements are so common, I almost reflexively go hit this bookmarklet on every website now. It makes the web so much better.

In the meantime, NoScript[1] frequently avoids them entirely by just showing the page contents with no JS at all, and Kill Sticky[2] cleans up the ones that require JS to show you the content you actually want.

[1] NoScript for Firefox & Chrome-based browsers: https://noscript.net/getit/

[2] Kill Sticky bookmarklet for all browsers including mobile: https://github.com/t-mart/kill-sticky

Or, a Firefox extension that adds a toolbar button: https://addons.mozilla.org/en-US/firefox/addon/kill-sticky/

kill-sticky just JavaScript so it will work on any browser

Though today much of the Microsoft.Extensions family is considered BCL by most users, especially in the way it is documented as "Core functionality" (the "Generic Host" model uses a lot of Microsoft.Extensions, up front in .NET documentation today) and also in the way that the majority of it (especially in this case of Microsoft.Extensions.Logging) is source controlled side-by-side with most of the BCL, including almost all of System.**: https://github.com/dotnet/runtime/tree/main/src/libraries

(There are some of Microsoft.Extensions that exist outside of dotnet/runtime in dotnet/extensions: https://github.com/dotnet/extensions/tree/main/src/Libraries)

GCHandle.cs

The referencesource repository is only relevant if you are using the legacy .NET Framework. Modern .NET has a special case for passing a List and avoids the allocation:

https://github.com/dotnet/runtime/blob/1f01bee2a41e0df97089f...

coreclr_delegates.h

Unthinkable crutches in Go land continue.

This is something that needs to be fixed in the runtime itself to be appropriately container-aware and not require the users to write their own libraries to patch this out.

For example: https://github.com/dotnet/runtime/pull/99508

(alternatively, the goroutine runtime could have been made auto-scalable which would have reduced the impact at the cost of implementation complexity, like .net's threadpool is)

If you're interested, here's the overview of planned compiler work for .NET 10: https://github.com/dotnet/runtime/issues/108988

Autovectorization is usually very fragile and in areas where you care about it hand-written implementations always provides much better results that will not randomly break on minor changes to compiler version or the code, that must be carefully guarded against.

It would be still nice to have it eventually, and I was told that JIT team actively discusses this but there are just many more lower hanging fruits that will light up in disproportionately more instances of user code.

Each limiter, except ConcurrencyLimiter, caps the number of requests in a time period. ConcurrencyLimiter caps only the number of concurrent requests. All limiters are derived from the abstract RateLimiter class and implement the following public API: