«Почему мы снова говорим про архитектуру?»

[UltraPokemon]

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

Когда мы привязываем бизнес-логику к компонентам, мы теряем контроль над приложением.

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

Если не брать rerender.js (react) - остальные фреймворки дают реактивность, di и другие фичи, которые можно использовать при написании бизнес-логики. Зачем отказываться от благ человечества, которые нам даются из коробки, в пользу собственных решений?

Логика размазывается по всем слоям приложения.

Ну, не знаю как везде-везде, но фронт в среднем по больнице строится на Фичах. Обычно логика содержится в фиче и не выходит за нее. Потребители фичи могут как-то с ней взаимодействовать, но чтобы размазать логику по всему проекту - ну хз. Не то, чтобы имел много-много опыта на текущий момент, но такого ещё не встречал.

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

Если клиент толстый и фреймворк уже не справляется, и мы начинаем писать "core", отделяя его от "движка рендеринга", возможно стоит не использовать имеющиеся "движки рендеринга", а перейти на Натив.

Имхо, это избавит вас от всех "проблем" фреймворков и просто даст возможность легко самим адаптировать js-код с использованием браузерного api (DOM и тд) под core, который у вас уже есть. Думается, что написать document.querySelector и навесить listener будет проще, чем композировать компоненты на фреймворке, строить между ними связи и тд

[Kayun]

Спасибо за развернутый коммент!

Сразу хочется подчеркнуть - я ни в коем случае не призываю не использовать фреймворки вообще. Любой фреймворк умеет рисовать интерфейсы и справляется с этим довольно хорошо, согласен, что было бы глупо отказаться от их использования. Что касается ванильной разработки, это как раз отлично ложится в предложенный мной подход - нужно переписать на чистый js, по каким-то причинам, пожалуйста, но переписывается слой отображения, а не вся логика приложения. Чтобы такое было возможно нужно изначально закладывать правильную архитектуру. Мой посыл в том, чтобы перестать пихать логику приложения в ui, интерфейс должен заниматься только получением и рендером данных.

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

Проблема в том, что папка features решает вопрос раскладки файлов, но не решает вопрос архитектурных границ. На практике получается примерно следующая ситуация, например: features/cart импортирует хук из features/user, чтобы проверить скидку и со временем граф зависимостей превращается в нераспутываемый клубок, где все фичи зависят друг от друга.

Про топор и смену ручек. К сожалению в крупных долгоживущих проектах "ручку" меняют постоянно - меняются поколения стейт менеджеров (Redux -> MobX -> Zustand -> Signals), фреймворки меняют подходы и обратную совместимость (Vue 2 -> Vue 3, React Class Components -> React Functional Components + хуки), появляется необходимость в гибридных мобильных приложениях. И это все нужно поддерживать чтобы сохранять поддержку интсрументов от разработчиков, чтобы шагать в ногу со временем и находить новых разработчиков, которые ничего не слышали про прошлое поколение тулзов.

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