Соглашусь с вами. Коментарий ivan386 натолкнул меня на размышления, и я был совсем даже не прав в этой статье. И даже подумываю разгромить себя же в следующей. Скажу вам так — вы очень много где правы, но пользуясь только Chrome вы понемногу начинаете презирать другие браузеры. Chrome лучший не во всем, хотя и я сам в основном им пользуюсь.
Вы очень не правы тут:
Соответственно, 60 вызовов функции перерисовки внутри браузера.
И даже тут:
Так в чем профит-то? IE11?
Каждый браузер важен на столько, на сколько им пользуются именно ваши посетители ресурса.
И я был не прав тут:
Так как часы отсчитывают время CSS-ом, то если забить тред какими-то тяжёлыми заданиями — часы перестанут идти и когда страница освободится — будут отставать.
Хотя зависит от реализации keyframe в браузере. Но многим такие вещи не по чем.
Скажу вам больше, мы все очень много не знаем про браузеры. Лично меня комментарии к этой статье заставили усомниться в своем понимании роботы браузеров, и даже в том что нам про них (не)говорят разработчики.
Я с вами согласен. Но все о чем мы сейчас спорим есть в статье. Возможно проблема в том, что я не раскрыл эти проблемы полностью, тогда извиняюсь, это моя первая публичная статья и я постараюсь следующие сделать лучше, возможно даже стоит поправить эту.
Но, лично у меня пока сложилось впечатление, что вы пробежались по статье не вчитываясь в детали.
На счет нагрузок уже отписывал, но все же
Я не знаю как себя поведет CSS при нагрузках процессора, я поэксперементирую с этим и сообщу вам результат. Но, хорошо сделанная страница не должна нагружать поток на столько, чтобы часы сильно отставали (больше 5 секунд разницы в час), а такими малыми отклонениями можно пренебречь.
Также, ради эксперимента оставлял вкладку с часами открытой, пока было запущено пару тяжелых процессов и еще 20 вкладок и часы за 2 часа так и не отстали.
В случае сна и гибернации — ничего не гарантирую. Но можно переопределять CSS классы при возвращении пользователя на страницу, много проблем это не вызовет.
Сама статья — это все лишь концепт, а не готовое решение.
Я очень сомневаюсь что хоть одна читалка будет рада ежесекундному изменению времени. Я работал пару раз с читалками и для них достаточно важно не изменять контент без надобности. Да и представте себе — читалка еще не успела прочитать время, а вы уже его поменяли 5 раз.
Я бы сказал, что для читалок лучше спрятать такой элемент (aria-hidden=«true») и создать скрытый элемент где мы меняем время раз в минуту.
На счет нагрузок — да. Я не знаю как себя поведет CSS при нагрузках процессора, я поэксперементирую с этим и сообщу вам результат. Но, хорошо сделанная страница не должна нагружать поток на столько, чтобы часы сильно отставали (больше 5 секунд разницы в час), а такими малыми отклонениями можно пренебречь.
Также, ради эксперимента оставлял вкладку с часами открытой, пока было запущено пару тяжелых процессов и еще 20 вкладок и часы за 2 часа так и не отстали.
В случае сна и гибернации — ничего не гарантирую. Но можно переопределять CSS классы при возвращении пользователя на страницу, много проблем это не вызовет.
Сама статья — это все лишь концепт, а не готовое решение.
Не совсем, не забывайте, что вы вызываете функцию каждую секунду, и если вам это кажется мелочью — придставте если их будет 10, а может и больше. И да, сами CSS переменные — прекрасный инструмент и никаких нагрузок не вызывают, но может все же не стоит переносить на CSS переменные и JS то, с чем сам по себе справляются CSS?
Также, как человек, который всегда на проектах имеет дело с IE 11 и старше, для меня очень важна поддержка старых браузеров и высокая производительность, чего собственно я и добивался в этой статье.
Здравствуйте, рекомендуймый FPS для страницы, не зависимо от контента — 60. И к сожалению, так с ходу, я не могу вам сказать почему в данном случае он 50, но факт остается факто — мы пишем в DOM с помощью JS каждую секунду и это нагружает главный поток. Кроме того наше переопределение CSS переменных вызывает перерасчет некоторых CSS аттрибутов, что нагружает главный поток опять.
Интереса ради я просто попробовал изменять CSS переменные каждую секунду в пустой странице, и даже так у меня появлялись странный просадки FPS, хотя не так частые. Я не утверждаю что не стоит вообще не использовать CSS переменные, просто возможно не стоит только ради часов нагружать главный поток.
На счет вашей функции сверху — она покажет FPS на основе только одного кадра, что не говорит ни о чем. Чтобы узнать точное FPS нужно считать среднее значение хотя бы 100 кадров. А так, это как говорить, что все люди выше 2 метров на основании роста Шакила О'Нила. Потому, простите, по Хром тут точно лучше обчистил FPS.
JavaScript был использован только для инициализации часов, создания начальных стилей. Сами часы идут только на основе CSS анимации.
Но если вас интересует только CSS+HTML часы — можно перенести создание CSS анимации на серверную часть, к примеру можно сгенерировать те же стили при помощи PHP, тогда на стороне клиента все будет работать даже если отключены скрипты.
Я кстати об этом упоминал в статье:
И так у нас два варианта, либо на стороне сервера рендерить CSS относительно времени запроса, либо использовать JavaScript. Конечно сервер рендеринг и без скриптовые часы это круто, но ради подтверждения концепта мы все же используем JavaScript.
Вы очень не правы тут:
И даже тут:
Каждый браузер важен на столько, на сколько им пользуются именно ваши посетители ресурса.
И я был не прав тут:
Хотя зависит от реализации keyframe в браузере. Но многим такие вещи не по чем.
Скажу вам больше, мы все очень много не знаем про браузеры. Лично меня комментарии к этой статье заставили усомниться в своем понимании роботы браузеров, и даже в том что нам про них (не)говорят разработчики.
Но, лично у меня пока сложилось впечатление, что вы пробежались по статье не вчитываясь в детали.
Я бы сказал, что для читалок лучше спрятать такой элемент (aria-hidden=«true») и создать скрытый элемент где мы меняем время раз в минуту.
На счет нагрузок — да. Я не знаю как себя поведет CSS при нагрузках процессора, я поэксперементирую с этим и сообщу вам результат. Но, хорошо сделанная страница не должна нагружать поток на столько, чтобы часы сильно отставали (больше 5 секунд разницы в час), а такими малыми отклонениями можно пренебречь.
Также, ради эксперимента оставлял вкладку с часами открытой, пока было запущено пару тяжелых процессов и еще 20 вкладок и часы за 2 часа так и не отстали.
В случае сна и гибернации — ничего не гарантирую. Но можно переопределять CSS классы при возвращении пользователя на страницу, много проблем это не вызовет.
Сама статья — это все лишь концепт, а не готовое решение.
Также, как человек, который всегда на проектах имеет дело с IE 11 и старше, для меня очень важна поддержка старых браузеров и высокая производительность, чего собственно я и добивался в этой статье.
Интереса ради я просто попробовал изменять CSS переменные каждую секунду в пустой странице, и даже так у меня появлялись странный просадки FPS, хотя не так частые. Я не утверждаю что не стоит вообще не использовать CSS переменные, просто возможно не стоит только ради часов нагружать главный поток.
На счет вашей функции сверху — она покажет FPS на основе только одного кадра, что не говорит ни о чем. Чтобы узнать точное FPS нужно считать среднее значение хотя бы 100 кадров. А так, это как говорить, что все люди выше 2 метров на основании роста Шакила О'Нила. Потому, простите, по Хром тут точно лучше обчистил FPS.
Но если вас интересует только CSS+HTML часы — можно перенести создание CSS анимации на серверную часть, к примеру можно сгенерировать те же стили при помощи PHP, тогда на стороне клиента все будет работать даже если отключены скрипты.
Я кстати об этом упоминал в статье:
Простите, что не уточнил сразу в статье.