Моя логика в том, что visible = scrollY === 0 || prevScrollY > scrollY; невозможно ускорить или сделать более эффективным через цепочку вызовов внутри debounce

Так как там проверок будет в 2-3 раза больше на каждом вызове (500 их в секунду или 10)

Зачем ускорять, нужно просто реже тригерить. Одно другому не мешает.

?

Мешает, так как здесь одна проверка и одно присвоение, а debouce притащит кучу внутреннего кода и проверок (тригерить или не тригерить сейчас, запросы времени и т.д.) который еще и не в местном контексте будет.

Понятия не имею о какой куче внутреннего кода идет речь.

https://t.me/sveltejs/126993

Марк, положа руку, что быстрее выполнить одно сравнение и одно присвоение в местном контексте:

    visible = scrollY === 0 || prevScrollY > scrollY;
    prevScrollY = scrollY

Или обвязать это двумя системными вызовами, где внутри будет вызываться код выше:

clearTimeout(timeout);
timeout = setTimeout(() => /* debounced */, 20);

    visible = scrollY === 0 || prevScrollY > scrollY;
    prevScrollY = scrollY

clearTimeout(timeout);
timeout = setTimeout(() => /* debounced */, 20);

Положа руку я клянусь в том, что это спасет от смачного наступания на грабли рано или поздно.

А то, на миллисекунду дольше или меньше будет выполнятся этот код - вообще без разницы

Ваше право, если вам хватает небольшой проверочки и не будете экстендить анимациями то можете без дебаунсера, но я привык всегда с ним - на душе спокойнее =)

А вот это интересный вопрос при маунте переменная scrollY уже будет заполнена правильным значением или нет, при использовании конструкции
<svelte:window on:scroll={handleScroll} bind:scrollY/>

Тоже интересно. Узнаете?

Просто для меня это выглядит как premature optimization.
Одно сравнение и одно присвоение в местном контексте исполнения в десятки раз дешевле, чем вызов двух тяжелый функций работы с очередью таймеров. Этот код так же компактнее.

Анимации я хочу сделать на svelte, где просто будут подставлены разные transition в те моменты, когда значение visible меняется на противоположное. Сразу скажу, тут тоже не нужен debounce - пользователь не способен 500 раз в секунду менять направление скроллинга при работе со страницей ))

Вот здесь в этой строчке кода вы увидите псевдо оптимизацию, а потом, без дебаунсера, можете случайно добавить node.getBoundingClientRect() во время скролла(используя который также кстати можно вычислить направление скроллинга), и фпс славно полетит на дно =)

Не не не, не добавлю. Этот код оптимален. Там нечего улучшать.
Одно сравнение и одно присвоение все в местном контексте - идеально!

Просто все ваши аргументы пока основаны на "а вот если" и "а вот когда".
Я вас понимаю, ваш опыт часто подсовывал вам ситуации, где попадался тяжелый код внутри скроллинга и в итоге вы дуете на воду, постоянно и автоматом обвязывая debounce все, где видите onScoll, чтобы потом глаз не дергался ))
Ну или батарейка мобилок быстро не садилась

Но все равно спасибо, что обращаете на это внимание.
Давайте вернемся к сути, если надо обработать клавиатуру, мышь, пальцы, перо при скроллинге, все таки лучше вешаться на on:scroll={handleScroll} ? И там следить на deltaY

На скроллинге нету дельты.

Так что нужно либо отдельно пилить(для колесика, клавы и жестов) либо пожирнее вариант использовать.

Ну да. Для этого и завели
let scrollY, prevScrollY
bind:scrollY

А что значит вариант пожирнее?

Просто если onScroll покрывает всё (мышь, колесо, клаву, пальцы, перо) то это лучшее место для отслеживаний скролим  вверх или вниз