Comments 18
Непонятно, зачем vDOM выносить в воркер, операций обновления слишком много, они забьют канал к воркеру, и нужно будет бороться с задержкой. Все то же самое, но в воркере держать состояние и обмениваться им с main - должно быть гораздо лучше и супер фреймворк не нужен
Это интересный вопрос, который нужно исследовать на практике. Обновления vDOM точно не должны происходить чаще чем раз в кадр. Но скорее всего, в таком формате, после проб и ошибок появится отдельный протокол передачи изменений в реальный дом.
В целом, я не настаиваю на vDOM, но React и Vue сейчас работают с ним. Потенциально от него можно вообще отказаться как это делает Angular. Идея dedicated worker в том, чтобы обрабатывать логику View части.
Да, я как раз про логику View, что ее лучше оставить в основном потоке. Для себя представляю воркер как домен приложения, выполняющий бизнес-логику. А к нему уже можно безболезненно подключить веб страницу или нативное приложение или nodejs, electron, cli.
Кажется, что если view не влезает в основной поток, то перенос его в воркер только усугубит дело.
Узкое место это обмен данными между DOM и рантаймом JavaScript. DOM API в основном синхронный и заставляет ждать результатов. К тому же браузеру приходится перепаковывать структуры данных из одного формата в другой. vDOM помогает производить максимум вычислений в пределах JS и лишь иногда синхронизироваться с настоящим DOM (может раз в 16ms или даже чаще, но это все равно не так часто как если ходить за каждым атрибутом по сто раз в DOM и обратно). При попытке вынести расчет vDOM в воркер узким местом может стать коммуникация с основным потоком. Но там есть четкая зависимость от объема данных.
А вот это поведение воркеров, которые блокируются браузером из-за неактивности или слишком большой активности. А основной их смысл, судя по мыслям разработчиков стандарта - запуск нагруженных операций не так чтобы часто, но и не так чтобы редко.
Вот с этим как жить?
Казалось, когда узнал об этих самых воркерах - крутая идея положить туда SSE какой-нибудь и общаться со всеми вкладками и с воркером, чтоб централизовать передачу данных и получение их обратно в корпоративной CRM поделке.
P.S. Юзвери уж очень сильно хотят, чтоб можно было несколько вкладок и открывать их снаружи.
vDOM как-то шарится между воркерами или нет? Или идея в том, что каждый dedicated worker отвечает только за свою часть vDOM? Если таки шарится, то как его синхронизировать?
А как в такой архитектуре планируется решать проблему передачи данных между воркерами?
Как я понял, обычная обработка ввода от пользователя превращается в поток следующих действий:
Генерация события ввода символа в main thread -> трансфер события в воркер бизнес логики + сама бизнес логика -> трансфер стейта в рендед-воркер и пересчет vdom-а -> трансфер изменений/событий в main thread для отрисовки в DOM.
Итого минимум 3 трансфера, два из которых передают полный стейт приложения (или нет, но тогда как?). А если речь заходит о крупных веб-приложениях, то в них вроде как тенденция к тому, что стейт со временем сильнее пухнет. А трансфер стейта между воркерами - это всегда аналог json serialize/deserialize, что сильно грузит CPU. А технологии для перемещения объектов между потоками с минимумом накладных расходов по крайней мере мне еще не встречались.
Необязательно для каждого поля ввода читать каждый вводимый символ. Можно группировать по времени или вообще на потерю фокуса повешать обработчик. Тогда количество событий явно станет меньше.
А насчет передачи данных, я предлагаю двигать только те данные, которые меняются. Таким образом, количество данных подвергаемое копированию будет минимально, и как следствие задержки тоже.
Если у вас есть конкретный кейс, я бы с радостью более детально разобрал :)
Практически во всех областях IT-разработки весь мир перешел на использование многопоточности: мобильные приложения, бэкенд, прикладное программирование
Про это есть старый доклад на тему Concurrency , который однако до сих пор актуален. Если коротко: многопоточность это для персоналок, в игры гонять, ну или там рисовать юай. Для бекендов она не слишком полезна: для них типичны либо задачи, которые прекрасно решаются в один поток на одном ядре, либо требующие масштабирования за пределы одной машинки.
У вас немного ссылка не валидная. (Вот рабочая, если я прав https://www.youtube.com/watch?v=9zinZmE3Ogk)
Обязательно посмотрю :)
А насчет бека, не совсем так. Многопоточность отличный вариант, там где нет асинхронности и там где нужно все держать в рамках одного процесса. На беке, мы обычно не ограничены одним процессом, поэтому в языках с поддержкой асинхронности мы вообще не думаем о потоках (та же Node.js).
Рад за веб-программеров, наконец они изобрели велосипед, на котором десктопные приложения ездят лет эдак 25. Я про использование многопоточности в GUI-приложениях и выделение всех GUI-операций в один поток, а бизнес-логику в другой/другие потоки.
Кстати, в десктопном Хроме shared worker должен быть в своём отдельным процессе, так как каждая вкладка уже отдельный процесс.
Да, и не надо путать шаринг и шеринг - это разные вещи. В данном случае слово шаринг используется неверно.
Рад за веб-программеров, наконец они изобрели велосипед, на котором десктопные приложения ездят лет эдак 25
В экосистемах, где есть мощная механика асинхронности, не так и важна многопоточность :)
Кстати, в десктопном Хроме shared worker должен быть в своём отдельным процессе, так как каждая вкладка уже отдельный процесс.
Нет. Вкладки и воркеры это именно что потоки. Хотя, я, конечно, могу ошибаться, и если вы предоставите аргументы, я буду вам премного благодарен ;)
у shared-воркера плохой PR-менеджер
к сожалению, поддержки браузерами нет
Многопоточность на фронте: абсурд или прекрасное архитектурное решение?