Passive event listeners
github.com
github.com
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.
The risk here is that you end up where cases where non-obvious changes cause the static analysis to no longer work; at least in the current world there's a clear line between having a non-passive event listener and not having one. Attempting a heuristic could cause both unpredictability and interoperability issues (since the heuristic will surely vary by browser vendor).
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_?)
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.
So, yes, I am trying my hardest not to write shitty code, and to make it resilient - but no: it doesn't help nearly as much as your original comment suggests it would, because there are numerous forces beyond my control affecting the result. Worse, some behaviors that are inconvenient to me are seen as desirable by the respective library/browser/OS makers ("you say bloat, I say essential feature"), so even if all the parties involved up and down the stack were producing 100% shit-free code, the result of their interactions could still be shitty.
As for the automated-under-the-hood-fixes inside browsers - yeah, that would be great if there wasn't a need for those, or if they didn't exist at all (even though I'm aware that their existence enables inflationary expectations in JS developers). I'd also like a pony while we're in wishing-land.
TL;DR: No, handwaving away complex and leaky abstraction stacks doesn't work.
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.
By marking a touch or wheel listener as passive, the developer is promising the handler won't call preventDefault to disable scrolling.
Shitty developers who are lazy aren't likely to add that to their code if it 'works' without it. They are shitty after all. They won't care about a janky scroll on their webpage. Heck, they probably won't even test different ways of scrolling. Therefore it's fair to think this change is for awesome developers who test things and find that there's a problem, and need a way to fix it.
The point of passive listeners would be to make it easier for developers to not accidentally write shitty code and boost performance on well written code that doesn't have to be blocking the scroll.
1. https://developers.google.com/web/updates/images/2016/10/avo...
2. https://github.com/search?utf8=%E2%9C%93&q=non-passive+event...
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.
Modern browsers use separate threads for Javascript and rendering. But if you have a (non-passive) scroll event, the rendering thread has to block on the Javascript thread, and that's why scrolling is janky.
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.
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. :)
Javascript currently throws on many kinds of errors.
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
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.
Firefox has something similar [1] as part of Telemetry, although they measure less things [2].
[0]: https://chromium.googlesource.com/chromium/blink/+/master/So...
[1]: http://gecko.readthedocs.io/en/latest/toolkit/components/tel...
[2]: https://dxr.mozilla.org/mozilla-beta/source/obj-x86_64-pc-li...
(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?)
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.
> We improved the performance on a vast swath of the mobile web while causing problems for a very small number of developers/sites and virtually no users (we've heard almost no complaints from users about broken sites). Our data suggests we made the right trade-off for the web platform as a whole and for Chrome as a product.
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)
Perhaps the problem is that shipping, for example, two different Javascript engines would be too bad for browsers?
I want to know.
The browsers seem to like that, so it's probably unlikely that we'll get a wildly different HTML6 anytime soon, if ever.
That choice basically says to me that the idea of partitioning, or whatever those doctypes were for, is now abandoned.
I'm sorry - that just seems a bit...naive.
If "we" did as you are saying, twenty years would pass and we'd be having this same conversation again.
History is rife with examples of trying to fix things by wholesale rebooting, and people thinking "this time it will be perfect!"
...except it never is.
I think engineers of all stripes understand this; we've never seen this (yet...) in industries like aerospace or automobiles, or other kinds of hands-on engineering. For one, if it were done, people would probably die. But mainly, I think, because engineers know that throwing the baby out with the bathwater is a bad idea in general; that the institutional knowledge built into the outputs and practices are worth having in place and examining - both to learn what works right, as well as what doesn't.
Your suggestion is akin to a "not invented here" mindset, where rather than using existing frameworks and/or libraries, a developer instead opts to "go at it alone", to prove their implementation is better. Sometimes it is; sometimes it does advance things in a good way. But those tend to be outliers; "your implementation" likely won't be that case.
Also, to be honest, many of those "game changing" libraries and such are "built on top of" earlier stuff and package it better (with cleanup and tweaks added too). This isn't to denigrate either; in fact it's part of the process (and also show's why "first mover advantage" can sometimes be a fallacy as well).