Объединить оба компонента под родительской ViewModel и вынести связанные ключи в неё. Это безболезненно и очень быстро. :)
Не всегда просто. Особенно если это большие компоненты, а бизнес-логика требует. Из личного: были две панели на одной странице, никак между собой не связанные. А потом оказалось, что одна панель при сохранении может обновлять данные другой панели. Логики в каждой панели просто невероятное количество, из общего — только ключ страницы, в которой используются оба. Нужно было сделать сигнализацию из одной панели в другую. В редаксе элементарно, в мобх зависит от использованного "над-фреймворка", но обычно тоже просто, тут нужно либо странный общий ключ у общего родителя, либо какую-то систему сигнализации. И задача не такая уж и редкая, если это полноценное веб-приложение с сложной и постоянно изменяющейся бизнес-логикой.
Я плохо представляю себе, насколько объемной должна быть модель, чтобы выборка данных стала бутылочным горлышком.
Да запросто. У вас есть 50 записей чего-то + фильтр (ну или сортировка). И черт с самим фильтром, быстро работает, а вот сбрасывание shallow compare (ну или shouldComponentUpdate) — большая проблема. Нужны уже реселекторы всякие там, чтобы computed всегда возвращал одно и то же значение.
Ах да, прошлый раз забыл: а что там по рефакторингу? Если я захотел переименовать user в profile — мне идти по всему коду и менять надпись? Селекторы как абстракция придуманы не просто так (в mobx это проще, потому что всегда прямая ссылка на поле, ts справится с переименованием).
Про кеширование не совсем понял, уточните?
Если я открыл страницу с ресурсом id = 1, затем id = 2, затем вернулся на 1 — зачем мне его перезагружать?
Тоже не совсем понял. 50 вложенных объектов, или просто связанных?
Нормализованных. Пример: у меня есть список всех лекций, а на панели слева список текущих лекций. Я переименовал одну лекцию — как панель слева узнает о том, что я это сделал? Логично использовать нормализованную структуру:
Изменения в одном месте отражаются сразу во всем приложении. Только у меня таки "таблиц" в терминах БД 50+. И, как я сказал, если их хранить все в рутовом ViewModel, тогда он вырождается в редакс (только без тайм тревела, логирования, мидлвейров, саги). Если их хранить в виде иерархии ViewModel — как они будут сигнализировать об обновлении?
Никакой магии тут нету, кстати сказать, банальные lodash.get/set.
Это жуткий недостаток для меня. И для всех, кто хоть раз пытался рефакторить более-менее крупный проект, полный этого чертового get.
С архитектурной точки зрения мне кажется, что таких штук допускать не надо.
С архитектурной точки зрения, при unmount запросы должны отбрасываться либо их результат игнорироваться. Как минимум, не должно мигать пол страницы. Впрочем, тут только rxjs молодцом, с сагой еще можно извернуться, остальные технологии требуют достаточно больших телодвижений и спасает, что обычно данные в дочерних компонентах никому не нужны и факт их загрузки никому не мешает.
Если это не родственная модель, то никак. Это фича. Выносите ключи в общего родителя.
Это приведет, со временем, к миграции всего в рутовый ViewModel. В лучшем случае, в рутовый для модуля, а не всего приложения.
Простой пример: у вас есть список предметов ученика с оценками по ним. Идем по пути "Самый очевидный вариант — да, рендерить ViewModel на каждого пользователя.". Скажем, по каждому предмету еще тыкать можно, оценки там менять, заметки добавлять, преподавателя смотреть. Появляется задача — показать средний балл. Что ж, поехали все наши ViewModels для каждого предмета вверх по стейту и теперь есть общий ViewModel, который хранит список предметов. А теперь вам нужно эту оценку для каждого ученика в левой панели показать — опять все всплывает вверх. А потом среднюю по всем ученикам… И динамику, заодно.
Абстрагируясь от идеи вписывания бизнес-логики во вью (это, в целом, плохо по множеству причин, но может быть иногда достаточно удобно), я бы подсветил несколько моментов.
Стоит убрать FaaC (function as a child) в пользу хуков. Сильно сократит и упростит код. В разы.
Показал бы в примерах как это тестировать.
Как вызвать метод контроллера компонента сверху? (Окей, диспатч или более странный способ через $set, допустим. К слову, в редаксе нельзя напрямую писать в store, никогда не задумывались почему?)
Как среагировать на изменение состояния соседа? А что если сейчас вам не нужно связывать две панели между собой и вы создали достаточно объемную ViewModel в каждом из них, а потом вдруг понадобилось их связать (они стали взаимно зависимыми)?
У меня есть список пользователей. Каждый раз я открываю пользователя — я должен его догрузить. Но у меня еще есть N методов для каждого пользователя. Как вы это организуете в своем фреймворке? Каждый пользователь — отдельный ViewModel? А как тогда будете кешировать пользователей?
Продолжение 5-го пункта. У меня в реальном проекте более 50 доменных объектов (это мы еще плохо нормализовали данные). И они, к сожалению, достаточно сильно связаны между собой. У вас вырадится в редакс? Или будет иерархия из 50-ти вложенных контекстов?
Как "прервать" / отбросить / отменить асинхронный метод? Что если я уже успел покинуть viewModel, которое еще не успело что-то загрузить, при этом оно перепишет какое-то значение родителя?
К слову, как в методе контроллера получить значение чужой viewModel?
Самое главное: зачем это все, если есть useReducer и useContext, которые позволяют получить все тоже самое? Ну вместо $set будет у вас dispatch({type: 'set'}), обертку можно легко сделать.
P.S. странно, у последних абзацев должны быть цифры 7, 8 и 9, не знаю что поломалось.
Интересная технология, но не понятно назначение. Нет бы сделать упрощенный HTML, я бы назвал его AHTML (application html), специально под нужды веб-приложений, да порезанный css для него без всяких там float, а так же возможность делать wasm расширения для фреймворков (условно говоря, собственный многопоточный рантайм для условного реакта/ангулара), чтобы js обрабатывал только бизнес-логику, а не весь процесс рендеринга, так все хотят втянуть рантайм огромных кросс-платформенных фреймворков с собственным движком рендеринга, т.е. сделать браузер в браузере.
Осталось портировать под wasm эмулятор андроида и вместо веб-приложений запускать андроид-приложения в браузере под wasm.
Gmail надоел отклонять письма с вложениями на подобие zip. Но про аутлук действительно иногда не получает письма, прям бесит. Но пока не нашёл удобного, желательно self-hosted аналога с возможностью продвинутой фильтрации, но и не создающим невероятное количество геморроя
Знаю, что он не популярен в рунете, да и это шило на мыло, но все же Gmail > outlook.com. По крайней мере, в нем есть гораздо более продвинутые правила сортировки писем из серии "показывать только последнее письмо от X в inbox, остальные перемещать на месяц в папку Y, после чего удалять"
Используя css-modules столкнулся с проблемой, что в библиотеках иногда селекторы довольно многословны и, поэтому, имеют высокий приоритет и просто с использованием модулей (ровно как и styled-component) перебить без impotant их иногда не выходит. Жутко раздражает, хотелось бы, конечно, иметь более декларативный способ описания приоритета стиля, чем через селектор.
Ну узкофюзеляжный бомбардир сильно шумнее А320, да и мне не повезло сидеть на последнем ряду прямо у крепления двигателя. Скажем так, звук ощущался всем телом. Но в целом, в метро с тихой музыкой (на половину громкости) само метро не слышно вообще так что нареканий у меня нет
Без музыки шум слышен даже от переодики. Однако хватает даже очень тихой расслабляющей музыки (или, не знаю, белого шума, например, он на удивление хорошо отсекается самим мозгом через несколько секунд) чтобы приглушить все голоса в офисе и даже крик ребенка в самолете.
Но у меня к звукодаву другой отзыв: очень непривычное ощущение мира — пропадает звуковой отклик от повседневных вещей и, оказывается, первое время это воспринимается странно. А костная проводимость только делает все хуже — слышно как некоторые вещи распространяются через пол и кости в уши — какие-то высокочастотные звуки, но быстро привыкаешь. К слову, подозреваю что фоновый шум от самолета слышен тоже только из-за костной проводимости, а не через сами наушники. Ну или может они все же не могут заглушить ревущий в полтора метрах двигатель Bombardier Challenger 800
Почему-то вспомнился сразу анонсированный MS Flight simulator 2020 https://www.youtube.com/watch?v=_TY56kA8oY0 Интересно, там похожая техника? На видео пока выглядит мягко говоря впечатляющее количество деревьев.
Вот интересно, слышал что в забугорье часто используются персональные номера (что-то между нашим ИНН и номером паспорта) и есть служба с API, в которой можно сверить эти данные на правильность. Но что самое интересное — эти номера содержат чек-сумму и проверяют на ошибку. Почему в России до такого не додумались? И вообще, номера и серия паспорта идут по порядку или все же кодируют какую-то информацию?
Edit: служба с API — налоговая. Они же эти номера и выдают.
Не очень понятно из текста каким образом определяется какой из номеров считается оригинальным в таком случае? Или сохраняются оба, просто с ссылкой друг на друга?
Прямо в рекомендациях к этой статье есть ваша же (!) статья с этой же темой, только другим оформлением от прошлого года. Это не считая сотни других статей, которые так же являются перепечаткой документации. В 2021 году будет такая же статья?
Потом сравните производительность одного запроса. И производительность нескольких запросов (время выполнения одного запроса должно вырасти, но суперпозиция асинхронной версии должна быть быстрее, стартовая гипотеза). И можно даже больше заморочаться — запустить ноду как кластер и посмотреть как изменятся показания.
Я даже не прошу заморачиваться с параллельным асинхронным поиском в данном случае. Тогда это будут действительно репрезетативные данные.
P.S. PreciseTime, само собой, не может быть while (true) внутри очевидно, так что придется повозиться, впрочем можно обойтись, конечно, и setTimeout(1);
Так, поправьте меня, если я не прав, но вроде как если хранить JSON внутри файла, вы не можете гарантировать сдвиг до нужного объекта внутри файла. Как следствие — вам нужно прочитать все строки перед этим JSON до того, пока вы найдете нужный, вы не можете сказать просто read(offset struct_size, (offset + 1) struct_size) (ну или в этом духе, не важно).
Как следствие, каждый раз вы ищите файл. Синхронный код в java может работать быстрее по множеству причин, в том числе сама асинхронность само собой увеличивает издержки, но так же тут может участвовать что угодно, например, неумение JS частично парсить объект и ему нужно передавать всю строку, а в JAVA движке он может читать частично и все в этом духе.
В любом случае, речь идет о написании своей БД. Проще использовать в крайнем случае https://www.sqlitetutorial.net/sqlite-nodejs/, а лучше нормальную бд, потому что вам в любом случае придется возиться с бинарными структурами, смещениями и всем прочим вместо линейного чтения всего файла до первого попадания. Так же использовать индексы и куча другого геморроя, который вы не хотите (я уверен).
Поправьте меня, но вы читаете миллион файлов в секунду? Ну это многовато, даже если дескрипторы файлов таскать через сервис и не закрывать их, все равно. Асинхронный код тут ни при чем. Более того, чтение из файла физически всегда асинхронное по своей природе, поэтому можно дать потоку заняться чём-то другим эти несколько сотен (тысяч?) тактов, пока мы ждём пока данные на диске подготовятся.
А чтобы не тормозило все приложение, нужно использовать Promise.all, но опять же, даже в данном примере у вас проблема не с асинхронностью, а с большим количеством случайных чтений с диска, что достаточно медленно и следует сериализовывать в большие структуры. И вообще использовать базу данных, а не файлы на ноде. Нода сильно не предназначена чтобы ворочать миллионы файлов
На самом деле, функция не обязательно должна быть асинхронной. Она может спокойно возвращать / пробрасывать наверх промис, если конкретно для неё информации из этого нет. Ну или можно добавить старый добрый then, а асинхронность добавлять когда уже идёт финальное использование функции. Это позволит не генерировать стейт машину с while (true) (я сейчас говорю конкретно по тому, как это делает babel с js) внутри каждого уровня абстракции. Но это экономие на спичках — если на просадку в скорости веб-сервера заметно влияет async — nodejs не подходящая платформа для вашей задачи, во всех остальных случаях время отъедает что-то другое. Да даже обращение к ssd будет в несколько сотен раз медленнее чем интерпретация async функции и избавление от неё (не знаю, с переносом в веб-воркер с синхронной логикой например) вряд ли сильно поможет.
Если вы, конечно, не рассчитывает орбиту Аринсторфа, вызывая в методе Ронге Кута асинхронный обсчёт для каждой итерации. Тогда это просто корявая архитектура.
Не всегда просто. Особенно если это большие компоненты, а бизнес-логика требует. Из личного: были две панели на одной странице, никак между собой не связанные. А потом оказалось, что одна панель при сохранении может обновлять данные другой панели. Логики в каждой панели просто невероятное количество, из общего — только ключ страницы, в которой используются оба. Нужно было сделать сигнализацию из одной панели в другую. В редаксе элементарно, в мобх зависит от использованного "над-фреймворка", но обычно тоже просто, тут нужно либо странный общий ключ у общего родителя, либо какую-то систему сигнализации. И задача не такая уж и редкая, если это полноценное веб-приложение с сложной и постоянно изменяющейся бизнес-логикой.
Да запросто. У вас есть 50 записей чего-то + фильтр (ну или сортировка). И черт с самим фильтром, быстро работает, а вот сбрасывание shallow compare (ну или shouldComponentUpdate) — большая проблема. Нужны уже реселекторы всякие там, чтобы computed всегда возвращал одно и то же значение.
Ах да, прошлый раз забыл: а что там по рефакторингу? Если я захотел переименовать user в profile — мне идти по всему коду и менять надпись? Селекторы как абстракция придуманы не просто так (в mobx это проще, потому что всегда прямая ссылка на поле, ts справится с переименованием).
Если я открыл страницу с ресурсом id = 1, затем id = 2, затем вернулся на 1 — зачем мне его перезагружать?
Нормализованных. Пример: у меня есть список всех лекций, а на панели слева список текущих лекций. Я переименовал одну лекцию — как панель слева узнает о том, что я это сделал? Логично использовать нормализованную структуру:
Изменения в одном месте отражаются сразу во всем приложении. Только у меня таки "таблиц" в терминах БД 50+. И, как я сказал, если их хранить все в рутовом ViewModel, тогда он вырождается в редакс (только без тайм тревела, логирования, мидлвейров, саги). Если их хранить в виде иерархии ViewModel — как они будут сигнализировать об обновлении?
Это жуткий недостаток для меня. И для всех, кто хоть раз пытался рефакторить более-менее крупный проект, полный этого чертового get.
С архитектурной точки зрения, при unmount запросы должны отбрасываться либо их результат игнорироваться. Как минимум, не должно мигать пол страницы. Впрочем, тут только rxjs молодцом, с сагой еще можно извернуться, остальные технологии требуют достаточно больших телодвижений и спасает, что обычно данные в дочерних компонентах никому не нужны и факт их загрузки никому не мешает.
Это приведет, со временем, к миграции всего в рутовый ViewModel. В лучшем случае, в рутовый для модуля, а не всего приложения.
Простой пример: у вас есть список предметов ученика с оценками по ним. Идем по пути "Самый очевидный вариант — да, рендерить ViewModel на каждого пользователя.". Скажем, по каждому предмету еще тыкать можно, оценки там менять, заметки добавлять, преподавателя смотреть. Появляется задача — показать средний балл. Что ж, поехали все наши ViewModels для каждого предмета вверх по стейту и теперь есть общий ViewModel, который хранит список предметов. А теперь вам нужно эту оценку для каждого ученика в левой панели показать — опять все всплывает вверх. А потом среднюю по всем ученикам… И динамику, заодно.
Абстрагируясь от идеи вписывания бизнес-логики во вью (это, в целом, плохо по множеству причин, но может быть иногда достаточно удобно), я бы подсветил несколько моментов.
Стоит убрать FaaC (function as a child) в пользу хуков. Сильно сократит и упростит код. В разы.
Показал бы в примерах как это тестировать.
Как вызвать метод контроллера компонента сверху? (Окей, диспатч или более странный способ через $set, допустим. К слову, в редаксе нельзя напрямую писать в store, никогда не задумывались почему?)
Как среагировать на изменение состояния соседа? А что если сейчас вам не нужно связывать две панели между собой и вы создали достаточно объемную ViewModel в каждом из них, а потом вдруг понадобилось их связать (они стали взаимно зависимыми)?
У меня есть список пользователей. Каждый раз я открываю пользователя — я должен его догрузить. Но у меня еще есть N методов для каждого пользователя. Как вы это организуете в своем фреймворке? Каждый пользователь — отдельный ViewModel? А как тогда будете кешировать пользователей?
Продолжение 5-го пункта. У меня в реальном проекте более 50 доменных объектов (это мы еще плохо нормализовали данные). И они, к сожалению, достаточно сильно связаны между собой. У вас вырадится в редакс? Или будет иерархия из 50-ти вложенных контекстов?
Как "прервать" / отбросить / отменить асинхронный метод? Что если я уже успел покинуть viewModel, которое еще не успело что-то загрузить, при этом оно перепишет какое-то значение родителя?
К слову, как в методе контроллера получить значение чужой viewModel?
Самое главное: зачем это все, если есть useReducer и useContext, которые позволяют получить все тоже самое? Ну вместо $set будет у вас dispatch({type: 'set'}), обертку можно легко сделать.
P.S. странно, у последних абзацев должны быть цифры 7, 8 и 9, не знаю что поломалось.
А что, идея — скомпилировать chrome в wasm, и уже в нем открывать свой сайт. Никаких полифилов и проблем с кроссбраузерностью!
Интересная технология, но не понятно назначение. Нет бы сделать упрощенный HTML, я бы назвал его AHTML (application html), специально под нужды веб-приложений, да порезанный css для него без всяких там float, а так же возможность делать wasm расширения для фреймворков (условно говоря, собственный многопоточный рантайм для условного реакта/ангулара), чтобы js обрабатывал только бизнес-логику, а не весь процесс рендеринга, так все хотят втянуть рантайм огромных кросс-платформенных фреймворков с собственным движком рендеринга, т.е. сделать браузер в браузере.
Осталось портировать под wasm эмулятор андроида и вместо веб-приложений запускать андроид-приложения в браузере под wasm.
Я когда-то искал. Раньше было 4ГА, сейчас около 1.5 гектар. Это не считая многоэтажной гидропоники
Gmail надоел отклонять письма с вложениями на подобие zip. Но про аутлук действительно иногда не получает письма, прям бесит. Но пока не нашёл удобного, желательно self-hosted аналога с возможностью продвинутой фильтрации, но и не создающим невероятное количество геморроя
Знаю, что он не популярен в рунете, да и это шило на мыло, но все же Gmail > outlook.com. По крайней мере, в нем есть гораздо более продвинутые правила сортировки писем из серии "показывать только последнее письмо от X в inbox, остальные перемещать на месяц в папку Y, после чего удалять"
Используя css-modules столкнулся с проблемой, что в библиотеках иногда селекторы довольно многословны и, поэтому, имеют высокий приоритет и просто с использованием модулей (ровно как и styled-component) перебить без impotant их иногда не выходит. Жутко раздражает, хотелось бы, конечно, иметь более декларативный способ описания приоритета стиля, чем через селектор.
Вообще так и 1password и keepass умеет. Если под ключницей подразумевается хромовская или встроенная мак осная — у нее фатальный недостаток.
Ну узкофюзеляжный бомбардир сильно шумнее А320, да и мне не повезло сидеть на последнем ряду прямо у крепления двигателя. Скажем так, звук ощущался всем телом. Но в целом, в метро с тихой музыкой (на половину громкости) само метро не слышно вообще так что нареканий у меня нет
Без музыки шум слышен даже от переодики. Однако хватает даже очень тихой расслабляющей музыки (или, не знаю, белого шума, например, он на удивление хорошо отсекается самим мозгом через несколько секунд) чтобы приглушить все голоса в офисе и даже крик ребенка в самолете.
Но у меня к звукодаву другой отзыв: очень непривычное ощущение мира — пропадает звуковой отклик от повседневных вещей и, оказывается, первое время это воспринимается странно. А костная проводимость только делает все хуже — слышно как некоторые вещи распространяются через пол и кости в уши — какие-то высокочастотные звуки, но быстро привыкаешь. К слову, подозреваю что фоновый шум от самолета слышен тоже только из-за костной проводимости, а не через сами наушники. Ну или может они все же не могут заглушить ревущий в полтора метрах двигатель Bombardier Challenger 800
Почему-то вспомнился сразу анонсированный MS Flight simulator 2020 https://www.youtube.com/watch?v=_TY56kA8oY0 Интересно, там похожая техника? На видео пока выглядит мягко говоря впечатляющее количество деревьев.
Интересная задача.
Вот интересно, слышал что в забугорье часто используются персональные номера (что-то между нашим ИНН и номером паспорта) и есть служба с API, в которой можно сверить эти данные на правильность. Но что самое интересное — эти номера содержат чек-сумму и проверяют на ошибку. Почему в России до такого не додумались? И вообще, номера и серия паспорта идут по порядку или все же кодируют какую-то информацию?
Edit: служба с API — налоговая. Они же эти номера и выдают.
Не очень понятно из текста каким образом определяется какой из номеров считается оригинальным в таком случае? Или сохраняются оба, просто с ссылкой друг на друга?
https://m.habr.com/en/company/plarium/blog/483958/
Прямо в рекомендациях к этой статье есть ваша же (!) статья с этой же темой, только другим оформлением от прошлого года. Это не считая сотни других статей, которые так же являются перепечаткой документации. В 2021 году будет такая же статья?
А вообще я вот подумал, даже интересно результат увидеть. Сделайте честный тест на js/ts, примерно такой:
Мы не можем держать в памяти 1 млн объектов, многовато, поэтому будем генерировать их на лету:
и его асинхронную версию
И дальше две функции: searchSync, searchAsync.
Потом сравните производительность одного запроса. И производительность нескольких запросов (время выполнения одного запроса должно вырасти, но суперпозиция асинхронной версии должна быть быстрее, стартовая гипотеза). И можно даже больше заморочаться — запустить ноду как кластер и посмотреть как изменятся показания.
Я даже не прошу заморачиваться с параллельным асинхронным поиском в данном случае. Тогда это будут действительно репрезетативные данные.
P.S. PreciseTime, само собой, не может быть while (true) внутри очевидно, так что придется повозиться, впрочем можно обойтись, конечно, и setTimeout(1);
Так, поправьте меня, если я не прав, но вроде как если хранить JSON внутри файла, вы не можете гарантировать сдвиг до нужного объекта внутри файла. Как следствие — вам нужно прочитать все строки перед этим JSON до того, пока вы найдете нужный, вы не можете сказать просто read(offset struct_size, (offset + 1) struct_size) (ну или в этом духе, не важно).
Как следствие, каждый раз вы ищите файл. Синхронный код в java может работать быстрее по множеству причин, в том числе сама асинхронность само собой увеличивает издержки, но так же тут может участвовать что угодно, например, неумение JS частично парсить объект и ему нужно передавать всю строку, а в JAVA движке он может читать частично и все в этом духе.
В любом случае, речь идет о написании своей БД. Проще использовать в крайнем случае https://www.sqlitetutorial.net/sqlite-nodejs/, а лучше нормальную бд, потому что вам в любом случае придется возиться с бинарными структурами, смещениями и всем прочим вместо линейного чтения всего файла до первого попадания. Так же использовать индексы и куча другого геморроя, который вы не хотите (я уверен).
Я, например, не уверен можно ли в ноде вообще считать с 1000 по 2000 байты файла, не помещая весь файл в буфер.
Поправьте меня, но вы читаете миллион файлов в секунду? Ну это многовато, даже если дескрипторы файлов таскать через сервис и не закрывать их, все равно. Асинхронный код тут ни при чем. Более того, чтение из файла физически всегда асинхронное по своей природе, поэтому можно дать потоку заняться чём-то другим эти несколько сотен (тысяч?) тактов, пока мы ждём пока данные на диске подготовятся.
А чтобы не тормозило все приложение, нужно использовать Promise.all, но опять же, даже в данном примере у вас проблема не с асинхронностью, а с большим количеством случайных чтений с диска, что достаточно медленно и следует сериализовывать в большие структуры. И вообще использовать базу данных, а не файлы на ноде. Нода сильно не предназначена чтобы ворочать миллионы файлов
На самом деле, функция не обязательно должна быть асинхронной. Она может спокойно возвращать / пробрасывать наверх промис, если конкретно для неё информации из этого нет. Ну или можно добавить старый добрый then, а асинхронность добавлять когда уже идёт финальное использование функции. Это позволит не генерировать стейт машину с while (true) (я сейчас говорю конкретно по тому, как это делает babel с js) внутри каждого уровня абстракции. Но это экономие на спичках — если на просадку в скорости веб-сервера заметно влияет async — nodejs не подходящая платформа для вашей задачи, во всех остальных случаях время отъедает что-то другое. Да даже обращение к ssd будет в несколько сотен раз медленнее чем интерпретация async функции и избавление от неё (не знаю, с переносом в веб-воркер с синхронной логикой например) вряд ли сильно поможет.
Если вы, конечно, не рассчитывает орбиту Аринсторфа, вызывая в методе Ронге Кута асинхронный обсчёт для каждой итерации. Тогда это просто корявая архитектура.