Comments 33
Ну к сожалению это не все))
Вот хоть убей, а я не понимаю, за что заминусовали статью! Автор постарался, разбирался в материале, потом постарался это всё изложить...ну что ж вы злые такие?
Наверное потому что эту тему разбирали на хабре уже много много раз.
Ну и тема тут на самом деле полностью не раскрыта.
Но ведь выже прочитали статью, которая "разбиралась много раз", раз уж утверждаете, что "тема полностью не раскрыта"? Для чего?
Мне не нужно читать ее полностью что бы понять что тема полностью не раскрыта.
По поводу того, что тема разбиралась много раз - введите в поиске async и посмотрите сколько статей уже было на эту тему.
А по каким признакам вы определили, что тема не раскрыта, если не прочитали статью полностью? Мне для собственного образования.
Ожидаемый вопрос. Я уже давно не читаю статьи полностью, а сразу смотрю основные тезисы. Если пропускать кучу воды, можно потратить время на чтение чего нибудь полезного. Вроде как это очевидно. И вроде как в моем понимании это не подходит под понятие полностью.
Я намекну на то чего нету в статье - случаи когда нельзя использовать async await вместо new Promise().
А что вы называете "основными тезисами"? Заголовки? Что, по-вашему, в этой статье было "основными тезисами", прочтение которых и дало вам возможность утверждать, что "тема полностью не раскрыта"?
Или вы искали в тексте именно использование "async await вместо new Promise()" и не нашли?
Или вы просто утверждаете, что "тема полностью не раскрыта" на том простом основании, что любую тему можно раскрыть ещё полнее?
Я вот, например, использую "скольжение по верхам", чтобы понять интересна мне статья или нет - сканирую текст глазами в ожидании, зацепится ли мозг за что-либо. Но я не пишу после этого комментарии. Хотя не могу не отметить, что ваш первый комментарий в этой ветке абсолютно корректен и его можно было смело написать даже без чтения этой статьи.
Подозреваю, что за поверхностность и легкомысленность типа “Да тут всё просто, я уже разобрался, ща покажу.” Т.н. “асинхронное программирование” никогда не было простой задачей, и что-то не демонстрирует тенденции к упрощению (при условии сохранения эффективности, которую оно может обеспечивать), Да, можно обвешать всё таймерами и ожиданиями, изрядно упростив себе жизнь, только толку от такой “асинхронности” будет не сильно больше, чем от single-thread app + blocking I/O.
Спасибо большое за комментарий, я постарался объяснить самые-самые азы, для тех кто только начинает и хотел бы что-то почитать на эту тему. Идти за более продвинутой информацией следует к документации. Я не преследовал цели пойти дальше и брать более сложные термины и все в этом духе, по крайней мере в этой статье)
Проблема в том, что статья содержит неверную информацию.
Во первых:
А асинхронный код может выполняться параллельно с другими задачами - это не так. Асинхронный код выполняется в один поток.
Во вторых:
Event Loop обеспечивает параллелизм в смысле возможности выполнять несколько операций одновременно, не блокируя основной поток выполнения. - Event loop тоже работает в один поток, любая тяжелая операция блокирует основной поток выполнения.
Без негатива. @Wilbemax Посмотрите на https://habr.com/ru/articles/762618/
Обратите внимание на
https://developer.mozilla.org/en-US/docs/Glossary/Thread https://developer.mozilla.org/ru/docs/Web/API/Web_Workers_API/Using_web_workers
Хм... а я кажись нашел источник ошибки
https://developer.mozilla.org/ru/docs/Web/JavaScript/Event_loop Статья на русском в начале разительно отличается от версии на английском. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Event_loop не зря там огромный баннер в начале с предупреждением.
Вот тут на русском вроде без косяков https://learn.javascript.ru/event-loop
Спасибо за комментарий и за конструктивное замечание, всё исправил и дополнил, спасибо!)
Асинхронный код в JavaScript выполняется в одном потоке, но не синхронно с основным потоком выполнения.
Если в одном, то почему написано, что запуская несколько асинхронных функций, можно добиться увеличения производительности? Поток же один?
С этим тоже непонятно - "событие кладётся на стек вызовов". На стек вызовов может класться обработчик события, но не само событие.
Как это - "event loop проверяет, не пустой ли стек вызовов"? Непонятно, это же все в одном главном потоке, разве нет? Как я понимаю, если управление передалось на event loop, то стек вызовов уже пустой по определению.
"Вызовется через 2 секунды" - после чего через две? После того, очевидно, как вызовется содержимое setTimeout, а оно вызовется далеко не мгновенно, а когда дойдёт очередь в очереди задач/событий до этой макрозадачи. А дойти она может только через 2+ секунды. Или нет?
В примере перед введением async/await вообще непонятно объяснение, почему "конец" напечатается раньше.
И вообще, во всех объяснениях хорошо бы добавить инфу, что происходит с очередью задач/событий (это же одна очередь?) и на каком потоке (просто с неким выдуманным id) исполняется тот или иной код.
В общем, текст больше нагнал тумана чем рессеял.
Увеличение производительности при использовании асинхронного кода в одном потоке: Да, асинхронный код в JavaScript выполняется в одном потоке. Однако, путем использования асинхронных операций, таких как асинхронные запросы к серверу или чтение файлов, можно сделать код более эффективным. Например, вместо блокирования потока выполнения на ожидании ответа от сервера, приложение может выполнять другие задачи, что повышает общую производительность.
"Событие кладётся на стек вызовов": Да, это неправильная формулировка. Событие само по себе не кладется на стек вызовов. Событие может инициировать вызов обработчика, который будет помещен на стек вызовов для выполнения.
Event Loop и проверка стека вызовов: Event Loop фактически проверяет, не пуст ли стек вызовов перед тем, как взять следующее событие из очереди и поместить его на стек вызовов. Это делается для того, чтобы обеспечить последовательное выполнение операций и избежать блокировки потока выполнения.
"Вызовется через 2 секунды": Да, это неправильная формулировка. Верно, что содержимое функции
setTimeoutбудет вызвано через 2 секунды после добавления в очередь событий. Таким образом, код после вызоваsetTimeoutбудет выполнен до истечения 2 секунд, а содержимоеsetTimeoutбудет выполнено после этого времени.Пример с async/await и порядок выполнения: Да, я согласен, порядок выполнения в примере с async/await не был объяснен ясно. В данном примере "Конец" выводится до выполнения асинхронной операции, так как асинхронная функция
myAsyncFunction()вызывается, но не блокирует выполнение кода дальше. Программа продолжает выполнение сразу после вызоваmyAsyncFunction(), и "Конец" выводится в консоль. После того, как асинхронная операция завершится, результат будет выведен в консоль.
Все эти аспекты важны для понимания работы JavaScript и его асинхронной модели выполнения. Спасибо за ваш отзыв, я учту ваши замечания при предоставлении объяснений в будущем. А данные формулировки постараюсь переписать по конкретнее, чтобы более не возникало таких вопросов при чтении)
Наверное потому, что кликбейтный заголовок ведёт к поверхностной статье по основам? Я был неприятно удивлён, когда после пересказа основ и пары примеров увидел "Заключение". Очередная мусорная статья, одним словом.
Мне, честно говоря, не хватило вывода результатов выполнения образцов кода.
Просто в текст вставлен пример, а затем просто слова в стиле "видно что выполнилось не в том порядке, хотя одно запущено раньше другого". Мне это не видно. Я могу только предположить из слов что наверное "Макрозадача" выведется раньше чем "Конец" хотя может и не это имелось ввиду...
А асинхронный код может выполняться параллельно
Вот это да, ничего себе!
Согласен, очень поверхностная статья с явными допущениями описанными выше в комментариях. Возможно она подошла бы для новичков, но тут опять нет практичных примеров кода.
Мне не понравилась статья, и показалась даже ужасной с точки зрения примеров. Так по описанию в первых двух примерах вроде получается, что все консоль логи выполняются синхронно по итогу (втф?). Подумал может я чего-то не правильно понимаю, скопировал примеры, выполнил и отпустило, все выполняется правильно, а совсем не так, как пишется в этой статье. Не проще ли было просто добавить блок с порядком вывода логов?
Спасибо за комментарий, не мог ли бы ты конкретно сказкть, в каком блоке не ясно выраженно, что будет отображаться первым , чтобы я смог добавить комментарий и разъяснить подробнее)
У вас про микротаски написано, с одной стороны, что они ставятся в очередь после основной задачи, но до рендеринга, а потом под спойлером в примере вы пишете, что колбэки промисов будут вызваны всё-таки до того, как выведется "конец".
Ваше замечание верно. В JavaScript микрозадачи, такие как обработчики промисов, выполняются после того, как текущий стек вызовов завершил свою работу, но до следующего события цикла событий (event loop) или рендеринга браузера. Это означает, что они выполняются в так называемом "макрозадаче" или "макротаске", которая включает в себя весь блок кода, выполняемый без прерывания, например, выполнение функции или обработчик события.
Сначала выполняется console.log('Начало'), затем создается разрешенный промис с помощью Promise.resolve(). После этого добавляются обработчики .then(), которые ставятся в очередь микрозадач. Затем выполняется console.log('Конец').
Это происходит потому, что обработчики .then() добавляются в очередь микрозадач, которая выполняется после того, как текущий стек вызовов завершил свою работу, но до следующего события цикла событий или рендеринга браузера. Это позволяет асинхронным операциям, таким как промисы, выполняться без блокировки основного потока выполнения кода, что улучшает производительность и отзывчивость веб-приложений.
Надеюсь данным дополнением, я сомг устранить недопонимание)
Почему в программировании асинхронность называется синхронностью, а синхронность асинхронностью?
Очень хочется увидеть пример, в котором разом запускаются 2 промиса, а, когда в одном из них стреляет ошибка, исполнение второго завершается.
Ты наконец-то поймешь асинхронность в JS