"Матрешкой по вебу". Интервью с разработчиком фреймворка Matreshka.js

Сегодня ко мне в блог заглянул Андрей Губанов - веб-разработчик со стажем и автор набирающего популярность фреймворка "Matreshka.js". Мы не стали ограничиваться одной Matreshka.js, а также поговорили на разные околопрограммерские темы. В общем, если вы программируете на JavaScript и до сих пор не попробовали Matreshka.js в деле, то самое время сделать это сейчас, а заодно почитать интервью.

Игорь Антонов: Расскажите немного о себе. Как пришли в программирование и мир JavaScript в частности? С какого языка начался ваш путь разработчика. По образованию вы программист или осваивали профессию самостоятельно?

Андрей Губанов: Началось с того, что я по нелепой ошибке попал на Факультет Информационных Технологий вместо Факультета Прикладной Математики. На первом курсе меня очень заинтересовал первый изучаемый нами язык программирования “Паскаль”. Я с большим удовольствием создавал небольшие консольные программки. Тогда же, познакомился с HTML и прекрасными тегами, типа font и frameset...

На третьем курсе института я и двое однокурсников решили, что пора бы что-то заработать. Начали активно искать клиентов в Одессе: мы просто ходили по городу, заходили во всевозможные магазины, кафе, организации и пр., предлагая сделать сайт. Со временем у нас появились небольшие заказы… Сомневаюсь, что дальнейшее повествование будет интересно, поэтому скажу кратко: я успел поработать проект-менеджером (самая скучная работа в моей жизни), преподавателем веб-разработки (в основном, JavaScript) и сейчас успешно тружусь в качестве фрилансера на бирже Upwork.

Выбор пал на JavaScript из-за простоты запуска того, что накодил. Плюс, меня привлекает больше то, что можно увидеть и кликнуть (кнопки, поля ввода и др.), чем, скажем, серверное программирование, которое нельзя “пощупать”.

Игорь Антонов: «Матрешка» ваш первый проект для разработчиков или до него уже был опыт создания универсальных инструментов? Это личный проект или создание начиналось еще при работе в компании?

Андрей Губанов: Проект не первый. До этого был WYSIWYG редактор и несколько небольших функций и плагинов к jQuery. В компаниях никогда не работал (кроме двух позиций, описанных выше), поэтому проект “личный”.

Игорь Антонов: Давайте поговорим об истории создания матрешки. С чего собственно все началось? Почему решили бросить силы на разработку собственного фреймворка, а не выбор готового решения?

Андрей Губанов: Начиналось всё с того, что я написал, как и большинство разработчиков, свою функцию Class, которая добавляла синтаксический сахар в прототипное наследование. Это позволило очень лаконично писать приложения, разделяя их на небольшие кусочки (о модулях я тогда не знал, а скрипты подключались строго по очереди). Эта функция копировалась из проекта в проект.

Затем, я получил “тот самый” проект, проект - мечта любого разработчика 4 года назад. Веб-приложение требовало поддержки исключительно последнего Хрома. Вы понимаете что это значит? Не знаю, понимаете ли, но это был рай веб-разработчика. Не нужно было поддерживать кроссбраузерность, можно было юзать самые новые возможности DOM и ECMSScript 5! Если помните, Хром был первым браузером с автоматическим обновлением.

Сам проект - гигантская форма на 20 экранов: ввод и вывод в виде таблиц и графиков статистики и прогнозирования нефте-газо добычи, включая все возможные страны и большинство крупных компаний. Каждый элемент формы должен был включать путь к свойству из многоуровневого объекта и, при изменении элемента (например, при вводе с клавиатуры в элементе input), менять данные и наоборот: при изменении свойства из кода или консоли, менять состояние элемента. Теперь-то я знаю, что это называется двустороннее связывание данных или two-way data binding.

Из популярных фреймворков на то время был выбор среди Backbone и Knockout. Первый никуда не годился для этой задачи, второй, как оказалось несколько позже, тоже. Поэтому, пришлось написать собственный фреймворк под этот конкретный проект. Вот тогда-то я и познакомился с акцессорами (accessors) и мог творить ту магию, которая была недоступна другим разработчикам.

Позже, после того, как я успел набить десяток шишек, возникла идея обобщить задачу, создав универсальную функцию: мы можем отловить изменение значения свойства, мы можем отловить действие пользователя, так почему мы не можем объединить эти два простых действия и держать данные и состояние ноды синхронизированными? Я размышлял над этой идеей около месяца. Так был заложен первый камешек во фреймворк в виде функции bindElement (ныне bindNode).

Небольшое отступление: помните, когда Object.defineProperty стал кроссбраузерным? После непродолжительного восторга все задались вопросом “И что теперь”? Матрешка - это, возможно, единственный инструмент, который выжал из акцессоров всё, что только возможно.

Игорь Антонов: Какие проблемы наиболее эффективно решает матрешка? Понятно, что возможности матрешки могут пригодиться в любом проекте, но наверняка есть тип проектов, в которых лучше всего можно прочувствовать мощь фреймворка.

Андрей Губанов: Матрешка решает проблему больших приложений и потенциально бесконечной расширяемости. Выбирая любой современный инструмент, вы наверняка будете следовать лучшим практикам по структуризации приложения. Обычно, следуя архитектурному паттерну MVC приложение разбивают на “вьюхи”, модели и коллекции (с некоторыми оговорками по каждому фреймворку) и кладутся в разные папки.

Если нужно внести некоторые изменения в кусочек приложения, вам нужно менять сразу несколько файлов (два-три). Это можно пережить, но когда логических кусочков становится слишком много, начинается самое интересное: кажущаяся ранее логичность структуры превращается в головную боль разработчика. В папке с контроллерами все контроллеры, в папке с “моделями” все модели, каждый файл из первой папки имеет “напарника” из другой. Сложность внесения изменений растет с каждым новым модулем, разработчик тратит время, компания или клиент теряет деньги…

Это хорошо, когда вы всю логику кладете в .js файлы, но сегодня модно использовать архитектурный паттерн MVVM, перекочевавший из мира .Net, заставляющий описывать логику в HTML разметке. Использование этого паттерна добавит вам еще немного боли при создании больших приложений.

С Матрешкой эти проблемы решены просто: “вьюха” - это чистый HTML (как и в Backbone, тут ничего нового), без всяких кастомных атрибутов и синтаксических ухищрений, модель - это и есть код, который вы пишете, а о контроллере вы вообще не думаете, так как 99% задач решает метод bindNode, связывающий “вьюху” с моделью. Периодически нужно описать нечто более сложное, чем двустороннее связывание: в этом случае, создается еще один метод.

Проблема структурирования папок и файлов проекта решена элементарно. Вместо того, чтобы разбивать одну логическую частицу приложения на несколько частей и класть в разные папки, вы описывает модуль в одном .js файле, назвав его понятным именем, например “форма регистрации” (обычно я добавляю суффикс class для каждого модуля: registration-form.class.js). Если этого недостаточно, можно создать папку с таким же понятным именем и наполнить двумя - тремя файлами, отвечающими за одну часть приложения. Например, форму регистрации в соцсети можно разбить на, собственно, форму (имя, адрес почты и пр.), загрузку фото и поиск друзей, и сложить это в папку registration-form.

Игорь Антонов: Двухсторонний биндинг реализован сегодня во многих фреймворках. Матрешка тоже обладает этим функционалом. Вот отсюда возникает вопрос, на основе чего сделан биндинг в матрешке и нет ли проблем с производительностью?

Андрей Губанов: Байндинг реализован на базе акцессоров. Подход позволяет установить свойство так, как это обычно делается без использования фреймворков (object.x = 42). Относительно производительности: вы задали очень хороший вопрос. Как раз на днях сравнивал скорость сеттера и Object.observe (без фреймворков). Оказалось, что, во-первых, сеттер работает на 30% быстрее, во-вторых регистрирует изменения свойства моментально, в отличие от обзервера, который коллекционирует изменения и регистрирует все сразу после небольшой задержки. Теперь представьте, насколько первое быстрее dirty-checking или полифилов Object.observe.

Матрешка - потенциально самый быстрый фреймворк, она уже обгоняет в тестах с сотней и более элементов коллекций Angular, Knockout и даже React и расход в скорости растет по экспоненте. “Потенциально” потому что на 10 элементах Матрешка немного отстает от Knockout и React, а в коде есть несколько известных “замедлителей”, например функций, расширяющих один объект другим, вместо обычного цикла. Такие незначительные “косяки” постепенно исправляются.

<script src="matreshka.min.js"></script>
<input type="text" class="my-input">
<script>
var app = new Matreshka;
app.bindNode( 'x', '.my-input' );
app.x = 'Двустороннее связывание данных в JS? Серьезно?';
</script>

Игорь Антонов: Не могу не спросить про название фреймворка. Почему именно «матрешка»? Кстати, у вас вроде еще есть один проект – «балалайка». Расскажите, немного про него.

Андрей Губанов: Пока не было принято решение выкладывать проект на Github, у фреймворка (скорее, у набора утилит) было скудное название TopClass (самый высокий класс в иерархии классов), от которого наследовались все остальные классы в проектах.

Когда я решил выложить проект в открытый доступ, встал вопрос о названии. Было очень много разных идей, слово “матрёшка” показалось наиболее звонким и запоминающимся (как показала практика, так и есть).

Почему “матрёшка”? У меня есть нечто, что я бы хотел назвать чувством юмора, и “матрёшка” была той “клюквой”, которая разбавила бы несколько пафосные или слишком “технические” названия других доступных тогда инструментов.

Другим вопросом, над которым пришлось помучиться (как ни странно) - это выбор способа написания слова “матрёшка” на английском. Хотелось избежать путаницы между двумя равносильными “матрёшками”: matryoshka и matrioshka. Но было решено просто-напросто отказаться от буквы “ё”. Так что, фреймворк правильно называть “Матрешка”, а не “Матрёшка” (обратите внимание на все мои статьи и документацию).

Балалайка - это просто ассоциация к “матрёшке”, такая же шутливая и вроде-как запоминающаяся.

Игорь Антонов: Проблема поддержки старых браузеров сегодня менее актуальна, чем пять лет назад, но все же интересно, на каких бродилках матрешка будет чувствовать себя комфортно.

Андрей Губанов: Сегодня Матрешка работает везде, начиная с IE8. Постепенно будет осуществляться уход от этого браузера, так как он несовместим с новыми фичами, которые появятся в версии 1.1. Старые проекты по-прежнему будут работать в этом “старичке”, но в документации будет указана поддержка IE9+.

Игорь Антонов: Русскоговорящие разработчики заинтересовались вашим проектом, а как обстоят дела с продвижением на западе? Есть прецеденты применение матрешки среди англоговорящих разработчиков?

Андрей Губанов: Это очень хороший вопрос. Следующей волной популяризации как раз будет продвижение в англоговорящем интернете. Есть много интересных идей в этом направлении, которые по плану будут реализованы до 2016 года. Подробностей, к сожалению, озвучить не могу.

Игорь Антонов: Пока «Матрешка» малоизвестный проект, нет ли проблем с заказчиками при обсуждении новых проектов? Более-менее продвинутые заказчики обычно желают получить проект с использованием популярного стека технологий. Вопрос последующего сопровождения всегда актуален.

Андрей Губанов: Нет, таких проблем нет. Один из заказчиков даже выставил требование использовать Матрешку в новом проекте.

Игорь Антонов: Если не ошибаюсь, то «Матрешке» как минимум 2 года. Как это время отразилось на сообществе вокруг фреймворка? Появились контрибьютеры? Сторонние разработчики присылают пул-реквесты?

Андрей Губанов: Основная помощь идет от людей, желающих улучшить документацию. К счастью (или к сожалению?) очень часто приходят уведомления об опечатках на странице документации. Контрибьюторы есть, но мне бы хотелось, чтобы люди присылали пулл-риквесты чаще и с крупными изменениями, а не с небольшими исправлениями.

Игорь Антонов: Что планируется реализовать в матрешке в ближайшее время? Приоткройте немного занавес, поделитесь планами на будущее.

Андрей Губанов: Все анонсы я делаю в чате Матрешки, стараясь сделать фреймворк еще более открытым.

Следующая версия, кроме минорных улучшений и рефакторинга получит улучшение производительности и возможность работать с нативными объектами (да, DOM узел можно будет привязывать к свойству обычного объекта). Сейчас, идет работа над еще более сумасшедшими идеями: возможность ловить любые изменения в дереве объекта и байндить любое свойство в дереве объекта. Это всё уже работает в одном из проектов, но из-за колоссального количества юз-кейсов требует больше тестов (автоматических и “боевых”).

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

Игорь Антонов: Хорошо, теперь отвлечемся от матрешки и поговорим на общие темы. Не против? Начнем с самого холиварного вопроса. Какую IDE (или редактор) предпочитаете и почему? Аналогичный вопрос про системное окружение. В какой ОС предпочитаете работать.

Андрей Губанов: Использую KUbuntu 14 (с версией 15 мой ноутбук не подружился) и недавно слез со встроенного редактора Kate, обкатываю новомодный Atom.

Мне нужно просто писать код, поэтому не могу развернуто ответить на вопрос “почему”. Наверно, потому что нравится. Я не совсем понимаю почему люд холиварят на такие темы, как выбор ОС или редактора.

Игорь Антонов: Какими еще технологиями/языками программирования интересуетесь помимо JavaScript?

Андрей Губанов: Я бы хотел поработать с функциональными или логическими языками (например, Prolog) программирования, но рынок мне этого не позволяет, очень мало заказов (по логическому программированию вообще не встречал).

Еще интересует потрясающий язык Python, но, к сожалению, за него платят меньше на 30-40%, чем за клиентский JavaScript.

Игорь Антонов: С какого языка программирования вы бы рекомендовали изучать программирование? Объясните свой выбор.

Андрей Губанов: Мой личный путь был настолько заковыристым, что я затрудняюсь ответить. Наверно, все-таки C++. Он считается очень сложным, но, при этом, он включает в себя почти всё, с чем встретится программист, изучая один из большинства других языков.

Главное не начинать с Python. Другие языки будут выглядеть чересчур громоздкими и заумными. Люблю Python :)

Игорь Антонов: При изучении нового языка программирования/технологии вы начинаете с теории или практике?

Андрей Губанов: Скорее с практики. Если запустился “Hello World”, то можно не боясь продолжать разбираться дальше (если я правильно понял вопрос).

Игорь Антонов: Какие ресурсы для разработчиков вы бы могли порекомендовать для ежедневного просмотра. Какие сайты посещаете каждый день?

Андрей Губанов: Хабр и ценные статьи, разбросанные по просторам интернета. Советую мониторить дайджесты для веб-разработчиков, которые выходят регулярно в начале недели на Хабре.

Игорь Антонов: Однозначно уверен, что начинающих разработчиков интересует самый правильный путь к достижению успеха в выбранной области. Как на ваш взгляд быстрей стать классным front-end разработчиком. Что почитать, какие курсы прослушать. Поделитесь кейсами.

Андрей Губанов: Почитать и послушать можно, но, в первую очередь, нужно писать как можно больше кода на каждом этапе своего развития в качестве разработчика. Очень желательно находить живые заказы, несмотря, что на первых порах это нереально трудно и неприбыльно. На каком-то этапе может показаться, что ничего хорошего из этого не выйдет и многие отказываются от перспективы стать программистом в пользу чего-то более простого. Но сдаваться нельзя.

Игорь Антонов: Напоследок, чтобы вы хотели пожелать нашим читателям.

Андрей Губанов: Есть три профессии, позволяющие хорошо заработать, не имея талантов, связей или богатых родственников: моряк, проститутка и программист. Сделайте правильный выбор.

Начинаем изучать Matreshka.js

Если вы заинтересовались фреймворком Matreshka.js, то самое время пробежаться по следующим ссылкам:

• Matreshka.io - официальный сайт проекта Matreshka.js;
• Блог автора на Хабре - блог автора на популярном ресурсе "Хабрахабр". На блоге публикуются анонсы новых версий, а также обучающие статьи.