kill-sticky VS ideas

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

I found a fix!

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

Just add a little bit of code to a bookmark button, it works wonderfully.

Click the button and your scrollbar returns, the keyboard works again, _AND_ the page renders to a PDF beautifully.

You're welcome. :)

Lower latency native calls in Python would be extremely useful, thank you for your work! Is the following GitHub issue the right place to monitor progress? https://github.com/faster-cpython/ideas/issues/546

I'm open to doing some benchmarking. Several of my libraries have pure CPython bindings (StringZilla, UCall, SimSIMD), and all perform low-latency SIMD-accelerated ops, so might be a good testing ground :)

Recent CPython development has been towards optimizations and addressing use cases that benefit from optimizations, some coming from the faster CPython initiative. You might just get your JIT[1].

[1] https://github.com/faster-cpython/ideas/wiki/Workflow-for-3....

The faster-cpython folks seem to be working towards a JIT (https://github.com/faster-cpython/ideas/tree/main/3.13) and both pyston and cinder have JITs. So I don't think anyone has ruled one out.

faster-cpython team has done a lot of work to experiment on it: https://github.com/faster-cpython/ideas/issues/485#issuecomm...

It kind of sounds like migration to register based is a foregone conclusion, but it's not very clear to me.

lots of big ideas are still remaining to be done. One example is the register based interpreter, see https://github.com/faster-cpython/ideas/issues/485

A previous plan called for the beginning of a JIT in 3.12, seen as "Trace optimized interpreter" here: https://github.com/faster-cpython/ideas/wiki/Workflow-for-3....