Web workers что это

HTML5: Web Workers и AJAX

Все прочнее в среду разработчиков входит HTML5. Важным его достоинством является наличие такой технологии, как web workers, которая позволяет в некоторой степени обеспечить, если не мультипоточность, то ее подобие при выполнении скриптов.

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

Теперь о том, как использовать работников.
Проверим поддержку объекта браузером:

Создается объект очень просто:

созданный нами объект обладает следующими методами:

postMessage(); //ключевой метод, инициализирующий обмен данными
onmessage(); //метод, исполняемый при поступлении ответа от вызванного работника.
onerror(); //метод, вызываемый при возникновении ошибок

Теперь сделаем сам файлик worker`а и назовем его worker.js. Внутрь поместим следующий код:

Объект и файл у нас есть, теперь остается только его вызвать делается это так:

Переменная ev будет содержать объект, в свойстве data, которого будет находится то, что мы передадим в функцию, в нашем случае строка ‘Hello World’. Передавать можно что угодно, в том числе сложные объекты. Теперь сделаем, чтобы наш работник, что-нибудь нам вернул. Для этого в код работника последней строкой допишем следующее:

А в основном скрипте определим метод, который будет вызван при поступлении сообщения от работника:

Ещё надо добавить, что HTML5 позволяет создать Web Worker и без внешнего файла с помощью

Вот собственно и все! Вернуть работник нам также сможет любые данные. Стоит помнить о нескольких важных моментах, таких как:
1. Работник не может получить доступ к DOM ни в каком виде. Ни одна функция работающая с DOM получающая данные о его состоянии или модифицирующая его, внутри работника недоступна. В том числе alert().
2. Работник имеет доступ к:
2.1 navigator
2.2 объект location (только чтение)
2.3 метод importScripts() (для доступа к файлам сценариев в том же домене)
2.4 объекты JavaScript, такие как Object, Array, Date, Math, String
2.5 XMLHttpRequest
2.6 методы setTimeout() и setInterval()

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

А теперь о важном, о том, чего нет ни в одной статье про работников: для того чтобы получить адекватный ответ при использовании технологии AJAX, необходимо отсылать СИНХРОННЫЕ запросы методом POST. Причина проста: при асинхронном запросе воркер заканчивает работу не дожидаясь ответа сервера. Логического объяснения почему не шлется методом GET я так и не нашел. Беспокоиться о том, что все встанет, не стоит, так как работник выполняется в отдельном потоке, основной скрипт будет работать дальше без остановок.

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

Приведу свою реализацию данного подхода:
1.
объект отвечающий за связь с сервером:

UPD2:
По настойчивым просьбам yui_room9 привожу его альтернативный вариант работающий в браузерах на webkit

Источник

Прослушиватели событий и веб-воркеры

Недавно я разбирался с API Web Workers. Очень жаль, что я не уделил время этому отлично поддерживаемому инструменту раньше. Современные веб-приложения очень требовательны к возможностям главного потока выполнения JavaScript. Это воздействует на производительность проектов и на их возможности по обеспечению удобной работы пользователей. Веб-воркеры — это именно то, что в наши дни способно помочь разработчику в деле создания быстрых и удобных веб-проектов.

Момент, когда я всё понял

У веб-воркеров много положительных качеств. Но я по-настоящему осознал их полезность, столкнувшись с ситуацией, когда в некоем приложении используется несколько прослушивателей событий DOM. Таких, как события отправки формы, изменения размеров окна, щелчков по кнопкам. Все эти прослушиватели должны работать в главном потоке. Если же главный поток перегружен некими операциями, на выполнение которых нужно продолжительное время, это плохо отражается на скорости реакции прослушивателей событий на воздействия пользователей. Приложение «подтормаживает», события ждут освобождения главного потока.

Надо признать, что причина, по которой меня так заинтересовали именно прослушиватели событий, заключается в том, что я изначально неправильно понимал то, на решение каких задач рассчитаны веб-воркеры. Сначала я думал, что они могут помочь в деле повышения скорости выполнения кода. Я полагал, что приложение сможет сделать гораздо больше за некий отрезок времени в том случае, если какие-то фрагменты его кода будут выполняться параллельно, в отдельных потоках. Но в ходе выполнения кода веб-проектов весьма распространена ситуация, когда, прежде чем начать что-то делать, нужно дождаться некоего события. Скажем, DOM нужно обновить только после того, как завершатся некие вычисления. Я, зная это, наивно полагал, что, если мне, в любом случае, придётся ждать, это значит, что нет смысла переносить выполнение некоего кода в отдельный поток.

Вот пример кода, который тут можно вспомнить:

Тут я обновляю текст в поле после того, как завершатся некие вычисления, предположительно — длительные. Вроде бы бессмысленно запускать этот код в отдельном потоке, так как DOM не обновить раньше, чем завершится выполнение этого кода. В результате я, конечно, решаю, что код этот нужно выполнять синхронно. Правда, видя подобный код, я сначала не понимал того, что до тех пор, пока главный поток заблокирован, другие прослушиватели событий не запускаются. Это означает, что на странице начинают проявляться «тормоза».

Как «тормозят» страницы

Вот CodePen-проект, демонстрирующий вышесказанное.

Проект, демонстрирующий ситуацию, в которой страницы «тормозят»

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

Любому пользователю не понравится работать с сайтом, который ведёт себя так, как показано в предыдущем примере. А ведь тут используется всего несколько прослушивателей событий. В реальном мире речь идёт совсем о других масштабах. Я решил воспользоваться в Chrome методом getEventListeners и, применив следующий скрипт, выяснить количество прослушивателей событий, прикреплённых к элементам DOM различных страниц. Этот скрипт можно запустить прямо в консоли инструментов разработчика. Вот он:

Я запускал этот скрипт на разных страницах и узнавал о количестве используемых на них прослушивателей событий. Результаты моего эксперимента приведены в следующей таблице.

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

Избавление от «тормозов» с помощью веб-воркеров

Вот JS-код этого примера:

Если немного вникнуть в этот код, то можно заметить, что, хотя API Web Workers мог бы быть устроен и поудобнее, в работе с ним нет ничего особенно страшного. Вероятно, этот код выглядит страшновато из-за того, что перед вами — простой, быстро написанный демонстрационный пример. Для того чтобы повысить удобство работы с API и облегчить работу с веб-воркерами, можно воспользоваться некоторыми дополнительными инструментами. Например, мне показались интересными следующие:

Итоги

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

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

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

Уважаемые читатели! Пользуетесь ли вы веб-воркерами в своих проектах?

Источник

Простое введение в Web Workers в JavaScript

Дата публикации: 2019-08-29

Перенесемся почти на 25 лет вперед — теперь JavaScript овладел Сетью. У него есть профессиональные обязанности и, наконец, профессиональные качества. Одним из примеров этого являются Web Workers.

Web Workers предназначены для того, чтобы вы могли выполнять громоздкие задачи, не замораживая страницу. Например, представьте, что вы хотите выполнять сложные вычисления, когда кто-то нажимает кнопку. Если вы начнете выполнять эту задачу сразу же, вы все заблокируете. Человек, использующий страницу, не сможет прокрутить ее вниз или кликнуть что-либо. Они могут даже получить страшное сообщение об ошибке «эта страница не отвечает».

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

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

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

Web Workers позволяют выполнять любую трудоемкую работу в фоновом режиме. Процесс прост:

Вы создаете web worker.

Вы говорите web worker, что делать. (Например, заняться этими числами!)

Вы запускаете web worker.

Когда web worker готов, он говорит вам об этом, и оттуда приходит код. (Например, показать результаты на странице.)

Давайте рассмотрим все подробнее!

Создание трудоемкой задачи

Прежде чем вы сможете увидеть преимущества web worker, вам нужно написать действительно медленный код. Нет смысла использовать web worker для быстрых задач, потому что они не блокируют страницу.

Рассмотрим, например, поиск простых чисел, показанный ниже. (Он размещен на CodePen, так что вы можете попробовать его, посмотреть код и даже внести изменения.)

В этом примере используются простые числа, попадающие в заданный диапазон. Вы выбираете диапазон, используя два текстовых поля на странице. Выберите относительно узкий диапазон (скажем, от 1 до 100 000), и задача будет выполнена за считанные секунды, не доставляя никому неудобств. Но запустите более широкий поиск (скажем, от 1 до 1 000 000), и ваша страница может перестать отвечать на секунды или минуты. Вы не сможете ничего кликать, прокручивать или взаимодействовать.

Очевидно, что эту страницу можно улучшить с помощью web worker. Но прежде чем вы доберетесь до этого, вам нужно внимательнее рассмотреть текущий код JavaScript. Прямо сейчас, когда вы нажимаете кнопку «Поиск», запускается функция doSearch(), показанная здесь:

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

Код, который фактически выполняет поиск простых чисел, находится в другой функции с именем findPrimes(). Вам не нужно понимать, как работает поиск простых чисел, чтобы использовать этот пример. Мы просто используем его, потому что это задача, которая проста для кодирования, но сложна в отношении вычислений, а это означает, что это может занять некоторое значительное время. Если вам интересно посмотреть математику, которая заставляет эту страницу работать, посмотрите в примере CodePen функцию findPrimes().

Выполняем задачу в фоновом режиме

Функция web worker связана с объектом под названием Worker. Когда вы хотите запустить что-то в фоновом режиме, вы создаете новый Worker, передаете ему некоторый код и отправляете некоторые данные.

Вот пример, который создает нового web worker, который запускает код в файле с именем PrimeWorker.js:

Код, который выполняет web worker, всегда хранится в отдельном файле JavaScript. Этим шаблоном начинающим программистам не рекомендуется писать код web worker, который пытается использовать глобальные переменные или напрямую обращаться к элементам на странице. Ни одна из этих операций невозможна. Почему? Потому что могут возникнуть проблемы, если несколько потоков пытаются манипулировать одними и теми же данными одновременно. Это означает, что у кода в PrimeWorker.js нет способа записать простые числа в элемент div. Вместо этого код web worker должен отправить свои данные обратно в код JavaScript на странице, и позволить коду веб-страницы отобразить результаты.

Веб-страницы и web worker общаются путем обмена сообщениями. Чтобы отправить данные worker, мы вызываем метод worker postMessage():

Затем worker получает событие onMessage, которое предоставляет копию данных. Точно так же, когда worker необходимо вернуться к веб-странице, он вызывает собственный метод postMessage() вместе с некоторыми данными, и веб-страница получает событие onMessage.

Перед тем, как рассмотреть это подробнее, нам нужно разобрать еще одну проблему. Функция postMessage() допускает только одно значение. Этот факт является камнем преткновения для поиска простых чисел, потому что ему нужны две части данных (два числа диапазона). Решение состоит в том, чтобы упаковать эти две части в литерал объекта. Этот код демонстрирует пример, в котором мы передаем объекту два свойства (первое с именем from и второе с именем to) и присваивает значения им обоим:

Помня об этом, вы можете пересмотреть функцию doSearch(), о которой шла речь ранее. Вместо того, чтобы выполнять поиск простого числа, функция doSearch() создает worker и заставляет его выполнять фактическую задачу.

Теперь в действие вступает код в файле PrimeWorker.js. Он получает событие onMessage, выполняет поиск, а затем отправляет новое сообщение обратно на страницу со списком простых чисел.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Когда worker вызывает postMessage(), он запускает событие onMessage, которое вызывает эту функцию на веб-странице:

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

Обработка ошибок worker

Метод postMessage() является ключевым аспектом взаимодействия с web worker. Однако есть еще один способ, с помощью которого web worker может уведомить веб-страницу — событие onerror, которое сигнализирует об ошибке:

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

Наряду со свойством message, объект ошибки также включает в себя свойства lineno и filename, которые сообщают номер строки и имя файла, в котором произошла ошибка.

Отмена фоновой задачи

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

Есть два способа остановить worker. Во-первых, worker может быть остановлен через вызов close(). Но чаще всего страница, создавшая worker, закрывает его, вызывая метод worker terminate(). Например, вот код, который вы можете использовать для включения простой кнопки отмены:

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

Передача более сложных сообщений

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

Как вы уже узнали, у web worker есть только один способ общения с веб-страницей — метод postMessage(). Таким образом, чтобы создать этот пример, web worker необходимо отправить два типа сообщений: уведомления о прогрессе работы (пока задача выполняется) и список простых чисел (когда задача закончена). Суть в том, что разница между этими двумя сообщениями должна быть понятна, и тогда обработчик событий onMessage на странице может определить разницу между двумя типами сообщений.

Лучший подход — добавить к сообщению немного дополнительной информации. Например, когда web worker отправляет информацию о прогрессе, он может добавить в сообщение текстовую метку «Progress». И когда web worker отправляет список простых чисел, он может добавить метку «PrimeList».

Чтобы объединить всю необходимую информацию в одно сообщение, вам нужно создать литерал объекта. Это делается с помощью той же технологии, что и создание веб-страницы, используемой для отправки данных диапазона чисел. Дополнительная часть информации — это текст, описывающий тип сообщения, который помещается в свойство, называемое в этом примере messageType. Фактические данные передаются во втором свойстве с именем data.

Вот как можно переписать код web worker, чтобы добавить тип сообщения в список простых чисел:

Источник

Как работает JS: веб-воркеры и пять сценариев их использования

Публикуем перевод седьмой части часть серии материалов об особенностях работы различных механизмов JavaScript. Наша сегодняшняя тема — веб-воркеры. В частности, речь пойдёт о различных типах веб-воркеров, о том, как организована совместная работа тех частей, из которых они состоят, а также об их возможностях и об ограничениях, с которыми можно столкнуться в разных сценариях их использования. Здесь же будет показано 5 вариантов практического применения веб-воркеров.

Ограничения асинхронного программирования

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

Асинхронному программированию и вариантам его применения в JS-проектах был посвящён один из предыдущих материалов этой серии.

Асинхронное выполнение кода позволяет пользовательскому интерфейсу веб-приложений нормально функционировать, реагировать на команды пользователя. Система «планирует» нагрузку на цикл событий таким образом, чтобы в первую очередь выполнялись операции, связанные с пользовательским интерфейсом.

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

Такой подход, однако, демонстрирует следующую проблему: запросы обрабатываются WEB API браузера. Нас же интересует возможность асинхронного выполнения произвольного кода. Скажем, как быть, если код внутри функции обратного вызова интенсивно использует ресурсы процессора?

Если функция performCPUIntensiveCalculation — это не нечто вроде асинхронно выполняемого HTTP-запроса, а код, блокирующий главный поток (скажем, огромный и тяжёлый цикл for ), то при однопоточном подходе к JS-разработке у нас нет способа освободить цикл событий и разблокировать интерфейс браузера. Как результат, пользователь не сможет с ним нормально работать.

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

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

Этот код можно переписать так, чтобы он «эмулировал» асинхронное выполнение:

Веб-воркеры

HTML5 дал нам множество замечательных возможностей, среди которых можно отметить следующие:

Это поистине замечательная возможность. Система понятий JavaScript основана на идее однопоточного окружения, а теперь перед нами технология, которая (частично) снимает это ограничение.

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

Вот простой пример, который демонстрирует разницу между сортировкой массива с помощью веб-воркера и без него.

▍Обзор веб-воркеров

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

Возможно, вы вспомните о том, что JavaScript — это однопоточный язык программирования. Пожалуй, тут вы должны осознать, что JS — это язык, который не определяет модель потоков. Веб-воркеры не являются частью JavaScript. Они представляют собой возможность браузера, к которой можно получить доступ посредством JavaScript. Большинство браузеров исторически были однопоточными (эта ситуация, конечно, изменилась), и большинство реализаций JavaScript создано для браузеров.

Веб-воркеры не реализованы в Node.js — там есть концепция «кластеров» или «дочерних процессов», а это уже немного другое.

Стоит отметить, что спецификация упоминает три типа веб-воркеров:

▍Выделенные воркеры

Экземпляры выделенных веб-воркеров создаются главным процессом. Обмениваться данными с ними может только он.

Поддержка выделенных воркеров в браузерах

▍Разделяемые воркеры

Поддержка разделяемых воркеров в браузерах

▍Сервис-воркеры

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

Поддержка сервис-воркеров в браузерах

Надо отметить, что в этом материале мы будем заниматься выделенными воркерами, именно их мы будем иметь в виду, говоря о «веб-воркерах» или о «воркерах».

Как работают веб-воркеры

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

Веб-воркеры выполняются в изолированных потоках в браузере. Как результат, код, который они выполняют, должен быть включён в отдельный файл. Это важно запомнить.

Вот как создают веб-воркеры:

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

Для запуска только что созданного воркера нужно вызвать его метод postMessage :

Обмен данными с веб-воркером

▍Метод postMessage

Посмотрим на пример того, как страница, создавшая воркер, может обмениваться с ним данными, используя JSON-объект. При передаче строки выглядит всё практически точно так же.

Вот часть HTML-страницы:

Вот содержимое файла с кодом воркера:

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

▍Широковещательный канал передачи данных

Объект BroadcastChannel представляет собой более универсальное API для передачи данных. Он позволяет передавать сообщения, которые можно принять во всех контекстах, имеющих один и тот же источник. Все вкладки браузера, iframe или воркеры, относящиеся к одному источнику, могут передавать и принимать широковещательные сообщения:

Вот как выглядит схема взаимодействия различных сущностей с использованием широковещательного канала обмена сообщениями:

Обмен данными с использованием широковещательного канала передачи сообщений

Однако тут стоит отметить, что объект BroadcastChannel пока имеет довольно ограниченную поддержку в браузерах.

Поддержка BroadcastChannel в браузерах

Способы отправки сообщений веб-воркерам

Есть два способа отправки сообщений веб-воркерам. Первый заключается в копировании данных, второй — в передаче данных от источника к приёмнику без их копирования. Рассмотрим эти способы работы с сообщениями:

Возможности, доступные веб-воркерам

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

Ограничения веб-воркеров

К сожалению, у веб-воркеров нет доступа к некоторым весьма важным возможностям JavaScript. Среди них следующие:

Обработка ошибок

Сценарии использования веб-воркеров

Мы рассказали о сильных и слабых сторонах веб-воркеров. Теперь рассмотрим несколько сценариев их использования.

Итоги

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

Предыдущие части цикла статей:

Уважаемые читатели! Используете ли вы веб-воркеры в своих проектах?

Источник