VoidVolker

Самый простой способ - тупо взять список функций из стандарта JS, сделать заглушку-логгер для каждой, далее загрузить страницу и смотреть в логе, какие функции были использованыы.

1. Проверить кодировку со стороны клиента
   
2. Проверить кодировку принимаемой строки при парсинге/валидации пришедших данных со стороны сервера
   
3. Проверить кодировку после парсинга строки и конвертации её в тип "строка"
   
4. Проверить кодировку при сохранении в БД
   

Во всех четырех случаях она должна совпадать.

Вероятно правильнее так:

function multiplier(x) {
    return number => number * x
}
let twice = multiplier(2)
console.log(twice(10))

function multiplier(x) {
    return function(number) {
        return number * x
    }
}
let twice = multiplier(2)
console.log(twice(10))

Что это за странное объявление функции?

Обычная стрелочная функция.

number => number * x
(number) => number * x
number => { return number * x }
(number) => { return number * x }

Использовать для чего-то простого - можно, а вот работать - нет. Например, виртуализация x86 в UTM (qemu) обходится примерно в потерю 90% производительности в сравнении с ARM машиной (т.е., разница в десять раз - сам проверял бенчмарком на двух виртуалках). Visual Studio 2022 сама по себе в целом работает без проблем в OSX, но вот на счет кросс-компиляция ничего не скажу - опций из коробки я там не увидел, а значит их нет и не факт что вообще возможно. Так что если нужна разработка под винду - либо виртуалка в облаке на x86 железе либо х86 девайс под боком с виндой плюс набор виртуалок с разными версиями винды для отладки/тестирования.
Касательно М1/М2 - девайсы отличные, производительность на высоте.

не могу понять почему не выполняется дальше код в цикле а окно просто виснет(не отвечает)

Потому что в основном потоке графического приложения в Windows обрабатываются системные сообщения и если в этом потоке начать выполнять тяжелый код, то естественно все будет виснуть. Поэтому в основном потоке работать только с UI, а любые вычисления надо запускать в отдельном потоке. Так что выводите все ваши вычисления, в т.ч. работу с сетью в отдельный поток.

Еще есть отличная либа Newtonsoft.Json.

mcigorli Использовать Canvas для рендеринга данных, а не SVG. Например https://canvasjs.com/. Если надо использовать только SVG - то тут только уменьшать количество отображаемых объектов на экране через создание нескольких слоев с точками с разным мастштабом и плавающее окно для реализации рендеринга только тех данных, которые видны. Пишите в личку хабра для контакта или свой контакт тут )
Вот в этом проекте я использовал C3.js и Vis.js - там SVG, 3 уровня данных для разного масштаба, общий объем - до нескольких десятков тысяч точек, но на каждый график в один момент времени пара десятков точек, примерно. И все работало очень быстро - отрисовать новый график с двумя десятками новых точек быстрее, чем отрисовать его один раз его на 1000 точек для масштабирования пользователем. В целом же, корни проблемы в том, что тысячи и десятки тысяч видимых объектов в DOM дереве приводят к его тормозам. Так что кроме канваса нет других вариантов, когда надо работать с большим количеством объектов.

IEnumerable - интерфейс, а List - класс, реализующий данный интерфейс. Любой класс может реализовывать несколько интерфейсов. Правильнее объявлять как есть - т.е. List, а там где, где нужен конкретный интерфейс/класс - просто делать каст. Обычно не требуется, т.к. IDE/компилятор еще стадии написания/компиляции кода проверяет наличие нужного интерфейса в передаваемом объекте. Соответственно, если ваш конструктор просит IEnumerable, но не разрешает List - проверяйте точнее, что именно нужно конструктору, т.к. если все правильно делать - то List он должен принимать.

Написано же, что переменная уже существует. Просто используйте другое имя.