Необязательно для каждого поля ввода читать каждый вводимый символ. Можно группировать по времени или вообще на потерю фокуса повешать обработчик. Тогда количество событий явно станет меньше.
А насчет передачи данных, я предлагаю двигать только те данные, которые меняются. Таким образом, количество данных подвергаемое копированию будет минимально, и как следствие задержки тоже.
Если у вас есть конкретный кейс, я бы с радостью более детально разобрал :)
А насчет бека, не совсем так. Многопоточность отличный вариант, там где нет асинхронности и там где нужно все держать в рамках одного процесса. На беке, мы обычно не ограничены одним процессом, поэтому в языках с поддержкой асинхронности мы вообще не думаем о потоках (та же Node.js).
нет, не шарится. Для каждой страницы нужен свой vDOM. И для каждой страницы есть свой dedicated worker. А синхранизируем мы лишь только данные, которые в shared worker
Это интересный вопрос, который нужно исследовать на практике. Обновления vDOM точно не должны происходить чаще чем раз в кадр. Но скорее всего, в таком формате, после проб и ошибок появится отдельный протокол передачи изменений в реальный дом. В целом, я не настаиваю на vDOM, но React и Vue сейчас работают с ним. Потенциально от него можно вообще отказаться как это делает Angular. Идея dedicated worker в том, чтобы обрабатывать логику View части.
Необязательно для каждого поля ввода читать каждый вводимый символ. Можно группировать по времени или вообще на потерю фокуса повешать обработчик. Тогда количество событий явно станет меньше.
А насчет передачи данных, я предлагаю двигать только те данные, которые меняются. Таким образом, количество данных подвергаемое копированию будет минимально, и как следствие задержки тоже.
Если у вас есть конкретный кейс, я бы с радостью более детально разобрал :)
В экосистемах, где есть мощная механика асинхронности, не так и важна многопоточность :)
Нет. Вкладки и воркеры это именно что потоки. Хотя, я, конечно, могу ошибаться, и если вы предоставите аргументы, я буду вам премного благодарен ;)
Есть, но не лучшая)
Safari - уже вернули поддержку. Надо лишь подождать обновления у всех.
А у мобильных браузеров, да, придется полифилить.
У вас немного ссылка не валидная. (Вот рабочая, если я прав https://www.youtube.com/watch?v=9zinZmE3Ogk)
Обязательно посмотрю :)
А насчет бека, не совсем так. Многопоточность отличный вариант, там где нет асинхронности и там где нужно все держать в рамках одного процесса. На беке, мы обычно не ограничены одним процессом, поэтому в языках с поддержкой асинхронности мы вообще не думаем о потоках (та же Node.js).
нет, не шарится. Для каждой страницы нужен свой vDOM. И для каждой страницы есть свой dedicated worker. А синхранизируем мы лишь только данные, которые в shared worker
Возможно :)
Нужно пробовать и бенчить
Это интересный вопрос, который нужно исследовать на практике. Обновления vDOM точно не должны происходить чаще чем раз в кадр. Но скорее всего, в таком формате, после проб и ошибок появится отдельный протокол передачи изменений в реальный дом.
В целом, я не настаиваю на vDOM, но React и Vue сейчас работают с ним. Потенциально от него можно вообще отказаться как это делает Angular. Идея dedicated worker в том, чтобы обрабатывать логику View части.