Асинхронный JavaScript — Изучение веб-разработки

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

Необходимые знания

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

Если вы ещё не знакомы с концепциями асинхронного программирования, вам стоит начать со статьи Основные концепции асинхронного программирования в этом модуле. А если уже знакомы, то можете сразу переходить к статье Введение в асинхронный JavaScript.

Заметка: Если вы работаете за компьютером/планшетом/другим устройством где у вас нет возможности создавать собственные файлы, вы можете попробовать(почти все) примеры кода в одном из веб-приложений, таких, как JSBin или Thimble.

Руководства

Основные концепции асинхронного программирования

В этой статье мы пройдёмся по нескольким важным концепциям касающихся асинхронного программирования, и того как это выглядит в браузерах и JavaScript. Вы должны усвоить эти концепции прежде чем изучать другие статьи в этом модуле.

Введение в асинхронный JavaScript

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

Кооперативная асинхронность в JavaScript: Таймауты и интервалы

Здесь мы рассматриваем традиционные методы JavaScript, которые позволяют запускать код асинхронно по истечению заданного времени, или с регулярным интервалом (например: заданное количество раз в секунду), обсудим их пользу, а так же их неотъемлемые проблемы.

Изящная обработка асинхронных операций с Промисами

Промисы это достаточно новая функция в языке JavaScript, которая позволяет вам откладывать дальнейшие операции, пока предыдущая не выполнится, или реагировать на её неудачное выполнение. Это очень полезно, для установки нужной последовательности операций для корректной работы. Эта статья показывает как работают промисы, и вы рассмотрите то, как они работают в WebAPIs, и узнаете как писать свои собственные.

Делаем асинхронное программирование проще с async и await

Промисы могут быть достаточно сложными для написания и понимания, поэтому современные браузеры ввели функцию async и оператор await — где первый позволяет стандартным функциям неявно асинхронно работать с промисами, а последний может использоваться внутри async функций, для ожидания промиса, прежде чем функция продолжит свою работу, что делает работу с промисами проще и улучшает читабельность кода.

Выбор правильного подхода

В завершение этого модуля, мы рассмотрим технологии и функции, которые мы обсуждали, рассмотрим когда и где их надо использовать. А так же дадим рекомендации и расскажем о распространённых подводных камнях, там где это будет необходимо.

Смотрите также

developer.mozilla.org

Асинхронный JavaScript против отложенного / Habr

В моей статье «Понимание критического пути рендеринга» (перевод статьи) я писала о том, какой эффект оказывают JavaScript-файлы на Критический Путь Рендеринга(CRP).

JavaScript является блокирующим ресурсом для парсера. Это означает, что JavaScript блокирует разбор самого HTML-документа. Когда парсер доходит до тега <script> (не важно внутренний он или внешний), он останавливается, забирает файл (если он внешний) и запускает его.

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

К счастью, элемент <script> имеет два атрибута async и defer, которые дают нам возможность контролировать то, как внешние файлы загружаются и выполняются.

Нормальное выполнение

Прежде чем понять разницу между этими двумя атрибутами, давайте посмотрим что происходит в их отсутствие. Как было сказано ранее, по умолчанию файлы JavaScript прерывают парсинг HTML-документа до тех пор, пока не будут получены и выполнены.
Возьмём пример, в котором элемент <script> расположен где-то в середине страницы:

<html>  
<head> ... </head>  
<body>  
    ...
    <script src="script.js">
    ....
</body>  
</html> 

Вот что произойдёт, когда парсер будет обрабатывать документ:

Парсинг HTML приостанавливается, пока скрипт не будет загружен и выполнен, тем самым увеличивая количество времени до первой отрисовки.

Атрибут async

Async используется для того, чтобы указать браузеру, что скрипт может быть выполнен асинхронно.
Парсеру HTML нет необходимости останавливаться, когда он достигает тега <script> для загрузки и выполнении. Выполнение может произойти после того, как скрипт будет получен параллельно с разбором документа.

<script async src="script.js">  

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

Атрибут defer

Атрибут defer указывает браузеру, что скрипт должен быть выполнен после того, как HTML-документ будет полностью разобран.

<script defer src="script.js">

Как и при асинхронной загрузке скриптов — файл может быть загружен, в то время как HTML-документ парсится. Однако, даже если файл скрипта будет полностью загружен ещё до того, как парсер закончит работу, он не будет выполнен до тех пор, пока парсер не отработает до конца.

Асинхронное, отложенное или нормальное выполнение?

Итак, когда же следует использовать асинхронное, отложенное или нормальное выполнение JavaScript? Как всегда, это зависит от ситуации и существуют несколько вопросов, которые помогут принять вам правильное решение.

Где расположен элемент <script> ?

Асинхронное и отложенное выполнения наиболее важны, когда элемент <script> не находится в самом конце документа. HTML-документы парсятся по порядку, с открытия <html> до его закрытия. Если внешний JavaScript-файл размещается непосредственно перед закрывающим тегом </body>, то использование async и defer становится менее уместным, так как парсер к тому времени уже разберёт большую часть документа, и JavaScript-файлы уже не будут оказывать воздействие на него.

Скрипт самодостаточен?

Для файлов, которые не зависят от других файлов и/или не имеют никаких зависимостей, атрибут async будет наиболее полезен. Поскольку нам не важно, когда файл будет исполнен, асинхронная загрузка — наиболее подходящий вариант.

Полагается ли скрипт на полностью разобранный DOM?

Во многих случаях файл скрипта содержит функции, взаимодействующие с DOM. Или, возможно, существует зависимость от другого файла на странице. В таких случаях DOM должен быть полностью разобран, прежде чем скрипт будет выполнен. Как правило, такой файл помещается в низ страницы, чтобы убедиться, что для его работы всё было разобрано. Однако, в ситуации, когда по каким-либо причинам файл должен быть размещён в другом месте — атрибут defer может быть полезен.

Скрипт небольшой и зависим?

Наконец, если скрипт является относительно небольшим и/или зависит от других файлов, то, возможно, стоит определить его инлайново. Несмотря на то, что встроенный код блокирует разбор HTML-документа, он не должен сильно помешать, если его размер небольшой. Кроме того, если он зависит от других файлов, может понадобиться незначительная блокировка.

Поддержка и современные браузерные движки

Поддержка атрибутов async и defer очень распространена:

Стоит отметить, что поведение этих атрибутов может немного отличаться в разных движках JavaScript. Например, в V8 (используется в Chromium), сделана попытка разобрать все скрипты, независимо от их атрибутов, на отдельном выделенном потоке для выполнения скрипта. Таким образом, «блокирующая парсер» природа JavaScript-файлов должна быть минимизирована по умолчанию.

habr.com

Асинхронность в javascript

Асинхронность в javascript — представляет собой правило в соответствии с которым блоки JS кода обрабатываются браузером параллельно с загрузкой DOM — т.е. структуры веб-страницы или после загрузки DOM.

 

 

Код на JS, как известно, помещается между тегами <script> </script>. При этом код может содержаться как в HEAD документа, так и в BODY — при этом в любой части документа. Также javascript можно подгружать с других доменов.

 

Обычно JS помещают в конце страницы именно из тех соображений, что на обработку кода уходит определенное время — загрузка страницы при этом приостанавливается — DOM не может загрузиться поскольку ждет завершения исполнения скритпа на javascript.

 

 

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

 

 

Чаще всего посетитель с сайта, страница которого перестала загружаться на половине уйдет не дождавшись пока скрипт отработает до конца. Задержки, таким образом, очень нежелательны.

 

 

Чтобы исправить эту ситуацию предусмотрена опция async, позволяющая загружать JS асинхронно. Структура документа при использовании документа и все элементы страницы не будут ждать завершения исполнения скрипта.

 

Скрипт инициируется, страница продолжит загружаться даже если скрипт не завершил свою работу. Какой-то функционал страницы при этом может работать некорректно (если в javascript допущены ошибки) — в целом же страница загружается и посетитель сайта может с ней работать.

 

 

Стоит отметить, что async не поддерживается некоторыми версиями Internet Explorer, но поскольку пользуется им очень маленькое количество пользователей — обычно имеет смысл этим пренебречь и использовать асинхронность в javascript.

 

Альтернативой async может быть defer. При использовании данного атрибута скрипт будет исполняться только после того как загружен DOM.  Директива поддерживается всеми браузерами, ее особенность в том, что она обрабатывает JS скрипты в том порядке, в котором они подключаются.

 

Это может быть как плюсом, так и минусом. Если порядок выполнения скриптов принципиален — defer — лучшее решение.async можно принудительно отключить: script.async=false;

Минус в том, что если один скрипт, подключается с внешнего ресурса, который недоступен — остальные скрипты отрабатывать не будут. Они будут ждать этот независимо от того насколько он важен в целом.

 

 

server-gu.ru

Async/await это шаг назад для JavaScript’a? / Habr

В конце 2015 года я услышал об этой паре ключевых слов, которые ворвались в мир JavaScript, чтобы спасти нас от promise chain hell, который, в свою очередь, должен был спасти нас от callback hell. Давайте посмотрим несколько примеров, чтобы понять, как мы дошли до async/await.

Допустим, мы работаем над нашим API и должны отвечать на запросы серией асинхронных операций:
— проверить валидность пользователя
— собрать данные из базы данных
— получить данные от внешнего сервиса
— изменить и записать данные обратно в базу данных

Также давайте предположим, что мы не имеем каких-либо знаний о промисах, потому что мы путешествуем назад во времени и используем функции обратного вызова, чтобы обработать запрос. Решение выглядело бы примерно так:

function handleRequestCallbacks(req, res) {
  var user = req.user
  isUserValid(user, function (err) {
    if (err) {
      res.error('An error ocurred!')
      return
    }
    getUserData(user, function (err, data) {
      if (err) {
        res.error('An error ocurred!')
        return
      }
      getRate('service', function (err, rate) {
        if (err) {
          res.error('An error ocurred!')
          return
        }
        const newData = updateData(data, rate)
        updateUserData(user, newData, function (err, savedData) {
          if (err) {
            res.error('An error ocurred!')
            return
          }
          res.send(savedData)
        })
      })
    })
  })
}

И это так называемый callback hell. Теперь вы знакомы с ним. Все его ненавидят, так как его трудно читать, отлаживать, изменять; он уходит все глубже и глубже во вложенности, обработка ошибок повторяется на каждому уровне и т.д.

Мы могли бы использовать знаменитую async библиотеку, чтобы немного очистить код. Код стал бы лучше, так как обработка ошибок, по крайней мере, была бы в одном месте:

function handleRequestAsync(req, res) {
  var user = req.user
  async.waterfall([
    async.apply(isUserValid, user),
    async.apply(async.parallel, {
      data: async.apply(getUserData, user),
      rate: async.apply(getRate, 'service')
    }),
    function (results, callback) {
      const newData = updateData(results.data, results.rate)
      updateUserData(user, newData, callback)
    }
  ], function (err, data) {
    if (err) {
      res.error('An error ocurred!')
      return
    }
    res.send(data)
  })
}

Позже мы узнали как использовать промисы и подумали, что мир больше не злится на нас; мы почувствовали, что нужно провести рефакторинг кода еще раз, ведь все больше и больше библиотек также движется в мир промисов.

function handleRequestPromises(req, res) {
  var user = req.user
  isUserValidAsync(user).then(function () {
    return Promise.all([
      getUserDataAsync(user),
      getRateAsync('service')
    ])
  }).then(function (results) {
    const newData = updateData(results[0], results[1])
    return updateUserDataAsync(user, newData)
  }).then(function (data) {
    res.send(data)
  }).catch(function () {
    res.error('An error ocurred!')
  })
}

Это гораздо лучше, чем раньше, гораздо короче и намного чище! Тем не менее возникло слишком много накладных расходов в виде множества then() вызовов, function () {…} блоков и необходимости добавлять несколько операторов return повсюду.

И наконец мы слышим о ES6, обо всех этих новых вещах, которые пришли в JavaScript: например стрелочные функции (и немного деструктуризации, чтобы было чуть веселее). Мы решаем дать нашему прекрасному коду еще один шанс.

function handleRequestArrows(req, res) {
  const { user } = req
  isUserValidAsync(user)
    .then(() => Promise.all([getUserDataAsync(user), getRateAsync('service')]))
    .then(([data, rate]) => updateUserDataAsync(user, updateData(data, rate)))
    .then(data => res.send(data))
    .catch(() => res.error('An error ocurred!'))
}

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

И приходит async/await

Несколько месяцев спустя async/await выходит на сцену. Он собирался попасть в спецификацию ES7, затем идею отложили, но т.к. есть Babel, мы прыгнули в поезд. Мы узнали, что можем отметить функцию как асинхронную и что это ключевое слово позволит нам внутри функции «остановить» ее поток исполнения до тех пор, пока промис не решит, что наш код снова выглядит синхронным. Кроме того, функция async всегда будет возвращать промис, и мы можем использовать try/catch блоки для обработки ошибок.

Не слишком уверенные в пользе, мы даем нашему коду новый шанс и идем на окончательную реорганизацию.

async function asyncHandleRequest(req, res) {
  try {
    const { user } = req
    await isUserValidAsync(user)
    const [data, rate] = await Promise.all([getUserDataAsync(user), getRateAsync('service')])
    const savedData = await updateUserDataAsync(user, updateData(data, rate))
    res.send(savedData)
  } catch (err) {
    res.error('An error ocurred!')
  }
}

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

Функциональная парадигма программирования

Хотя функциональное программирование было вокруг нас в течение более чем 40 лет, похоже что совсем недавно парадигма стала набирать обороты. И лишь в последнее время мы стали понимать преимущества функционального подхода.

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

Мы продолжаем свое плавание в море функциональной парадигмы программирования и начинаем видеть ее реальную ценность. Эти сторонники функционального программирования не были просто сумасшедшими. Они были, возможно, правы!

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

Но… постойте!

Мы видели все эти функциональные модели в прошлом. Мы помним, как мы использовали обещания и как соединяли функциональные преобразования один за другим без необходимости управлять состоянием или ветвить наш код или управлять ошибками в императивном стиле. Мы уже использовали promise-монаду в прошлом со всеми сопутствующими преимуществами, но в то время мы просто не знали это слово!

И мы вдруг понимаем, почему код на основе async/await смотрелся странно. Ведь мы писали обычный императивный код, как в 80-х годах; обрабатывали ошибки с try/catch, как в 90-х годах; управляли внутренним состоянием и переменными, делая асинхронные операции с помощью кода, который выглядит как синхронный, но который внезапно останавливается, а затем автоматически продолжает выполнение когда асинхронная операция будет завершена (когнитивный диссонанс?).

Последние мысли

Не поймите меня неправильно, async/await не является источником всего зла в мире. Я на самом деле научился любить его после нескольких месяцев использования. Если вы чувствуете себя комфортно, когда пишете императивный код, научиться использовать async/await для управления асинхронными операциями может быть хорошим ходом.

Но если вы любите промисы и хотите научиться применять все больше и больше функциональных принципов программирования, вы можете просто пропустить async/await, перестать думать императивно и перейти к новой-старой функциональной парадигме.

См. также

→ Еще одно мнение о том, что async/await не такая уж хорошая вещь.

habr.com

Асинхронное программирование (полный курс) / Habr

Асинхронное программирование за последнее время стало не менее развитым направлением, чем классическое параллельное программирование, а в мире JavaSript, как в браузерах, так и в Node.js, понимание его приемов заняло одно из центральных мест в формировании мировоззрения разработчиков. Предлагаю вашему вниманию целостный и наиболее полный курс с объяснением всех широко распространенных методов асинхронного программирования, адаптеров между ними и вспомогательных проемов. Сейчас он состоит из 23 лекций, 3 докладов и 28 репозиториев с множеством примеров кода на github. Всего около 17 часов видео: ссылка на плейлист.

Пояснения к схеме

На схеме (выше) показаны связи между разными способами работы с асинхронностью. Цветные блоки относятся к асинхронному программированию, а ч/б показаны методы параллельного программирования (семафоры, мьютексы, барьеры и т.д.) и сети петри, которые, как и асинхронное программирование и модель акторов, являются разными подходами к реализации параллельных вычислений (они даны на схеме только чтоб точнее определить место асинхронного программирования). Модель акторов связана с асинхронным программированием потому, что реализация акторов без многопоточности тоже имеет право на существование и служит для структурирования асинхронного кода. Пунктирными линиями события и конкурентная очередь связаны с колбеками потому, что эти абстракции базируются на колбеках, но все же формируют качественно новые подходы.

Темы лекций

1. Асинхронное программирование (обзор)
2. Таймеры, таймауты и EventEmitter
3. Асинхронное программирование на callback`ах
4. Неблокирующее асинхронное итерирование
5. Асинхронность с библиотекой async.js
6. Асинхронность на промисах
7. Асинхронные функции и обработка ошибок
8. Асинхронные адаптеры: promisify, callbackify, asyncify
9. Асинхронные коллекторы данных
10. Необработанные ошибки в промисах
11. Проблема асинхронного стектрейса
12. Генераторы и асинхронные генераторы
13. Итераторы и асинхронные итераторы
14. Отмена асинхронных операций
15. Асинхронная композиция функций
16. Thenable и легковесный await
17. Конкурентная асинхронная очередь
18. Паттерн открытый конструктор (Revealing Constructor)
19. Future: Асинхронность на фьючерах без состояния
20. Deferred: Асинхронность на диферах с состоянием
21. Модель акторов (Actor Model)
22. Паттерн Наблюдатель (Observer + Observable)
23. Асинхронность на RxJS и потоки событий

Под каждым видео есть ссылки на репозитории с примерами кода, которые разбираются в видео. Я постарался показать, что не нужно сводить все к одной абстракции асинхронности. Универсального подхода к асинхронности не существует, а для каждого случая можно подобрать те методы, которые позволят писать код более естественно для этой конкретной задачи. Конечно же, этот курс будут дополняться и я прошу всех предлагать новые темы и контрибьютить в примеры кода. Основная задача курса — это показать как строить абстракции асинхронности изнутри, а не просто научить ими пользоваться. Практически все абстракции не берутся из библиотек, а даны в самой простой их реализации и пошагово разобрана их работа.

habr.com