VoidVolker

Лучше для чего? А так, в целом, третий наиболее оптимальный вариант - 4 нормальных ядра в сравнении с парой в первом, а 32 гигов ОЗУ вполне хватит еще года на три-четыре. Ну и плюс он легче.

Прокрутить страницу "что нового" до нужного пункта и прочитать религия не позволяет, да?
https://code.visualstudio.com/updates/v1_82#_comma...

NOTE: If you would rather not have the Command Center visible, you can right-click on the title bar and uncheck the Command Center entry in the dropdown to hide it.

Прочитать документацию по Document.querySelector() и Document.querySelectorAll(), осознать разницу между двумя методами и использовать подходящий.

Никак. Выбор инструмента - это задача тимлида и/или техлида. Т.е. ведущего/главного разработчика, отвечающего за принятие ключевых технических решений. Ваша задача, как заказчика, четко оформить требования, ограничения и сформировать начальное ТЗ и описание, что вам требуется от проекта, прототипы интерфейса, например. Без вникания в технические детали. Т.е., "хочу чтобы были фичи такие-то и работил они так-то, ограничения такие-то, требования такие-то". Далее уже задача найти разработчика/команду с большим или достаточным для данного проекта опытом. Далее из начального ТЗ формируется полноценное техническое задание: описывается весь требуемый функционал, рисуется дизайн, прописываются требования, ограничения и прочие хотелки. И на основе ТЗ, тим/тех лид уже подбирает/подбирают наиболее оптимальные и конкретные инструменты и решения, основываясь на собственном опыте и знаниях для конкретно этой задачи. Например, если человек хорошо знает несколько разных инструментов и есть достаточный опыт их использования - он может реализовать проект используя любой из них как одинаково хорошо, так и одинаково плохо. У разных ЯП и фреймворков свои плюсы и минусы. Далее из ТЗ формируется более детальное ЧТЗ и происходит разработка проекта.

Вот вы говорите:

Нужно будет выполнять много запросов к БД

Важная быстрая скорость работы нашего сайта

Много/быстро это сколько? 100 запросов в час? 1000 в минуту? 1М в секунду? Загрузка страницы за 30/10/1с или даже 100мс? А к какой именно БД? Какая характеристика самих данных и какого типа запросы? На какое количество соединений? В каком регионе? Есть ли там тяжелые или еще какие-то вычисления? Медиа файлы - картинки, видео? Тут очень много нюансов. В идеале следует определиться с конкретными значениями/параметрами и их описать в ТЗ. Ну или определить примерное, а фактическое значение определить на стадии прототипа/MVP и/или провести какое-то исследование/тестирование. Можно потратить десяток лямов на написание крутого кода на го/расте/С++/ассемблере в течении года и все будет летать на простейшем сервере. А можно купить свой сервер за лям (ну, условно, конечно), нанять питонщика или PHP-ника за 300к и он за пару-тройку недель добьется такого же результата. Большинство веб-задач сегодня достаточно просто или с минимальными усилиями решаются абсолютным большинством решений для веба. Да, у всех решений есть свои плюсы и минусы.

Безопасность от всяческих XSS и SQL атак.

Вот с этим проще: использовать популярные OpenSource решения, регулярно проводить тесты, нанять отдельно опытного разработчика, красноглазика и пентестера - и тратить на них деньги, пока деньги не кончатся или не будет достигнут необходимый уровень безопасности. Безопасность противоположна удобству, защита отстает на шаг от атак. Риск есть всегда и надо просто быть готовым к последствиям и иметь запасной плат хотя бы в общих чертах.

А так - уже правильно посоветовали сразу брать дот-нет, т.к. у вас требование к использованию конкретной библиотеки для дот-нета.

Вот так: JavaScript -> Reference -> Classes

Либо просто добавить нужную функцию к объекту:

let o = {
    foo: function() { console.log('foo called') }
}

>> o.foo()
<- foo called

Array.prototype.slice()

А никак. Только виртуалка - parallels, utmapp или бета VirtualBox. Кстати, ваш спец софт-то существует в виде сборки под арм? Если нет, то учитывайте, что потеря производительности будет примерно 90% на виртуализацию x86.

Во-первых, у let блочная область видимости:

>> let a = 0;
<- undefined
>> window.a
<- undefined

Во-вторых:

function foo(x) {
  this.x++
}

Вот в этой функции, локальная переменная x и свойство x объекта this - это разные вещи.

Если хочется иметь функцию, которая будет менять определенное или произвольное свойство объекта window или произвольного объекта - то делать надо это явно и прямо. Например:

window.x = 0
window.x++

Или же:

let propName = 'a'
window[propName] = 0
window[propName]++

Первая же ссылка в гугле ведет на мануал:
https://developer.mozilla.org/ru/docs/Web/API/Wind...

Событие unhandledrejection происходит, когда Promise завершён с ошибкой, но на данную ошибку не установлен обработчик.

Т.е., надо сначала поймать ошибку:
checkError().catch(console.error)
И уже потом смотреть, что это за ошибка и исправлять уже её.

Да, можно, но только внутри квартиры. Кабель, находящийся за пределами квартиры - собственность провайдера. Да, зачастую такой кабель может продолжать висеть многие годы, но факта собственности не отменяет. Кроме того, кабели могут идти в разные точки за пределами квартиры - как результат, придется все равно соединять два кабеля. Если так хочется восьмерку - просто попросите провайдера заменить кабель. Обычно идут на встречу и без проблем меняют. А если не захочет - просто переключитесь на тариф 100+ мегабит и провайдер все равно заменит кабель. А потом можно обратно на старый тариф переключиться. Лучше иметь кабель без дополнительных врезок и соединений - это в лучшую сторону сказывается на качестве соединения.

Конечно: достаточно просто в цикле пройтись по списку каталогов и сохранить отдельно в нужный массив названия каталогов.