Hacker News Reader

Comment by syberspace | Hacker News Reader

how's this for an idea: maybe developers could write code that isn't shitty

Why 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_?)

I 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.

Well, okay, great. Let's assume that I do write perfect code to run inside the webpage (which is what I strive for, and there are tools that help me with that; your radical new idea for JS static analysis tool has been implemented for years, and I'm actively using it). Great. And then the code needs to cooperate with multiple ad network codes, third-party plugins, all while working around browser-based bugs (oh, and did I tell you that there are various browsers, each with its own set of quirks?).

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.

I'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.

You seem to be misunderstanding my point. I'm definitely all for passive listeners. But I am very much against putting more workarounds for shitty developers directly into the browser.

The change we're discussing here is something that the developer will need to explicitly add to their code;

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.

yes, passive listeners are great. What I don't want in my browser is a static analyzing tool as the first comment I answered to suggested

Well...that's a bummer, as modern JS virtual machines used in browsers all use some sort of predictive code path model, and such static analysis is an integral part of this.

The whole point of TFA is that it doesn't matter what code the developers write; the browser needs to block on handlers regardless due to how the events are specified. The described new feature fixes this.

But wouldn't a developer who is surprised by performance penalties caused by empty scroll event handlers also not use passive listeners?

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.

Chrome gives nice warnings when passive listeners are not used[1]. This is demonstrably[2] causing people who have not used passive listeners / may have written poor code in the past in the past to take note and use them. It works.

1. https://developers.google.com/web/updates/images/2016/10/avo...

2. https://github.com/search?utf8=%E2%9C%93&q=non-passive+event...

Reply on news.ycombinator.com