Многопоточность на клиенте — миф или реальность?

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

Вопрос задан потому что открытие некоторых страниц по удобству напоминает Dos, только быстрый. Когда данных мало, то лаг невозможно заметить, когда много, то подвисания страницы могут длится до 10-15 секунд, что раздражает.

И при этом не важно как все хорошо оптимизировано на сервере, так как все равно создается впечатление тормознутого сайта.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ну кстати по поводу «зачем» — смотрим тот же pics.io — конвертировать и редактировать raw форматы в браузере в один поток === издевательство над пользователем.

Многопоточности на клиенте существует много-много лет. Делается через ifames. Worker — более легковесный, но при этом не может, например, общаться с сетью. Так что многопоточные приложения на клиенте вполне можно создавать.

согласно этому — www.html5rocks.com/...workers/basics с сетью можно вполне (такое ограничение было бы очень странным).

Workers do NOT have access to:

The DOM (it’s not thread-safe)
The window object
The document object
The parent object

а что это за страницы такие у вас, что подвисают на 15 секунд?
примеры приведите пожалуйста.
будет ли вас удовлетворять подвисание в 7 секунд?

Зависит от реализации, но вроде в один поток. Просто по событиям.

Зависит от реализации, но вроде в один поток.
А назовите многопоточные реализации?

Ну в Хроме в каждой вкладке JS работает в своем потоке, это конечно не совсем ответ на вопрос, но уже шаг к многопоточной реализации.

Ну в Хроме в каждой вкладке JS работает в своем потоке, это конечно не совсем ответ на вопрос, но уже шаг к многопоточной реализации.
лол просто лол

Вам не понравился факт или его интерпретация? Между прочим тот же IE7 для JS выделял один поток на все открытые страницы. Так что это уже прогресс.

Вам не понравился факт или его интерпретация?
Интерпритация.

Какое это имеет отношение к делу, если речь идет о многопоточности(точнее его отсутствии) в языке программирования javascript?

кстати, да
только вот сейчас в голову пришло — никаких объектов синхронизации сам язык в текущем виде не представляет(каюсь, не читал спеку на основу — ECMAScript). а распаралелливать только то, что setTimeout/setInterval/XHR — худо, ибо замыкание(точнее сказать — контекст) без локов/синхронизации доступа-то.

Обычно же асинхронно запускаются функции. Или они в один поток работают?
Мдяяяяя...
Джависты настолько зашорены что не знают языков программирования, в которых async функции/вызовы использует все ядра без указания пользователя, и есть языки которые этого совсем не позволяют делать?
Скорее некоторые джависты имеют представление о джаваскрипте, а еще различают понятия асинхронно и многопоточно. Чего нельзя сказать про некоторых Perl developer / Architect в AVA.ua

Это даже каждый Delphi-ст знает.

асинхронность может быть реализована и на базе потоков, и на базе процессов, а также на базе процессоров. например в железе.

А может и ни на чем из перечисленного.

это как? ну, даже если не вдаваться в нюансы работы движка?
выполняешь себе
var x = sin(0.5);
...
выполнение пошло дальше, а синус еще вычисляется? и куда вернется результат вычисления?

речь очевидно о конструкциях типа
sin(0.5, function(x) { вот и наш x });
а здесь код выполняется дальше во время работы sin

речь очевидно о конструкциях типа
sin(0.5, function(x) { вот и наш x });
А этот код будет выполнятсо многопоточно?
а здесь код выполняется дальше во время работы sin
То что вы написали — это обыкновенный колбэк, далеко не факт что он даже будет выполнятсо в новом эвенте/ячейке.

да, чёт я тупанул насчёт того, что они будут выполняться одновременно

Имеются ввиду анонимные функции, используемые повсеместно в jquery/nodejs. Это само собой разумеется для тех кто с js работал
1) Скорее для тех кто умет читать ваши мысли.
2) Далеко не все функции будут выполнятся именно асинхронно, некоторые могут быть просто колбеками (это как раз очевидно для любого кто работал с джаваскриптом)
3) Асинхронно != многопоточно, лучше так: Асинхронно !== многопоточно — это очевидно для любого кто имет хоть какие-то познания в ЦС
4) Нода и браузерные движки (знаете многопоточный расскажите), на данный момент, одонопоточны (это известно любому кто работал с джаваскриптом больше чем «навесить джКвери плагин»). И в этом их сила (это очевидно для любого кто знает что такое реактор)

А теперь троллинг:

а не только фабрики клепал в java и strnlen говнокодил в пхп.
А че "Perl developer"-у завидно? :)
Асинхронно != многопоточно, лучше так: Асинхронно !== многопоточно
Порвало. В голову ніколи не приходило так людям пояснювати.

Использую воркеры для сложных вычислений при обработке DOM в браузерных плагинах www.archify.com (для определения главного текстового модуля). Все зависит от задачи. Без воркера на больших сайтах происходит подвисание браузерного UI-потока на пару секунд. Но у воркеров много ограничений, они не имеют прямого доступа к документу, т.е. использовать их целесообразно для конкретных задач, а не клиента в целом

Перше питання, яке виникло — а нафіга? Переносити супер довгі обчислення на клієнт? Клієнт це тільки пульт управління для всієї системи...як на мене

Переносити супер довгі обчислення на клієнт?
Банальный рендеринг на клиенте может тормозить, анимации и тд.

З анімацією згідний, але це діло помалу переприває на хардварний рівень. Вже багато доповнень пропонують таку можливість

Потому что клиент, это по минимуму 1.5 ГГц ARM, а по максимуму какой-то i7, и у него ресурсов поболее чем может выделить сервер на одного клиента под нагрузкой.

І ви довірете, для прикладу, рахувати зарплати працівникам на клієнті? Тимбільше я не думаю, що клієнт скаже дякую, якщо ваш ресурс буде вішати йому бравзер.

ну, рассчет з/п не назвать ресурсоемкой операцией

І ви довірете, для прикладу, рахувати зарплати працівникам на клієнті?
Что значит расчет ЗП? Вывести итого? При всех данных вполне можно и доверить (так как это инфа только для отображения). Но это не лучший пример.
Более наглядно:
Есть таблица (ФИО, отдел, ЗП, разное). Надо написать фильтр ко всем полям.
Обязательное требование: Надо выводить сумму всех ЗП по фильтру.
Есть фильтрация сделана сервисом (отдает только данные), а отрисовка на клиенте, то получается интересный момент: ваш поиск будет немного больше нагружать сервер (да-да спички) и куда более важно — ваша модель будет не такой уж и универсальной (вместо списка моделей “сотрудник”, вы отдаете объект со списком объектов “сотрудник” и полем “итого”)

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

Когда данных мало, то лаг невозможно заметить, когда много, то подвисания страницы могут длится до 10-15 секунд, что раздражает.
Здаетсо мне, что дело не в многопоточности.
как часто в разработке на Javascript вы используете механизм Worker для многопоточной обработки данных
В современных браузерах и так все довольно быстро. А в несовременных вебворкеры не поддерживаются, то есть все равно надо проводить оптимизации типа ленивая инициализация или упрощение интерфейса (чтобы не надо было грузить много данных).
ИМХО, вебворкеры — это не для оптимизации «сайтов» или даже «веб-апликейшенов», это скорее тяжелая артиллерия (которой можно себе отстрелить голову, учитывая разнообразие платформ)

Підписатись на коментарі