Как стать автором
Обновить

Комментарии 22

Тест:
var obj = {}; console.log(obj); obj.foo = 'bar';
Вывод в браузере
Object {}

Я пока не читал книгу, просто интересно было проверить знания. Почему он должен был вывести наполненный объект?
Книгу обязательно прочитаю.
Сорри, сейчас поправлю, здесь имеются ввиду webkit-овые браузеры. Хром, Сафари. У вас какой браузер?
Хром. Версия 29.0.1547.62 m
Вы, наверное, через консоль вводите код, в development tools. Попробуйте внутри странички (в теге script) или для простоты через какой-нибудь jsFiddle.
На самом деле так было до какой-то, довольно старой уже, версии.
Примерно год назад этот баг поправили, сейчас при открытой консоли хром выводит Object {}
Ага, точно. Вижу разное поведение, в зависимости от того, открыта ли консоль в момент работы кода.
Так это не вопрос асинхронности, а вопрос реализации консоли в конкретных браузерах. Так что хорошо бы вообще вопрос убрать из поста.
Сколько (примерно) раз сработает setInterval(func, 0) за секунду в браузере?
Ответ: Около 200

Да ладно :) Спецификация утверждает, что минимальный таймаут — 4ms, очень сомневаюсь, что практически ничего не делающая функция будет выполняться 1ms, итого получаем почти 250.
Ну да, согласен, ближе к 250. Здесь вопрос в округлении. У меня, например, хром вообще 252 выдал :)
И это тоже фактически особенность реализации. А если про спеки говорить, то ответ должен звучать как «не больше 250»
Поправил.
Не совсем так. Реализация таймеров в хроме вполне соответствует спецификации whatwg.


Let timeout be the second method argument, or zero if the argument was omitted.

If the currently running task is a task that was created by this algorithm, then let nesting level be the task's timer nesting level. Otherwise, let nesting level be zero.

If nesting level is greater than 5, and timeout is less than 4, then increase timeout to 4.

Increment nesting level by one.

Let task's timer nesting level be nesting level.


И это тоже фактически особенность реализации.


В хроме так, но мы вроде про асинхронности в JavaScript. С этой точки зрения знать надо одно — наличие милисекунд не говорит о том, что милисекунда — минимальный интервал. Это знание многих бы могло избавить от серьёхных проблем.
Если говорить про асинхронность в JavaScript, в спецификации ECMAScript вообще нет таймеров, как и ввода / вывода. Таймеры фактически особенность реализации ECMAScript в браузере и, например, на ноде. Для браузерных реализаций есть спецификации от w3c и whatwg, выдержку из последней я и привел. Согласно ей, может быть и 252, и 255 раз за секунду. Но в целом, если не вдаваться в такие подробности, минимальный таймаут в setTimeout / setInterval — 4ms, нужен 0 — setImmediate.
НЛО прилетело и опубликовало эту надпись здесь
Да, кстати, очень похоже на то.
Не помойка, а поисковая система XD
не бесплатная — это факт. В айТюнс за $10 её покупал. Автор (книги) вроде как на кикстартере для нее деньги собирал.
Первый вопрос к async относится постольку-поскольку. Вопрос, на самом деле,
про лексические замыкания, которые для асинхронщины безусловно полезны,
но применение которых этой самой асинхронщиной вовсе не ограничивается.
Имхо, если есть необходимость выполнять код, критически зависимый от времени (например, позицию перемещающегося объекта, который рисуется, например, на канвасе), имеет смысл использовать requestAnimationFrame (или если работа не с графикой — то обычный setTimeout) и полагатся на системный таймер и разницу во времени между вызовами функции. Помню, была у нас проблема, когда объекты перемещались неплавно. Пришлось писать своей механизм для выравнивания нестабильного квантования между вызовами.
Расскажите, пожалуйста, какой принцип использовался в Вашем механизме? Насколько я понимаю, js ни в каком случае не гарантирует стабильность квантования вызовов, слишком много факторов влияют — от загрузки проца до периодического вызова gc.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории