11 декабря 2016 Marionette.js исполняется 5 лет. Этот проект постепенно рос все эти годы. Его развивали сотни контрибьюторов, было создано сотни коммитов и десятки сотен проектов, которые используют Marionette. Мы были инновационными и были устаревшими. Мы видели как новые фреймворки приходят и некоторые уходят. Мы, возможно, никогда уже не будем новыми и модными, но мы будем делать все возможное чтобы постоянно двигаться вперед.
Почему Marionette.js?
В начале 2013-го мне было дано задание найти решение для постоянно растущих сложностей в RoundingWell приложении, которое использовало PHP и jQuery. Дизайн постоянно требовал все больше и больше взаимодействий пользователей с приложением. Поддержка такого состояния приводила к созданию хрупкого и сложного для понимания кода. Я обратил взгляд на frontend библиотеки, чтобы найти решение, и после исследования многих ресурсов чувствовал себя с Marionette более комфортно. На то время он имел активное сообщество, сама библиотека выглядела достаточно маленькой и гибкой для взаимодействия с сервером. Откровенно говоря, команда RoundingWell училась на лету. Нам нужен был маленький API, который мы могли бы быстро понять, а возможность быстро читать и понимать исходный код была потрясающей.
Мотивы, по которым люди выбирают Marionette сегодня, очень схожи. Для разработчиков, которые только знакомятся с javascript фреймворками это предоставляет чувство комфорта. Marionette имеет маленький и гибкий API, а кодовая база проста и легка в понимании.
Интерактивный и дополняемый
Новые разработчики, после года изучения чувствуют себя ужасно от постоянно растущего списка новых технологий, которые им возможно нужно знать. Они пытаются угнаться за новыми технологиями, которые популярны в сообществе, бросая то, что они уже знают. Стабильность воспринимается как стагнация и когда новые лучшие решения теоретизированы, текущие лучшие решения демонизируются.
Если вы разрабатываете довольно зрелый javascript фреймворк с практически стабильным API, что вы должны делать когда кто-то представляет вам улучшения в виде решений, имплементированых в другом фреймворке? Вы можете бросить свой текущий проект и начать переписывать все с использованием нового решения, и как результат, это обязательно затронет всех вокруг — они будут вынуждены делать то же самое. Но, честно говоря, это нереально. Более прагматичным и конечно же менее захватывающим будет обнаружить то, что работает сейчас и применить интерактивные и прогрессивные изменения, которые приблизят к лучшему решению. Это важно когда пользователи и контрибьюторы двигаются нога в ногу.
Marionette надеется улучшаться таким образом. Это может означать, что Marionette больше никогда не будет передовым, но также, что Marionette улучшается и вашему приложению не понадобится полный рефакторинг длительное время.
Оглядываясь назад
Наше путешествие не было идеальным. Я верю, что релиз Marionette v3 был амбициозным и изменил очень много вещей. Осуществленные изменения были хороши и очень нужны, но подготовка релиза заняла очень много времени. Конечно же нам нужна помощь всех, чтобы улучшить документацию и создать примеры, которые построены на третьей версии. Найти что-то свежее о третьей версии очень сложно, так как мы не уделили достаточно времени на создание новой информации и статей, а материалов о второй очень много. Это влияет на поиски. Вдобавок хочется сказать, если вы не пробовали новую версию — пожалуйста, сделайте это! Если вам нужна помощь — наше сообщество всегда с вами.
Смотря вперед
Смотря в 2017-й год, Marionette команда будет проводить маленькие релизы. Релизы новых версий в идеале будут в себе содержать маленькие и простые обновления, в то время как новые и захватывающие "фичи" будут релизиться в минорных версиях. Изменения, которые могут сломать логику ваших приложений, будут представляться в виде фича флагов или параллельно с существующей логикой. Разработчикам будет легко предугадать нововведения будущих релизов.
Наша главная цель не изменилась. Marionette стремится быть доступным, с маленьким и понятным API. Мы хотим, чтобы наш код был легко читаемым с четкой структурой. Мы хотим, чтобы Marionette был интерактивным как в подходе к изменениям исходного кода так и в применении его на реальных проектах. Marionette останется гибким. Мы будем предлагать лучшие практики, но большинство архитектурных решений, которые применимы к тому или иному проекту, лежат на плечах самих разработчиков. Скорее всего самая важная цель — поддержка нашего сообщества. В нашем сообществе всегда была превосходная взаимоподдержка и поддержка в создании контента который улучшает окружение фреймворка.
Спасибо. За следующие 5 лет!
» Автор
» Оригинал на блоге
» Оригинал на medium
» Репозиторий
» Сайт
Комментарии (6)
Unixspv
12.12.2016 23:54В процессе изучения Marionette 3-ей версии, порою, очень сложно найти достойные архитектурные примеры, так как значительное количество литературы описано по 2-ой версии, с тем модульным подходом, который там был реализован, из-за чего, как мне показалось, полноценные модули ES6 сильно усложняют понимание новой версии. Переосмысленные типы представлений тоже иногда вызывают вопросы.
denar90
13.12.2016 00:16С этим конечно же проблема, но есть пару неплохих приложений с нормальной архитектурой
reps-js (v3)
v2, но архитектурно неплохо
marionette-wires
gistbook
Если Вам интересно можете в процессе изучения попробовать одно из этих приложений перевести на 3-ю версию.
Пример того, как мы обновляли todomvc приложение.
BasicWolf
14.12.2016 23:14+1Наверное покажусь старым пердуном, но меня Marionette, по сравнению с современными фронтенд фреймворками, привлекает простотой. Соглашусь, немало приходится писать руками. С другой стороны, от и до понимаешь, что, где, когда и главное — почему происходит в приложении. Меньше магии и больше прямолинейного кода.
rogov_dmitry
19.12.2016 03:31Эх. К большим сожалением поделюсь опытом — «сидел» на Марионетте начиная с первой версии. Смотрел на реакт, старался быть консервативным. Пару месяцев назад таки попробовал реакт — и всё, к сожалению, я стал делать все в разы быстрее и результативнее.
В любом случае спасибо за фреймворк!
Nadoedalo
Почему бы не отказаться от jquery? В оригинальном Backbone всего-ничего зависимостей от него.
denar90
Мы в процессе. Вот первый шаг в этом направлении.
Dom API
Документация по этому API
Все эти нововведения и больше появятся в v3.2.