я так думаю что хейт не на express, а на проекты которые он порождает. В 80% это жоская каша, даже без намека на архитектуру. Но на express можно тоже нормально написать, если разделять на слои

тем что фреймворк должен заставлять вас писать хороший код. Миддлвары никак не запрещают мутировать req/res и этим они плохи

Можно провести хорошую аналогию с Vue2 и Vue3. Vue2 ведет себя как экспресс - "все кишки наружу"

во Vue3 теперь private instance и public instance (то как вы видите компонент изнутри и снаружи) - разделены

и теперь ОЧЕНЬ много вещей, которые МОЖНО было сделать во vue2 не работают во vue3 и это хорошо

Это уже другая проблема, но она не из-за самого экспресса, а из-за огромного количества курсов и им подобных, которые так учат

можно сказать что Vue3 сейчас заставляет писать хороший код лучше чем react?

потому что мне кажется что react вообще этим не занимается

я вообще не знаю как их сравнивать

как сказал Илья, экспресс(любой фреймворк) должен заставлять писать хороший код

Согласен, но тут вопрос. Вот я работал с express, nest, всякими strapi, hapi и смотрел fastify. В принципе, если бездумно делать по доке - то все равно получишь очень плохо пахнущий код. То есть условно говоря, экспресс позволяет делать все, что угодно, остальные фреймворки дают небольшие ограничения, но все равно хороший код не получится без знаний.

А если у тебя есть знания, то ты и на экспрессе напишешь хорошо, но потратишь чуть меньше времени на это. Ну это то, как я вижу.

я не соглашусь про "чуть меньше" времени потратить на экспрессе если мы говорим о хорошем коде на экспрессе

Чем больше ограничений - тем лучше. И вопрос не только в "напишешь" но и в командной работе

Про "чуть меньше" я имею в виду что-то наподобие описанного мной выше пример

Дано: нужно не допускать для отдельных роутов клиентов без токена или с не валидным токеном.

Как я это решаю в экспрессе. У меня есть сервис аутентификации, я создаю мидлвар, который передает в этот сервис токен и случае если проверка не прошла кидает 401

Дальше я вставляю через use над всеми приватными роутами этот мидлвар.

Как это предлагается решать в том же несте

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

И я не могу в одном месте поставить этот декоратор, я ставлю его над каждым приватным эндпоинтом.

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

Вопрос, если я все равно вставляю одну и ту же логику, зачем мне писать в 10 раз больше кода? Замутировать что-то я могу и там и там, сделать плохо могу и там и там.

потому что явное лучше неявного

это как регулярные порывы "как мне сделать во вью что-нибудь доступно глобально" с примешиванием к прототипу и так далее

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

Там проблема в том, что с учетом декораторов сваггера и других получается над каждым эндпоинтом по 10 декораторов и читать класс становится невозможно даже для простого crud с 4мя методами, поэтому приходится очень сильно выкручиваться, например делать отдельно классы с приватными эндпоинтами, отдельно с публичными.

Но вообще позиция стала яснее, спасибо)

можно композировать декораторы

Но это тоже дополнительный оверхед + композиция декораторов накладывает лишнюю абстрактную сложность над читающим

Типо у тебя в одном декораторе ещё 5 декораторов, а там в одном случае ещё 3, в другом ещё 10 а там ещё ветвление (это утрированный пример, но все же)

В результате становится ещё хуже, на месяц ушел с проекта, вернулся и сидишь пытаешься вдуплить что вообще происходит

да, есть такое