Карлиндоу Мэрлифи

Почему у введенного числа в input тип данных(typeof) -string?

Так проще, т.к. неизвестно, что именно прилетит из input, а тут по умолчанию - string, а дальше Ваши проблемы.

Установите отладочный прокси-сервер (HTTP debugging proxy) вроде Mitmproxy на компьютер и настройте пропуск трафика вашего приложения через этот прокси. В его интерфейсе можно просматривать HTTP-запросы, а также сообщения WebSocket и некоторые другие протоколы. Также можно останавливать и модифицировать запросы/ответы на лету и писать скрипты для этого.
Ещё один инструмент, который также позволяет перехватывать и модифицировать запросы/ответы на лету: https://github.com/projectdiscovery/proxify. Он вдобавок поддерживает модификацию трафика по правилам, описанным на специальном DSL (языке).
Настроить прокси на Android можно в параметрах Wi-Fi сети (для всех соединений в системе), либо с помощью приложения ProxyDroid (только для соединений вашего приложения, но нужен root).

Возможно это поможет

_string.replace(/[^a-zа-яё\u4E00-\u9FFF0-9 `,:-]/gim, " ")

\u4E00 - начальный символ диапазона китайских иероглифов в кодировке Unicode.
\u9FFF - конечный символ диапазона китайских иероглифов в кодировке Unicode.

Поменяй шейдер на Distance Field SSD
Поменяй Sharpness на 1
Поменяй Perspective Filter на 0
Сделай Toggle Extra Padding off (TextMeshPro - Text (UI) component -> Extra Settings)

Внутри фреймворка, за счёт эффекта масштаба, могут быть реализованы оптимальные алгоритмы и применены какие-то оптимизации, ухудшающие читаемость кода, но ускоряющие его, которых может не быть в том ванильном коде, который напишете вы. Но, конечно, это редкий сценарий и в общем случае код без фреймворка будет работать быстрее или так же (Svelte).

Ответ - и да и нет.

Обычно классический ЯП - предполагает прямое (директивное) управление процессом.
И качество оптимизации будет сильно зависеть от того как программист проработал весь прямой ход алгоритма.
В том числе работу с I/O и сетью.

Фреймворк - это ограничитель, который очень строго лимитирует присуствие программиста в результирующем
коде. В идеале программист делате только хендлеры. Или лямбды. Как в Inversion of Control.
Это позволяет хорошему фреймворку сильно соптимизировать поток выполнения базируясь
на том что I/O и сеть будут обеспечиваться фреймворком а программист будет вставлять только лямбды.
Кроме сети и ввода-вывода фреймворк может обеспечивать пул объектов (соединения с БД)
и типичные шаблоны обработки ошибок (retry-pattern) перформанс (cirquit-breaker) и
рейт-лимитеры и троттлинг.

Очень хороший программист который в этом разбирается может улучшить использование
фреймворка а иногда и полностью его заменить. Это будет очень медленно в разработке и дорого в оплате.

Но мы исходим из предположения что 80% программистов - середнячки и звезд с неба не хватают.
Поэтому для них фреймворк - является предпочтительной методикой. И код с фреймворком
скорее всего будет быстрее чем при прямом кодировании на той-же выборке кодеров-середнячков.

Вообще-то 90% задач в JS предполагают, что решительно всем решительно похрен, что там в попугаях.
Лишь бы не глючило и можно было легко исправить.
Язык, просто-таки предназначенный для фреймворков.
Во всяком случае, его браузерная часть.
А если вам позарез понадобились реальные оптимизации - так пишите не на ванили, а на чем-нибудь низкоуровневом и собирайте в WebAssembly,

Фреймворк за счёт внутренних оптимизаций может работать быстрее, чем плохо написанный ванильный код.
Хотя даже это по большей части работает на синтетических примерах.

Самый наивный из них:
Например, вам надо добавить 10 000 узлов в DOM.
Плохо написанный код будет выглядеть как цикл, на каждой итерации которого вы будете обращаться к DOM API, добавляя элемент.
Хорошо написанный код (как и код, который сгенерирует фреймворк, вероятнее всего) в цикле соберёт всё необходимое и по окончании одним запросом к DOM API вставит на страницу.

С таким func.cjs у меня всё работает:

function say(x){
    console.log(x)
}

exports.say = say;

Нода 18.15

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

Можно использовать await в сочетании с setTimeout

Например:

async function wait(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function Looooool(){
  console.log("подождите 5 секунд");
  await wait(5000);
  console.log("прошло 5 секунд");
}