Сразу хочется подчеркнуть - я ни в коем случае не призываю не использовать фреймворки вообще. Любой фреймворк умеет рисовать интерфейсы и справляется с этим довольно хорошо, согласен, что было бы глупо отказаться от их использования. Что касается ванильной разработки, это как раз отлично ложится в предложенный мной подход - нужно переписать на чистый js, по каким-то причинам, пожалуйста, но переписывается слой отображения, а не вся логика приложения. Чтобы такое было возможно нужно изначально закладывать правильную архитектуру. Мой посыл в том, чтобы перестать пихать логику приложения в ui, интерфейс должен заниматься только получением и рендером данных.
Ну, не знаю как везде-везде, но фронт в среднем по больнице строится на Фичах
Проблема в том, что папка features решает вопрос раскладки файлов, но не решает вопрос архитектурных границ. На практике получается примерно следующая ситуация, например: features/cart импортирует хук из features/user, чтобы проверить скидку и со временем граф зависимостей превращается в нераспутываемый клубок, где все фичи зависят друг от друга.
Про топор и смену ручек. К сожалению в крупных долгоживущих проектах "ручку" меняют постоянно - меняются поколения стейт менеджеров (Redux -> MobX -> Zustand -> Signals), фреймворки меняют подходы и обратную совместимость (Vue 2 -> Vue 3, React Class Components -> React Functional Components + хуки), появляется необходимость в гибридных мобильных приложениях. И это все нужно поддерживать чтобы сохранять поддержку интсрументов от разработчиков, чтобы шагать в ногу со временем и находить новых разработчиков, которые ничего не слышали про прошлое поколение тулзов.
Вообще эта статья задумывалась как открывающая для цикла статей по архитектуре фронта. Тут я хотел описать общие теоритические концепции и поверхностный обзор подхода, возможно из-за этого веет нейрослопом). В следующих статьях планирую показывать поэтапное построение независимого ядра с конкретными примерами кода и подробными объяснениями.
Вот не очень понимаю, что эти 2-3 секунды перекомпиляции вам дадут. Зачем каждую секунду править свой код, может лучше подумать, что конкретно нужно написать? А если так хочется постоянно что-то вводить, то настройте перекомпиляцию по ctrl + s. В любой ide это возможно. В крайнем случае, писали выше, у вебпака можно задержку выставить.
Единственный недостаток при сборке вебпаком, а может и не только им, в том, что не работают сорсмапы для изолированных стилей. Если у кого-нибудь есть решение этой проблемы, то с радостью послушаю!
Спасибо за развернутый коммент!
Сразу хочется подчеркнуть - я ни в коем случае не призываю не использовать фреймворки вообще. Любой фреймворк умеет рисовать интерфейсы и справляется с этим довольно хорошо, согласен, что было бы глупо отказаться от их использования. Что касается ванильной разработки, это как раз отлично ложится в предложенный мной подход - нужно переписать на чистый js, по каким-то причинам, пожалуйста, но переписывается слой отображения, а не вся логика приложения. Чтобы такое было возможно нужно изначально закладывать правильную архитектуру. Мой посыл в том, чтобы перестать пихать логику приложения в ui, интерфейс должен заниматься только получением и рендером данных.
Проблема в том, что папка features решает вопрос раскладки файлов, но не решает вопрос архитектурных границ. На практике получается примерно следующая ситуация, например: features/cart импортирует хук из features/user, чтобы проверить скидку и со временем граф зависимостей превращается в нераспутываемый клубок, где все фичи зависят друг от друга.
Про топор и смену ручек. К сожалению в крупных долгоживущих проектах "ручку" меняют постоянно - меняются поколения стейт менеджеров (Redux -> MobX -> Zustand -> Signals), фреймворки меняют подходы и обратную совместимость (Vue 2 -> Vue 3, React Class Components -> React Functional Components + хуки), появляется необходимость в гибридных мобильных приложениях. И это все нужно поддерживать чтобы сохранять поддержку интсрументов от разработчиков, чтобы шагать в ногу со временем и находить новых разработчиков, которые ничего не слышали про прошлое поколение тулзов.
Вообще эта статья задумывалась как открывающая для цикла статей по архитектуре фронта. Тут я хотел описать общие теоритические концепции и поверхностный обзор подхода, возможно из-за этого веет нейрослопом). В следующих статьях планирую показывать поэтапное построение независимого ядра с конкретными примерами кода и подробными объяснениями.
Вот скрин http://take.ms/pIYE4.
Единственный недостаток при сборке вебпаком, а может и не только им, в том, что не работают сорсмапы для изолированных стилей. Если у кого-нибудь есть решение этой проблемы, то с радостью послушаю!