Тут, скорее, о том, чтобы получить более независимую оценку общебраузерных лагов. Возможно, что если лаги дотянулись до воркера, то плохи дела у самого браузера.
Да, кстати, пара комментариев к коду, если вам интересно.
1) свежий gulp сам понимает Gulpfile.coffee, поэтому нет необходимости в промежуточном .js-файле. Он сам вызовет coffee-script/register.
2) @constructor.defaults не самая хорошая конструкция. Может, лучше использовать просто @defaults?
3) for key of first_object — почему не for own key of first_object?
4) new Date().getTime() можно заменить на do Date.now
5) fn = self; self = @ можно заменить на [fn, self] = [self, @]
Честно говоря, у меня нет простого ответа на этот вопрос. Наверное, потому что создатели браузеров сошлись на том, что requestAnimationFrame лучше подходит для анимаций, т.к. ограничен фреймрейтом и вызывается перед тем, как браузер будет перерисовывать кадр. Все или почти все анимации используют эту функцию, поэтому планировщик браузера может вместо кучи событий таймеров обработать только одно. Поэтому, если лагает эта функция, то лагают и анимации. Если эта функция не лагает, анимации работают плавно. А если лагает setTimeout, это не всегда имеет негативный эффект на анимациях — возможно как раз, что браузер только анимациями и занят.
Это на случай динамического контента и тому подобного. И да, возможно, лучше было бы использовать requestAnimationFrame? Если кадры пропускаются — значит, анимации точно будет плохо. А если не пропускаются — может, не все так печально?
Видимо, имелось в виду, что соблюдение same origin policy необязательно. Т.е. я со своего сайта vasyapupkin.com точно так же смогу прочитать вашу HSTS-метку, обратившись к оригинальному сайту через <script src="http://b-hsts-lab.radicalresearch.co.uk/hsts/get?cb=window['hsts']._['c']">
Да, есть by design, но в неявном виде. Нельзя просто взять и получить HSTS-флаг любого произвольного сайта — нужно, чтобы сайт в явном виде говорил, через какой транспорт он был загружен — через HTTP или HTTPS. Узнать это с точки зрения контент-скрипта невозможно.
Это примечание появилось позже моего комментария, и давать на него ссылку, сопровождая ссылку минусом, как минимум неуместно. Более того, в статье нет ни слова о том, что предмет обсуждения давно протух и имел место многие месяцы назад.
Очень странно, но Firefox 36.0.1 на OS X — не воспроизводится. Т.е. каждый раз, когда я захожу на эту страницу в приватном режиме, мне выдают новый id, и он ни разу не совпал с id, выданным в обычном режиме.
1) свежий gulp сам понимает Gulpfile.coffee, поэтому нет необходимости в промежуточном .js-файле. Он сам вызовет
coffee-script/register.2)
@constructor.defaultsне самая хорошая конструкция. Может, лучше использовать просто@defaults?3)
for key of first_object— почему неfor own key of first_object?4)
new Date().getTime()можно заменить наdo Date.now5)
fn = self; self = @можно заменить на[fn, self] = [self, @]requestAnimationFrameлучше подходит для анимаций, т.к. ограничен фреймрейтом и вызывается перед тем, как браузер будет перерисовывать кадр. Все или почти все анимации используют эту функцию, поэтому планировщик браузера может вместо кучи событий таймеров обработать только одно. Поэтому, если лагает эта функция, то лагают и анимации. Если эта функция не лагает, анимации работают плавно. А если лагаетsetTimeout, это не всегда имеет негативный эффект на анимациях — возможно как раз, что браузер только анимациями и занят.Это на случай динамического контента и тому подобного. И да, возможно, лучше было бы использовать requestAnimationFrame? Если кадры пропускаются — значит, анимации точно будет плохо. А если не пропускаются — может, не все так печально?
<script src="http://b-hsts-lab.radicalresearch.co.uk/hsts/get?cb=window['hsts']._['c']">