image


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)


  1. Nadoedalo
    12.12.2016 16:01
    +1

    Почему бы не отказаться от jquery? В оригинальном Backbone всего-ничего зависимостей от него.


    1. denar90
      12.12.2016 18:24

      Мы в процессе. Вот первый шаг в этом направлении.
      Dom API
      Документация по этому API

      Все эти нововведения и больше появятся в v3.2.


  1. Unixspv
    12.12.2016 23:54

    В процессе изучения Marionette 3-ей версии, порою, очень сложно найти достойные архитектурные примеры, так как значительное количество литературы описано по 2-ой версии, с тем модульным подходом, который там был реализован, из-за чего, как мне показалось, полноценные модули ES6 сильно усложняют понимание новой версии. Переосмысленные типы представлений тоже иногда вызывают вопросы.


    1. denar90
      13.12.2016 00:16

      С этим конечно же проблема, но есть пару неплохих приложений с нормальной архитектурой

      reps-js (v3)

      v2, но архитектурно неплохо
      marionette-wires
      gistbook

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


  1. BasicWolf
    14.12.2016 23:14
    +1

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


  1. rogov_dmitry
    19.12.2016 03:31

    Эх. К большим сожалением поделюсь опытом — «сидел» на Марионетте начиная с первой версии. Смотрел на реакт, старался быть консервативным. Пару месяцев назад таки попробовал реакт — и всё, к сожалению, я стал делать все в разы быстрее и результативнее.

    В любом случае спасибо за фреймворк!