Очень крутое объяснение! Спасибо за работу Могли бы вы в комментах ответить какие самые частые use case'ы для использования этого инструмента могут встретиться в разработке приложения?
Добрый день. У веб воркера нет доступа к DOM поэтому его используют для тяжелых расчетов, "фоновых" запросов к серверу и обработки различных данных. Например: 1. Запуск WebSocket для получения данных с сервера без дополнительной активности юзера, таймеров или интервалов, полная обработка полученных с сервера данных и отправка в приложение уже готовых к использованию данных, без необходимости дополнительной обработки в основном потоке. 2. Запросы на веб сервер, обработка полученных данных и передача их в основной поток. 3. Тяжелые математические вычисления. Передаем сырой набор данных для вычисления из основного потока, выполняем расчет и возвращаем полученные результаты. 4. Организация баз данных на стандартных JS структурах (Array, Map, Set и т.д) или на IndexedDB. Из основного потока присылаем команды с данными, а вся обработка выполняется в WebWorker. 5. Более точные таймеры, не зависящие от основного потока. 6. Создание или обработка файлов, загруженных пользователем. Например, можно в WebWorker выполнить преобразование полноцветного изображения в чёрно-белое. Самое главное, что нужно помнить - это то, что WebWorker это реально отдельный поток выполнения и вычисления внутри никак не влияют на основной поток приложения и, как следствие на отзывчивость.
Спасибо большое. И предыдущий ролик про microTasks, macroTasks - и этот - были то что мне нужно. И что приятно английские названия вполне нормальные. (Единственно к чему придерусь, уж простите - к опечатки в словах "default" - в файле webworker.js и "response" в index2.html на 12:37)
Разное время исполнения от того, что начальные условия не равны, вы же постоянно расширяете портянку текста, записывая её с множителем х5. 🤔 А так очень полезное видео, Автору огромная благодарность 👍👍👍
Добрый день. Спасибо за просмотр и поддержку. Основной смысл не в скорости, а в том, что UI не блокируется. Скорость это второстепенно. И чаще всего общее время выполнения одной и та же функция с таким объемом данных в воркере будет немного больше, т.к. время кодирования и декодирования в JSON добавляется ко времени выполнения самого кода функции.
Реально круто, никогда не использовал воркеры на клиенте, в каких случаях это может быть полезно? Я к тому что не правильнее ли всю тяжёлую фигню на бэк отдавать?
Добрый день. Веб приложения работают в рамках классической архитектуры клиент-сервер. Клиент - это браузер и приложение в нем. Сервер - это http сервер включая бэкэнд. В любой системе "клиент-сервер" именно сервер + сеть являются горлышком бутылки. Сервер должен обслуживать массовые запросы и любая проблема с производительностью на сервере приводит к тормозам во всей системе. Поэтому еще до появления WEB старались всё, что только можно (с учетом безопасности и т.д.) вынести на сторону клиента. Тогда часть работы выполняется на хосте пользователя и разгружает сервер. Когда появился JS стали это делать и в WEB, до того - был чистый "сервер-сайд рендеринг" ;) Браузер, как среда выполнения для веб приложения, накладывает много ограничений, но это уже особенности. В современных веб приложениях очень часто есть расчеты, которые сказываются на производительности и отзывчивости приложения. Вот их удобно делать в воркере. Например, сложные фильтрации и сортировки данных, подготовка и преобразование данных, трекинг активности пользователя...
@@EasyITChannel а на сколько это является хорошей практикой, ведь производительность клиентов разная? в наших проектов мы наоборот делаем легкий клиент, вынося все тяжëлые операции на сервер
@@EasyITChannel по поводу фильтрации и сортировки кстати согласен, но вот преобразование например уже вопрос, зачем это клиенту, пусть сервер уже готовые данные вернëт... но вообще - да, надо пробовать внедрить
Легкий клиент это одно из архитектурных решений. У него есть преимущества и недостатки. Главный - повышенная нагрузка на сервер. Преимущество - вся логика на сервере, в более защищенном месте, «в одних руках». Преобразования бывают разные, многие можно сделать на сервере, некоторые, зависящие от UI - на клиенте. Например, 3D сцену сложно просчитать полностью на сервере, она зависит от чисто клиентских нюансов, меняющихся слишком часто. Скажите «где 3D, а где web”? 😉Задачи бывают разные, и такие тоже. Может быть дойдем когда-то до этого и на канале ;) Всему свое время.
postMessage это стандартный метод экземпляра воркера. Если его вызываем, то сработает обработчик, который создали в основном коде: worker.onmessage = onMessage; Вот этот onMessage и вызовется. Это стандартный способ коммуникации между основным кодом и воркером.
@@EasyITChannel Хм, если бы это изначально его метод был ,то я бы получил при написании postMessage() reference Error , так как нужно было сослаться на декларацию метода. Щас проверил postMessage как и addEventListener просто функции в глобальной области видимости, поэтому и не ругается компиллер на обращение
Вы путаете вот что - "глобальная область видимости" в воркере - это экземпляр воркера (не window!!!), а в основном скрипте это глобальный объект window. А так, да, все верно, только что находясь внутри воркера, ссылаться на него не обязательно. Точно так же находясь в основном скрипте можно не ссылаться на window при вызове метода alert() или fetch().
Добрый день. Разница в том, что асинхронные функции все же работают в том же цикле обработки событий что и основаная программа (макротаски), а веб воркер работает в отдельном от основной программы цикле обработки событий. То есть фактически параллельно и независимо. У него есть ограничения в виде отсутствие доступа к DOM и некоторым WEB API. Но если нужно именно выполнить расчеты в отдельном параллельном "потоке" - веб воркер отличный выбор.
Если целью ставить расширение аудитории то надо делать ролики с мемасиками или жопами и вообще ничего не говорить. В технических же роликах главное это нормальный звук, внятность и раскрытие сути материала, большинство их смотрят как справочник. Планов превращать канал в развлекательный, типо «стильно, модно, молодежно» пока нет. Материалов, в которых с ошибками, но весело пересказывают банальные доки, на RUclips более чем достаточно. Большое спасибо Вам за просмотр, комментарий и очень ценный совет, сам бы я никогда не догадался.
Честно говоря мне тоже первые несколько секунд самого первого ролика так показалось тк голос автора уставший, но нет,быстро затянуло, и ролик и плейлист, тк материал автора очень актуально подается на важные темы и без задержек - хотя в теме про задержки рассказать без ненужных задержек - это надо быть ассом.
Спасибо за классный материал, даже не думал о таком
И Вам спасибо за просмотр.
Очень крутое объяснение!
Спасибо за работу
Могли бы вы в комментах ответить какие самые частые use case'ы для использования этого инструмента могут встретиться в разработке приложения?
Добрый день.
У веб воркера нет доступа к DOM поэтому его используют для тяжелых расчетов, "фоновых" запросов к серверу и обработки различных данных. Например:
1. Запуск WebSocket для получения данных с сервера без дополнительной активности юзера, таймеров или интервалов, полная обработка полученных с сервера данных и отправка в приложение уже готовых к использованию данных, без необходимости дополнительной обработки в основном потоке.
2. Запросы на веб сервер, обработка полученных данных и передача их в основной поток.
3. Тяжелые математические вычисления. Передаем сырой набор данных для вычисления из основного потока, выполняем расчет и возвращаем полученные результаты.
4. Организация баз данных на стандартных JS структурах (Array, Map, Set и т.д) или на IndexedDB. Из основного потока присылаем команды с данными, а вся обработка выполняется в WebWorker.
5. Более точные таймеры, не зависящие от основного потока.
6. Создание или обработка файлов, загруженных пользователем. Например, можно в WebWorker выполнить преобразование полноцветного изображения в чёрно-белое.
Самое главное, что нужно помнить - это то, что WebWorker это реально отдельный поток выполнения и вычисления внутри никак не влияют на основной поток приложения и, как следствие на отзывчивость.
@@EasyITChannel Потрясающе!
Спасибо вам за дополнительную инфу, буду следить за вами дальше!
Спасибо большое. И предыдущий ролик про microTasks, macroTasks - и этот - были то что мне нужно. И что приятно английские названия вполне нормальные.
(Единственно к чему придерусь, уж простите - к опечатки в словах "default" - в файле webworker.js и "response" в index2.html на 12:37)
Самое смешное в том, что точно такие же описки совершают нэтив спикеры :)
Разное время исполнения от того, что начальные условия не равны, вы же постоянно расширяете портянку текста, записывая её с множителем х5. 🤔
А так очень полезное видео, Автору огромная благодарность 👍👍👍
Добрый день. Спасибо за просмотр и поддержку.
Основной смысл не в скорости, а в том, что UI не блокируется. Скорость это второстепенно. И чаще всего общее время выполнения одной и та же функция с таким объемом данных в воркере будет немного больше, т.к. время кодирования и декодирования в JSON добавляется ко времени выполнения самого кода функции.
Реально круто, никогда не использовал воркеры на клиенте, в каких случаях это может быть полезно? Я к тому что не правильнее ли всю тяжёлую фигню на бэк отдавать?
Добрый день.
Веб приложения работают в рамках классической архитектуры клиент-сервер. Клиент - это браузер и приложение в нем. Сервер - это http сервер включая бэкэнд.
В любой системе "клиент-сервер" именно сервер + сеть являются горлышком бутылки. Сервер должен обслуживать массовые запросы и любая проблема с производительностью на сервере приводит к тормозам во всей системе.
Поэтому еще до появления WEB старались всё, что только можно (с учетом безопасности и т.д.) вынести на сторону клиента. Тогда часть работы выполняется на хосте пользователя и разгружает сервер. Когда появился JS стали это делать и в WEB, до того - был чистый "сервер-сайд рендеринг" ;) Браузер, как среда выполнения для веб приложения, накладывает много ограничений, но это уже особенности.
В современных веб приложениях очень часто есть расчеты, которые сказываются на производительности и отзывчивости приложения. Вот их удобно делать в воркере. Например, сложные фильтрации и сортировки данных, подготовка и преобразование данных, трекинг активности пользователя...
@@EasyITChannel а на сколько это является хорошей практикой, ведь производительность клиентов разная? в наших проектов мы наоборот делаем легкий клиент, вынося все тяжëлые операции на сервер
@@EasyITChannel по поводу фильтрации и сортировки кстати согласен, но вот преобразование например уже вопрос, зачем это клиенту, пусть сервер уже готовые данные вернëт... но вообще - да, надо пробовать внедрить
Легкий клиент это одно из архитектурных решений. У него есть преимущества и недостатки. Главный - повышенная нагрузка на сервер. Преимущество - вся логика на сервере, в более защищенном месте, «в одних руках».
Преобразования бывают разные, многие можно сделать на сервере, некоторые, зависящие от UI - на клиенте. Например, 3D сцену сложно просчитать полностью на сервере, она зависит от чисто клиентских нюансов, меняющихся слишком часто. Скажите «где 3D, а где web”? 😉Задачи бывают разные, и такие тоже. Может быть дойдем когда-то до этого и на канале ;) Всему свое время.
unreal top
Спасибо за видео, толково разъяснили, но одно не понял где реализация метода postMessage() в методе answer ?
postMessage это стандартный метод экземпляра воркера. Если его вызываем, то сработает обработчик, который создали в основном коде:
worker.onmessage = onMessage;
Вот этот onMessage и вызовется.
Это стандартный способ коммуникации между основным кодом и воркером.
@@EasyITChannel Хм, если бы это изначально его метод был ,то я бы получил при написании postMessage() reference Error , так как нужно было сослаться на декларацию метода. Щас проверил postMessage как и addEventListener просто функции в глобальной области видимости, поэтому и не ругается компиллер на обращение
Вы путаете вот что -
"глобальная область видимости" в воркере - это экземпляр воркера (не window!!!), а в основном скрипте это глобальный объект window.
А так, да, все верно, только что находясь внутри воркера, ссылаться на него не обязательно.
Точно так же находясь в основном скрипте можно не ссылаться на window при вызове метода alert() или fetch().
@@EasyITChannel ПОнял, спасибо большое за разъяснение
А в чем разница в вынесении логики в веб воркер и в асинхронную функцию, промис?
Добрый день. Разница в том, что асинхронные функции все же работают в том же цикле обработки событий что и основаная программа (макротаски), а веб воркер работает в отдельном от основной программы цикле обработки событий. То есть фактически параллельно и независимо. У него есть ограничения в виде отсутствие доступа к DOM и некоторым WEB API. Но если нужно именно выполнить расчеты в отдельном параллельном "потоке" - веб воркер отличный выбор.
Дуже "тошно" розказуєш, по ділу але дуже занудно. Зміни темп і стиль подачі матеріалу, тоді твоя аудиторія сильно розшириться
Если целью ставить расширение аудитории то надо делать ролики с мемасиками или жопами и вообще ничего не говорить. В технических же роликах главное это нормальный звук, внятность и раскрытие сути материала, большинство их смотрят как справочник. Планов превращать канал в развлекательный, типо «стильно, модно, молодежно» пока нет. Материалов, в которых с ошибками, но весело пересказывают банальные доки, на RUclips более чем достаточно.
Большое спасибо Вам за просмотр, комментарий и очень ценный совет, сам бы я никогда не догадался.
Честно говоря мне тоже первые несколько секунд самого первого ролика так показалось тк голос автора уставший, но нет,быстро затянуло, и ролик и плейлист, тк материал автора очень актуально подается на важные темы и без задержек - хотя в теме про задержки рассказать без ненужных задержек - это надо быть ассом.
@@EasyITChannel Все прекрасно смотрится на 1.25, не меняйте, пожалуйста, ничего :)
Нормально он все рассказывает и по делу, без воды, если для вас это кажется медленным, всегда можно ускорить видео
@@EasyITChannelматериал топ!!!!!