Вы здесь

Выбор клиентского фрейм-ворка для Друпала

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

Я уверен, что принятие клиентского фрейм-ворка через прогрессивную отвязку даст нам лучшее из обоих миров. Конечно, это не означает, что я против полной отвязки через другие фрейм-ворки; фактически, я думаю, что нам нужно удвоить наши усилия по созданию первоклассного API в Друпале. Но прогрессивная отвязка означает то, что мы сможем работать с новыми возможностями для пользователей, без отказа от большей части той работы, которую уже сделали.

Учитывая это, я озадачил небольшую группу специалистов из Друпала и разных сообществ JavaScript созданием списка критериев и матрицы сравнения, которая поможет нам выбрать самый подходящий клиентский фрейм-ворк для прогрессивной отвязки Друпала.

Матрица сравнения JavaScript-фрейм-ворков

После сотен часов работы, мы сделали документ критериев и матрицу сравнения (.pdf-файл прикреплён к документу; открыть изображение в отдельной вкладке):

Выбор клиентского фрейм-ворка для Друпала

Отдельная благодарность следующим экспертам, которые сделали обзор и таблицу: Мишко Хеверы (создатель Angular; Google) и Игорю Минару (техническому лидеру Angular; Google); Эду Фалкнеру (мейнтейнер ядра Ember); Амитаи Бурштейну (вкладчик Друпала и Elm; Gizra); Себастьяну Сиемссену (вкладчик Друпала, разработчик Elm и React; Zensations); Джону Альбину Вилкинсу (лидер мобильной инициативы в Друпале 8), Алексу Бронштейну (мейнтейнер ядра Друпала; Acquia), Виму Лиерсу (мейнтейнер ядра Друпала; Acquia) и Престону Со (вкладчик Друпала, Acquia).

Это хорошая отправная точка, закладывающая основу для формального процесса принятия в ядро Друпала, и настало время открыть наше сравнение для обзора участниками сообществ Друпала и JavaScript. Нам нужно также более точно оценить возможности этих фрейм-ворков в фактической разработке.

Во-первых, правильные ли мы выбрали критерии вне зависимости от самих фрейм-ворков? Возможно это самое важное на этом этапе. В то время, как многие организации выбирают клиентские фрейм-ворки для вариантов с полным отвязыванием, нам нужно учесть работу Друпала, чтобы динамические и более традиционные модули сосуществовали при прогрессивной отвязке. Что с шаблонами, рендерингом и кешированием на стороне клиента нужно включить в критерии? Есть что-то отсутствующее или ненужное?

Во-вторых, мы выбрали нужные для фокусировки фрейм-ворки? Есть ли другие фрейм-ворки, библиотеки или даже компилируемые в JavaScript проекты (такие как Elm), которые нужно включить в матрицу? На мой взгляд, Друпалу лучше взять фрейм-ворк с уже большим сообществом и экосистемой, которая позволила бы нам быстрее преодолеть разрыв и устранить любые трения во время принятия. Чтобы улучшить видимость плюсов и минусов, мы также включили в матрицу Backbone, Angular и Knockout, все трое немного старше большинства клиентских фрейм-ворков. Другие проекты, которые мы не рассматривали в нашем списке, отличаются низким уровнем приспособления и маленькими сообществами, это Mithril, Riot и Vue. Другие амбициозные проекты, такие как языки Elm и ClojureScript, также являются кандидатами, но их приспособление будет означать большую работу для поддержки типичных возможностей клиентских фрейм-ворков, а также уход в подход, при котором JavaScript компилируется из другого языка.

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

Я делюсь исходной матрицей сравнения в своём блоге для максимального охвата аудитории; я хочу, чтобы сообщество Друпала и сообщества фрейм-ворков, а также более широкое сообщество фронт-энд разработчиков, отметили это. После трёх записей в моём блоге (предыдущие — Будущее отвязанного Друпала, Встраивать ли в Друпал клиенсткий фрейм-ворк?), пришло время перенести технический разговор на drupal.org. Теперь в очереди запросов касательно ядра есть запрос связанный с этой матрицей на drupal.org.

Предварительные выводы

В данный момент самыми перспективными кандидатами являются Angular 2, Ember и React, учитывая их техническую надёжность, относительную пригодность для прогрессивной отвязки Друпала, сильную поддержку сообществ и широкую распространённость. Учитывая, что Backbone уже находится в ядре и несколько модулей уже используют его, мы включили и его тоже.

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

Быстрый взгляд на критерии и наши нужны позволяет сказать что наиболее привлекательным кандидатом является Ember, поскольку именно он кажется имеет небольшое техническое преимущество в целом. Ember 2.0 имеет полностью новый движок рендеринга Glimmer и он использует рендеринг на стороне сервера через FastBoot. С другой стороны, Ember довольно громоздкий и упрямый (принуждение к использованию паттерной структуры кода). Более фундаментальным отличием является то, что в отличие от Angular и React, которые имеют корпоративное управление и финансирование, Ember это проект создающийся по инициативе сообщества, подобно Друпалу.

Хотя React лёгкий, он нуждается в интеграции с разными другими библиотеками экосистемы React для работы как полноценная реализация, это даёт ему крутую кривую обучения. Так как это молодой проект, лучшие практики быстро меняются и делают его менее привлекательным. Самая привлекательная его возможность это Virtual DOM и его идеи фильтруются в другие проекты. Но самое важное это то, что React имеет в лицензии потенциально неприемлемую оговорку, которая говорит о том, что организация больше не может использовать React после того, как она подала в суд на Facebook за любое нарушение патентных прав. Это уже привело к откату от него вкладчиков WordPress Calypso и самого React.

Angular 2 полностью переписан в сравнении с Angular 1, чтобы решить вопросы связанные с быстродействием. Новая версия содержит новый движок шаблонов, который включает инструкции знакомые разработчикам Angular 1 и шаблоны на основе компонентов. Но Angular 2 распространяется по лицензии Apache 2.0, которая несовместима с лицензией GPL 2, по которой распространяется Друпал. Хотя PHP-код Друпла и JavaScript-код выполняются в изолированных процессах, похоже что проекты с лицензией Apache 2.0 не могут распространяться совместно с проектами с лицензией GPL 2.

Несмотря на технический недостаток Ember, юридические проблемы с React и Angular заставляют меня думать, что Ember может быть нашим лучшим выбором. Но я не юрист и не специалист в JavaScript, поэтому я не могу принять решение в одиночку; я смотрю много отзывов, особенно от специалистов в JavaScript, чтобы определить лучший вариант для Друпала.

Заключение

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

Отдельная благодарность Престону Со за вклад в эту статью.

Рубрика: