7 ms·
Passive event listeners
- weeksie 9y agoShouldn't calling `preventDefault` on an event marked passive throw an exception? It seems sloppy not to but maybe I'm missing something.
- ChrisSD 9y agoIt should be logged as a warning but I don't think it should throw. Throwing obviously stops execution which is unlikely what the programmer intended. Javascript is, for better or worse, a permissive language. It doesn't like to break code when it doesn't have to.
- twiss 9y ago> Many developers are surprised to learn that simply adding an empty touch handler to their document can have a significant negative impact on scroll performance. Maybe browsers could do some static analysis for the simple cases? Or, would it be possible to fire all events asynchronously, and if the event cancels scrolling, revert the scroll position to where it was when the event happened? (And possibly mark the event handler as canceling scrolling.) That could sometimes cause jankiness when scrolling is canceled, in exchange for smooth scrolling in other cases.
- syberspace 9y agohow's this for an idea: maybe developers could write code that isn't shitty
- Piskvorrr 9y agoWhy didn't anyone think of that before?! I mean, what a breakthrough - think of the time that could be spent elsewhere, if only everyone got everything perfectly right. Coming up with the idea was the hardest part, implementing it should be easy, right? In other words, "We won't allocate any time for testing and debugging: just don't write any bugs into the code" -a PHB I used to know (Do you think people write shitty code _on purpose_?)
- syberspace 9y agoI don't think I said people write shitty code on purpose, I'll have to go back and read my own comment to make sure though. You might find that it is even a better option to do _more_ testing and debugging as opposed to cramming yet another pointless feature into already bloated browsers. And as a sibling to my previous comment mentioned: this is ripe with "unpredictability and interoperability issues" Maybe create a `static js analysis` browser extension for developers to aide them in their endeavours to stop writing shitty code, but don't force that down everybody's throat.
- connor4312 9y agoI'd hardly call this feature pointless. Scroll events, with cancellation support, have been a thing for well over a decade. This solves a very real problem of having to execute single-threaded application code that blocks scrolling. Particularly on mobile where resources are constrained and scrolling is smooth, this is a big problem. Having developers hint to the browser that the event will not be cancelled solves it very simply. Far more simply and predictably than any kind of static analysis could.
- 9y ago
- solarkraft 9y agoI'm thinking that maybe event listeners should be passive by default.
- fiatjaf 9y agoYes, but that would break the internet.
- Fifer82 9y agoI know this is a silly question and probably argued already over the years. But can't and shouldn't this be solved by some mechanism? Like, some umbrella "native-web-1" meaning that any project without that tag renders 2020 and below whilst anything with it as a brand new shiny implementation. It would also help prevent the relentless "wow I really like that 2024 feature, lets make a shit version now today and another 7 over the years so that everyone is stuck with a dependency which doesn't even follow the specification" (promises etc)
- workmandan 9y agoAlthough a nice idea in principle I think you'll just end up with horribly convoluted and hacky if/else logic throughout your code - much like the era of nasty IE6 kludges.
- fiatjaf 9y agoThat's a good question. That <!DOCTYPE> things is that such mechanism, isn't it? (Or it was supposed to be.) Perhaps the problem is that shipping, for example, two different Javascript engines would be too bad for browsers? I want to know.
- twiss 9y agoThe WHATWG's philosophy for the HTML standard is never to sway too far from what browsers currently do, mainly to make sure that the browsers can keep up: https://whatwg.org/faq?#living-standard https://whatwg.org/faq?#living-standard The browsers seem to like that, so it's probably unlikely that we'll get a wildly different HTML6 anytime soon, if ever.
- ezequiel-garzon 9y agoIs WICG a new kind of WHATWG? Does anybody know the difference between them?
- Ajedi32 9y agoThe WICG is a working group for W3C. Here's their charter: https://wicg.github.io/admin/charter.html https://wicg.github.io/admin/charter.html
- josephwegner 9y ago> For instance, in Chrome for Android 80% of the touch events that block scrolling never actually prevent it I'm curious how they get at this data. I haven't fully thought it through, but something about this raises the "creepy flag" in my head. Does this data come through the "Automatically send usage statistics and crash reports to Google" setting? Google's help page [1] regarding that doesn't seem to indicate it's recording information about website's javascript. [1]: https://support.google.com/a/answer/151135?hl=en https://support.google.com/a/answer/151135?hl=en EDIT: I'd also be curious if they have done any analysis to see if the mechanism that gathers this data is related to the performance implications of touchEvent listeners.
- twiss 9y agoThey measure lots of client-side feature usage, in part so that they know when they can deprecate something. Here's a list and short explanation [0]. Firefox has something similar [1] as part of Telemetry, although they measure less things [2]. [0]: https://chromium.googlesource.com/chromium/blink/+/master/Source/core/frame/UseCounter.h#47 https://chromium.googlesource.com/chromium/blink/+/master/So... [1]: http://gecko.readthedocs.io/en/latest/toolkit/components/telemetry/telemetry/collection/use-counters.html http://gecko.readthedocs.io/en/latest/toolkit/components/tel... [2]: https://dxr.mozilla.org/mozilla-beta/source/obj-x86_64-pc-linux-gnu/dom/base/UseCounterList.h https://dxr.mozilla.org/mozilla-beta/source/obj-x86_64-pc-li...
- fenomas 9y agoThe Chrome team probably runs some kind of automated conformance tests over various popular websites, so absent other information it would be simpler to assume that's where this data point comes from. (Though with that said, 80% seems surprisingly low. I can't think why a site would cancel a scroll event besides scrolljacking, and while that's getting more common surely it can't be on 20% of all sites?)
- yoshuaw 9y agoThe intercept is a fun example of where Passive Listeners would help. If you check out this article on mobile, you'll see the header jump around; passive listeners would fix that https://theintercept.com/2017/08/15/fearful-villagers-see-the-u-s-using-afghanistan-as-a-playground-for-their-weapons/ https://theintercept.com/2017/08/15/fearful-villagers-see-th...
- samwillis 9y agoYou can achieve smooth scrolling animations by using requestAnimationFrame and watching the scroll position within it, bypassing the blocking nature of the scroll event handler.
- tothepixel 9y agoThis coupled with storing the scroll position and only executing code when it actually changes is the gold standard IMO. Works fantastically well on mobile too.
- paulirish 9y ago`scroll` listeners are not blocking, however `wheel` ones are. If you've tried to implement a parallax effect in JS you may have noticed the subtle differences on timing between these two (wheel fires before the scroll position is updated, scroll afterwards). That said, yielding immediately within a listener (like you recommend) is indeed a best practice.
- Jonas_ba 9y agoWhile passive event listeners are an improvement, they are not a complete solution. It's more like the "least of evils". There is a new set of primitives that is being implemented called IntersectionObserver which solves most of the issues of having to detect when something is in view + they run on a separate thread. So you don't need to do any computations, reading the window size and whatnot magic to detect if an element is inside the window. We are currently using this in prod for our algolia static websites and it has worked very well for the majority of all of our use cases. https://github.com/WICG/IntersectionObserver/blob/gh-pages/explainer.md https://github.com/WICG/IntersectionObserver/blob/gh-pages/e...
- rjbwork 9y agoWhy do you need to detect whether something is in the viewport?
- eyelidlessness 9y agoThe linked description provides several use cases.
- SimeVidas 9y agoFor lazyloading stuff like images and ads. Or that technique where you have an infinite list, and the elements that are scrolled off-screen are recycled on the other end.
- esailija 9y agoYou can easily scroll so that the intersection observer sentinels are not seen and cause bugs. Disappointing.
- rvanmil 9y agoAnd while they're at it, please remove all api's which allow for scrolljacking.
- TekMol 9y agoDo I understand it correctly, to cause a problem, a page needs to: 1) Add a touch handler to the window.document element 2) Do computations even when there is no user interaction So when the user wants to scroll, the touch handler cannot be run because some other javascript is already running. So the browser waits until the other javascript is finished, executes the touch handler and only then scrolls. Is that correct? If so, I am not in much danger. Because I usually do not do a lot of computation without user interaction. And I also do not put a touch handler on the document element.
- ensiferum 9y agoThe problem is that the client side browser side implementation which has it's own display thread (It displays prerasterized tiles) must post the scroll event to the rendering thread which runs the JavaScript engine and then wait for the response before it can show the result of the scroll. With this flag the client side can respond to the scroll request immediately and display already rasterized tiles without waiting for the js thread.
- iainmerrick 9y agoIt seems like the root of this entire problem is that Javascript is single-threaded, but current browsers want to be multithreaded (and specifically to do rendering and scrolling in a separate thread). Does JS need to be single-threaded? I wonder if browsers could speculatively run JS event handlers in multiple threads, then block and transfer to a central "main" thread iff they mutate any global state.
- iainmerrick 9y agoTo clarify a bit: the passive event listener idea is a good start because it means the scrolling thread doesn't have to block on the main JS thread. But it seems like a big use of scroll handlers is to reposition some elements on the page, e.g. for parallax scrolling. Ideally that should synchronize exactly with the rendering thread, so elements don't jiggle slightly out of position as you scroll. The best way to do that is to run the scroll handler in the scrolling thread -- as long as you can avoid waiting for another thread.
- mnarayan01 9y agoConsider the need to block on e.g. the DOM.
- iainmerrick 9y agoMultiple threads have to synchronize their DOM reads and writes, sure, but that doesn't mean all access needs to be single-threaded. I guess what I have in mind is roughly like managing DOM and JS state via STM, and speculatively parallelizing the JS. I don't know enough about STM to know how well it works out in practice, and for what kind of workloads. The goal would be to improve JS latency (ability to run small functions quickly) even if it reduces throughput. This is all pretty speculative, I realize, I'm just wondering if there are obstacles beyond all the obvious ones, like having to rewrite the entire JS and DOM implementations. :)
- deleted 9y ago[deleted]
- totony 9y agohow does having a function(){setTimeout(handler,1)} compare to this?
- dkh99 9y agoThat function won't block the rendering operation. Having a lot of timeouts/etc. will potentially slow the JS down in general (indirectly slowing the page down or costing battery, CPU, etc., but it will not cause the user-action jank that the article is talking about.