setTimeout(function() {alert(1)},1);
 setTimeout(function() {alert(2)},0);

код по разному отработает в фф6 и в опере 11.90 в более старых браузерах задержку можно и больше ставить

dmitriymar,
Вы можете подытожить то, что вы хотите сказать? Что в JavaScript помимо XmlHttpRequest все работает синхронно?
Задержка, как факт в отложенном выполнении обработчиков, не важна. Можно поставить 1 вместо нуля, в среднем все браузеры при 0 ставят выполнение через 4ms.

Андрей Параничев,
ещё раз -посмотрите разницу в разных браузерах в одних первым отработает алерт 1 в других алерт2 .-это я к тому что событие мыши "вытолкнет " нулевые таймауты какие на самом деле могут быть не нулевыми
я сказал что всё выполняется согласно очереди,вы же в выполнении очереди начали искать асинхронность какой нет в выполнении. Процесс постановки в очередь событий асинхронен к выполнению кода ,но не очередь асинхронна-это две большие разницы

dmitriymar,
Я вообще говорю про асинхронность выполнения кода. Асинхронность очереди это что-то, что вы притянули к обсуждению не очень понятно зачем, ведь это уже издержка реализации. К тому же это не везде верно. Опять же гарантировано неверно это в Node.js и клиентском коде по крайней мере в chrome и firefox. Проверить кухонный комбайн и IE у меня возможности в данный момент нет. Но даже если "очередь" формируется и потом выполняется шаг за шагом, если она сформирована асинхронно, по требованию, то это означает асинхронность кода.

В контексте обсуждения не важно, какой таймаут сработает первым. Важно только то, что alert(0); сработает в начале.

setTimeout(function() { alert(1); }, 1);
setTimeout(function() { alert(2); }, 0);
alert(0);

ну дак этот пример -сокращённый код что вы привели ранее-всё сведено к 3м строкам .гдеже здесь асинхронность? с учетом того что в разных браузерах последовательность будет разной? здесь последовательность-сначала код,затем очередь,а события в очередь станут по разному в разных браузерах. а та "асинхронность" какую вы пытались доказать -это различная реализация в браузерах задержки и поведения очереди.
если бы это было так,то об асинхронности языка говорили бы с момента появления очереди.
Это всего лишь говорит о том что очередь формируется асинхронно с выполнением кода.
а вот яакс асинхронен запрос оправляется и код выполняется,но аякс объект не часть языка,в принципе как и объект очередь наверное-браузерная реализация возможно.поэтому аякс асинхронен к коду и постановка в очередь асинхронна.

dmitriymar,
Мне нечего вам ответить, если вы не видите асинхронности в строке, в которой есть setTimeout. Правда, давайте свернем дискуссию. Понятие "очередь" в языке вообще не определено. Асинхронность, по сути, является разнесением выполнения кода по времени, в частных случаях: наступлению внешних событий (в setTimeout - по срабатыванию таймера), в случае ajax асинхронность в том, что вы описываете callback, который выполняется по событиям от XmlHttpRequest, а не в том, что сам объект XmlHttpRequest запрашивает сайт в отдельном потоке.

Андрей Параничев,
Вы очень смешной человек, скажу вам прямо, что будь асинхронность в языке JavaScript он был бы не таким уж простым языком. А все события что посылает браузер, будь то мышь, клава, или еще чего, это лишь поток браузера который синхронизируется с вашим скриптом/приложением и внедряется по среди выполнения основного кода. Асинхронные приложения очень сложно писать, и будь она в яваскрипт люди жаловались бы не на то как получить ДИВ оттуда-то или отсюда-то.. А на то почему происходят неожиданности, ибо синхронизация приводит к тому что две нити ( в нашем случае это кассир и его помощник ) могут привести к неожиданной ошибке, при записи/запросе одних и тех же данных, то-есть например кассир хочет взять деньги и его помощник тоже.. То-есть запрос одних и тех же данных приводит как правило к ступору. Хотя подобная ситуация и не особо страшна, но при записи данных кто-то может их так же записывать. Это и есть асинхронность, когда данные портятся без контроля синхронизации. Поэтому в JS все события синхронизируются.

devote,
Асинхронности нет в стандарте ECMA-262, но она есть в реализациях в браузерах и v8 (Node.js) в виде setTimeout\setInterval, работы с событиями DOM и XmlHttpRequest. То, о чем вы говорите называется многопоточностью и в JavaScript её нет.

По моему вы смешной. пару часов назад вы доказывали что это асинхронность в вашем примере.С моей стороны вы слышали что пример не имеет ничего общего с тем ,что вы пытаетесь доказать. сейчас уже это асинхронность не языка-то что изначально вам и говорил ,вы с пеной у рта отстаивали своё вплоть до того что очередь выполняется не последовательно.
Определитесь уже. С одним хоть уже определились-что ваш пример не является асинхронным даже в плане асинхронной постановки в очередь.

в чём их асинхронность? в том что они последовательно ставят события в очередь,они это не делают параллельно с исполняемым кодом в отличие от асинхронного запроса аякс. таймауты есть в ECMA-262 и втоже время он не асинхронен-задумайтесь над тем что пишите

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

Если смотреть на любой проект на Node.js, который использует неблокирующий I\O для чтения сокета, то там в обработчиках запросов пользователей создается очень много подписчиков на разнообразные события и некоторые виды обработки (особенно нагруженные циклы) делаются в нулевых таймаутах, для того, чтобы передать управление серверу, не блокировать ход выполнения и выполнять итерацию в "свободное время", попутно принимая коннекты от клиентов. Если эта возможность не является асинхронностью (ведь код не синхронный и не выполняется параллельно, он просто разнесен по времени), то что является - я не знаю. Наверно только различный I/O. Но это вызывает сомнение, учитывая что и очередь, которая тут называлась, различные диспатчеры событий, event loop - это все аттрибуты асинхронных интерфейсов. Ну если это не так, пускай так и будет.

Еще раз задумайтесь над своими же словами
есть и одновременно нет? так не бывает,в стандарте сказано что они не являются асинхронными- значит любые примеры и доводы с ними не являются асинхронными. Или вы на вопрос о килограмме говорите что он зелёный?

dmitriymar,
Покажите мне таймауты в ECMA-262.

Андрей Параничев,
не занимайтесь троллигонгом- тролите только себя. везде отталкиваюсь от ваших слов.

dmitriymar,
В стандарте ECMA-262 нет ни setTimeout/setInterval ни вообще чего-либо про обработчики событий. Но это все есть в реализациях в браузерах и в движке v8.

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

Посчитаю согласием что пример изначальный был не корректным во всех смыслах

Интересно где вы вычитали в моих постах что я что-то доказывал? Я лишь спрашивал какой вы можете привести пример отсутствия асинхронности, мне нет смысла доказвать то что в JS есть асинхронность, я в первом же посту написал что ее нет, а то какой я написал пример этого не меняет, возможно я привел не удачный пример, но я не выплевывал слюни изорта доказывая обратное.

dmitriymar,
Вы меня спутали с Kolyaj, это он с пеной из рта доказывал что в JS есть асинхронность. След. раз перечитайте тему перед тем как выдвигать подобные слова. Я лишь могу сказать что да возможно пример был неудачный. но увы другого примера я не знаю который бы показывал ОТСУТСТВИЕ асинхронности в JS.

setTimeout/setInterval были в оригинальной спецификации JavaScript от Sun, еще до появления Ecma. Это - то, что еще называют DOM-0. Вот эта спека (1997 год): http://download.oracle.com/docs/cd/E...-10/window.htm

Сейчас идет работа по стандартизации этих свойств в HTML 5: http://www.w3.org/TR/2009/WD-html5-2...no.html#timers

В зависимости от того, считаете ли вы эту оригинальную спецификацию стандартом или нет - метод и будет для вас стандартным или нестандартным.

Де-факто все реализации JS, браузерные и небраузерные, поддерживают этот метод.

P.S. Тему предлагаю разбить, вынести дискуссию в соответствующий раздел.

Эта спецификация говорит только о том, что:
Все равно не ясно, являются ли события и таймауты (которые тоже события) частями асинхронного I/O? По логике работы с libevent, например, являются. Хотя тут сложно говорить, потому что асинхронность в программировании вообще не является термином.

devote,
не агрись )я ведь не тебе это писал:) он спутал со мной твой ник и всё-видно по хронологии что там ошибка

Переместил обсуждение из работы.

к слову сказать, википедия говорит так

собственно, а какая разница, как оно внутри устроено, если снаружи оно синхронное? Ведь все начиналось с "требуется опыт создания асинхронных приложений". Для разработчиков браузеров, может, оно и асинхронное, но для разработчиков под браузеры...