Концепция компонентов, несмотря на свою привлекательность и стройность, на практике показывает себя неудобной и тяжелой на подъём.
Для того, к примеру, чтобы поднять новое приложение, требуется изрядное количество операций: инициализация настроек с зависимостями, проверка правильности имён, создание дополнительных файлов, запуск билда через консоль, специальная инициализация приложения. Компоненты теперь требуются по commonJS-нотации. Разработка с компонентами сопровождается постоянным билдом ручками через консоль, если не поставить спец. утилиты. Если ставится вопрос о подключении нового кода - пишется новый компонент, что несколько сложнее, чем, скажем, писать jquery-плагин. И не факт, что получится подключить его как локальную зависимость: как это сделать, нигде не показывается и не говорится, получается, требуется репозиторий под компонент.
Ситуацию делает абсурдной тот факт, что, несмотря на революционные стремления отказаться от jquery и использовать только по-минимуму необходимого, большинство компонентов имеют jQuery в качестве зависимостей, и маловероятно откажутся от него. В итоге получается ситуация, что и с плагинами jQuery: их сотни, но часто проще и дешевле писать самому, чем использовать готовый.
В итоге, вся эта компонентная ажитация предлагает в перспективе процесс разработки, основанный на том, что прежде написания функции следует перерыть репозиторий компонентов в поисках оной, что, между прочим, весьма затруднительно, так как заранее можно не догадываться о точном названии функции, да и в прочем сервис весьма фрустрирующий по удобству использования; а после того, как функция найдена не будет, предлагается писать свой компонент, который писать в N>1 раз и на M>0 телодвижений сложнее, чем писать функцию/плагин/класс в отдельном файле.
В итоге, компоненты в качестве плюсов предлагают мнимую выгоду в виде образования единого скомпиленного файла (который, впрочем, не лучше скомпиленного грантом), мнимого разрешение проблем с зависимостями (которые не менее просто разрешаются require-js), готовой базы минималистичных компонентов. Последний пункт в теории перекрывает все минусы, но на практике даже небольшой проект с простыми компонентами будет весить под треть мегабайта кода.
Более того, если вдруг захочется сделать npm-package компонентом, то придется ощутить безысходность и тлен этого мира.
Для того, к примеру, чтобы поднять новое приложение, требуется изрядное количество операций: инициализация настроек с зависимостями, проверка правильности имён, создание дополнительных файлов, запуск билда через консоль, специальная инициализация приложения. Компоненты теперь требуются по commonJS-нотации. Разработка с компонентами сопровождается постоянным билдом ручками через консоль, если не поставить спец. утилиты. Если ставится вопрос о подключении нового кода - пишется новый компонент, что несколько сложнее, чем, скажем, писать jquery-плагин. И не факт, что получится подключить его как локальную зависимость: как это сделать, нигде не показывается и не говорится, получается, требуется репозиторий под компонент.
Ситуацию делает абсурдной тот факт, что, несмотря на революционные стремления отказаться от jquery и использовать только по-минимуму необходимого, большинство компонентов имеют jQuery в качестве зависимостей, и маловероятно откажутся от него. В итоге получается ситуация, что и с плагинами jQuery: их сотни, но часто проще и дешевле писать самому, чем использовать готовый.
В итоге, вся эта компонентная ажитация предлагает в перспективе процесс разработки, основанный на том, что прежде написания функции следует перерыть репозиторий компонентов в поисках оной, что, между прочим, весьма затруднительно, так как заранее можно не догадываться о точном названии функции, да и в прочем сервис весьма фрустрирующий по удобству использования; а после того, как функция найдена не будет, предлагается писать свой компонент, который писать в N>1 раз и на M>0 телодвижений сложнее, чем писать функцию/плагин/класс в отдельном файле.
В итоге, компоненты в качестве плюсов предлагают мнимую выгоду в виде образования единого скомпиленного файла (который, впрочем, не лучше скомпиленного грантом), мнимого разрешение проблем с зависимостями (которые не менее просто разрешаются require-js), готовой базы минималистичных компонентов. Последний пункт в теории перекрывает все минусы, но на практике даже небольшой проект с простыми компонентами будет весить под треть мегабайта кода.
Более того, если вдруг захочется сделать npm-package компонентом, то придется ощутить безысходность и тлен этого мира.