Фреймворк

Идея

Во время размышлений над архитектурой ExpressJS и KoaJS, мою голову посетила идея client side MV* фреймворка. Основная концепция и отличие от фреймворков, с которыми я работал — сверхмодульность: все компоненты, которые необходимы в проекте подключаются через Framework.use(module), сам же фреймворк предоставляет исключительно скелет, строительные леса, которые обеспечивают только базовый API для работы подключаемых модулей.

Плюсы

Простота

Являясь развитием идей ConnectJS, Express в релизе версии 4.0 перестал включать в список своих зависимостей предка, тем самым избавился от большого количества middlewares, которые достались в наследство. KoaJS, являясь развитием идей первых двух фреймворков, не включает в себя даже механизм роутинга, оставляя решение этой задачи внешним модулям.

Чем проще фреймворк, тем легче понять его внутреннюю структуру. Для понимания Express достаточно понять принцип работы middlewares.

То же самое вероятно сработает и в контексте клиенского MV* фреймворка. Я нахожу простоту — залогом гибкости и устойчивости концепции.

Гибкие мажорные обновления

Недавно Эдди Османи рассказал об Object.observable — API, позволяющем заменить биндинги, которые используются во всех MV* фреймворках на нативную реализацию, которая работает абсолютно прозрачно, поверх объектов, без необходимости бесконечных плеяд из вызовов getter’ов и setter’ов.

К сожалению, в ближайшее время вряд ли можно увидеть использование нового API в MV* фреймворках: не считая проблемы с кросс-браузерностью, монолитный Backbone не может просто взять и отказаться от legacy-кода.

Для сравнения, чтобы попробовать генераторы, скажем, в KoaJS, достаточно просто поставить послендюю unstable-версию NodeJS и запустить ее с флагом —harmony. В браузере же так просто справиться с Object.Observable не получится.

Если же иметь модульный фреймворк, то подключить, если можно так выразиться, unstable-реализацию можно всего лишь написав необходимый модуль, и подключив его к хост-фреймворку: Framework.use(webkitObservableModels).

Готово.

Гибкие минорные обновления

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

Только необходимое

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

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

Open Source Friendly

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

Форк Backbone? Такое я последний раз слышал на YAC от SoundCloud. Популярный форк Angular? Ember? Этого я не слышал. Контрибутить в эти фреймворки не просто: у монолитной системы есть большое количество пользователей, которые не могут просто так перейти на другой API. Такой подход поддерживает интерфейсы для устаревших систем. Это бремя несколько ограничивает фреймворк в развитии.

К примеру, jQuery потребовалось много времени для выпуска версии 2.0, без поддержки устаревших браузеров. В это время успели появиться различные альтернативы, такие, как Zepto.

Модульность же, при хорошей структуре самого фреймворка, позволяет легко контрибутить в независимые модули, добавляя поддержку новых фич, обрезая старое. Проблему совместимости можно решить с двух сторон одновременно — хорошим менеджером зависимостей (в этом плане, одна из лучших систем, на мой взгляд — npm), и форками/новыми модулями в случае действительно кардинальных изменений компонента.

Минусы

Порог входа. Модульность — это развитие простоты Backbone. Но, тут, как с Gulp и Grunt. Первый проще, но порог входа значительно выше.
Зависимость от качественного проектирования основной части фреймворка. Но эта проблема присутствует везде. Едва ли в этом случае она представляет что-то особенное.
Проблема качества сторонних модулей. Из-за низкого порога входа, этой проблеме подвержено все JS-коммьюнити.
И еще миллионы минусов, разумеется.

Итог

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

Мне было бы интересно поучаствовать в разработке такой структуры, но вряд ли я в ближайшее время буду этим заниматься: в одиночку вряд ли можно спроектировать гибкую систему — очень высок риск попасть в плен собственного опыта, создав слишком специфичную систему. Так что я буду держать эту идею на подкорке. Буду рад любой критике, советам, предложениям. :)

28.07.2014