из-за типизаций и прочьей фигни

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

Экспресс там по дефолту, но его можно убрать/заменить при желании.

Модули можно сделать полностью совместимыми через интерфейсы, не переписывая всё на тайпскрипте

круто, спс, не знал

Всегда пожалуйста

https://docs.nestjs.com/techniques/performance

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

да я искренне не понимаю че все так против этих миддлварей

смотрел я видос с критикой миддлварей но он не сильно убедительный

если все обьекты или сущности как попало бездумно расширять ( как там с req и res) так можно в любом фреймворке накосячить

проблему прокладки между компом и креслом никакой суперязык с суперфреймворком не пофиксит :)

А вдруг? Напишут ИИ, которое будет за программистами косяки поправлять 😂

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

Можно думать об этом, как о том, сколько раз вам придется сыграть в русскую рулетку по пути от А к В. Лишний шанс умереть не дойдя всегда объективно плохо.

так на этот ИИ толпа индусни набежит и отключит его нафиг как еслинт и дальше наваливать начнет

ну согласен +-, но я все равно не верю что фреймворк помогает избегать глупости программиста, она просто приобретает другую форму в фреймворках с архитектурой из коробки

Оно не просто снижает дельту от вероятности получить ошибку в системе, но и стандартизирует ошибки, за счёт стандартизации практик написания кода(изи дебаг). Также, это облегчает расширение кода и его тестирование, т.к. заранее известно, где система может сломаться, а где это крайн маловероятно.

да не знаю, я то в основном фронтендщик и за бекендовский js ничего не скажу. Но приведу другие примеры скажем Angular - строго типизированный, ентерпрайзный, якобы багоустойчивый и скажем тот же Vue/Nuxt

так как вспоминаю этот Ангулар с коробочными фичами так вздрагиваю, его дебажить и понимать как работает никакой документации не хватит

и все сделано якобы чтобы защитить от дурака

Вы не одиноки в своих проблемах. Такое случается с целыми языками и тогда рождаются новые, как Go, например. Это результат именно возрастающей сложности и плохих решений по борьбе с ней.

В Go, например, только один способ написать цикл - using keyword "for ". Одно это решение помогает мгновенно понять, как выглядит код человека, который реализовывал цикл, даже не открывая его.

ну это понятно, может даже это и круто

честно говоря, я никогда не слышал такой формулировки в адрес Angular. Зато я слышал, что он очень богат фичами, а теперь вы говорите, что никакой документации не хватит ...и кажется все сходится.