Дискуссия по выбору WordPress JS-фреймворка продолжается с привлечением лидеров open source сообщества

Дата публикации:Сентябрь 28, 2017

На днях на канале #core-js в Slack прошла продуктивная встреча под руководством Эндрю Дати. Дискуссия была сфокусирована в меньшей степени на сравнении конкретных фреймворков и в большей степени на роли фреймворка, которую он будет играть в построении JS-интерфейсов для WordPress. К участникам также присоединились основные разработчики и руководители сообществ React и Vue, инженеры Chrome, а также другие заинтересованные стороны за пределами WordPress сообщества.

«Это обсуждение будет в основном сфокусировано на определении требований для создания базовых особенностей ядра, а также паттернов для сокращения привязки к определенному фреймворку», — отметил Дати. – «В идеале это будет нечто большее, чем просто обсуждение достоинств конкретных фреймворков в вакууме, и нашу встречу следует рассматривать как возможность сотрудничества между разными проектами для задания вектора развития WordPress, который обеспечит гибкость и устойчивость платформы в будущем».

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

«Я не согласен с идеей о том, что любая технология, используемая (в частности Gutenberg) для реализации некоторых аспектов приложения, станет де-факто стандартом для разработки плагинов», — отметил Матиас Вентура, разработчик Gutenberg. – «Фактически фреймворк будет тем, что будет использовать WordPress и API».

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

«Покажу вам на своем примере, как решение WP по поводу фреймворка повлияет на разработчиков. Я — девелопер из Бостонского университета. Мы планируем вести разработку на том фреймворке, который выберет WordPress, даже если Gutenberg будет иметь полностью агностичное API», — отметил Адам Пеняжек. – «Мы поддерживаем магазин WP и вносим значительные изменения поверх WP, которые требуют детального погружения в ядро. Мне больше нравится Vue, чем React, однако, если WP примет React, мы сфокусируемся на изучении React для тех случаев, когда нам нужно будет что-то отладить за пределами API. Это не значит, что мы не будем использовать Vue, но React станет нашим основным направлением».

Ответ Пеняжека напомнил комментарий от Карла Хэнкока из Gravity Forms, в котором тот отметил, что его команда готова принять любую библиотеку, выбранную WordPress.

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

«Поскольку сам Gutenberg станет платформой для разработки, лучшим уровнем разделения будет применение фреймворка для разработки ядра, но при этом он не должен рассматриваться как API для создания билдеров блоков», — заметил инженер AMP Пол Бакаус. – «Это позволит менять базовый фундамент, когда это необходимо».

Разработчик Gutenberg Риад Бенгуэлла подытожил мнения, обсуждаемые командой:

Я считаю, что выводы следующие:

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

Бенгуэлла также отметил, что одной из целей Gutenberg является «задание базиса для расширения интерфейса WordPress в будущем». Как только Gutenberg увидит свет, команда, скорее всего, сформирует свое видение других компонентов wp-admin и реализует их таким же образом.

«Если все части интерфейса WordPress будут расширяемы через стандартный интерфейс, это, как мне кажется, разделит вопросы ‘какой фреймворк использовать для ядра’ и ‘какой фреймворк использовать для разработки расширений’», — отметил разработчик Vue.js Эван Ю.

Дэн Абрамов, сторонник React, поделился своими мыслями по поводу фреймворк-агностичного подхода для WP и Gutenberg:

«Я не очень хорошо знаю WordPress, поэтому мне трудно сказать, подходит ли React для использования с WP или нет», — отметил Абрамов. – «Обычно мы используем React для создания высокоинтерактивных интерфейсов, масштабируемых вместе с размером приложения. Я также рад ответить на технические вопросы. Но я думаю, что в целом у людей есть различные мнения, и я не считаю, что заставить всех использовать React – это правильный путь».

«Я чувствую то же самое», — отметил Эван. – «Принуждение использовать один фреймворк для всех, вне зависимости от того, какой именно – это не самая лучшая идея. Это неизбежно отчуждает группу разработчиков, которые не были связаны с данным фреймворком, и несет в себе более высокие риски для долгосрочной стабильности».

Абрамов также отметил, что люди и так уже «сильно озлоблены и расколоты» из-за выбора фреймворка.

«Я считаю важным (и технически осуществимым) отделить ‘какой фреймворк использовать для ядра’ от ‘какой фреймворк использовать для расширений’», — отметил Эван Ю.

Тема поддержки взаимодействия веб-компонентов для блоков Gutenberg также обсуждалась на встрече.

«Хотя на данный момент они менее эффективны, чем большинство реальных фреймворков, они, скорее всего, станут стандартом W3C, если они продолжат поддерживаться и развиваться», — заметил Феликс Арнтц.

Представитель Polymer.js Джастин Фагнани сказал, что он не согласен с тем, что они «менее эффективны», и отметил, что веб-компоненты уже являются стандартом W3C.

«Я думаю, что WP также имеет уникальные возможности для родной поддержки веб-компонентов повсюду», — рассказал разработчик EventEspresso Даррен Этье. – «Практически все фреймворки могут работать со спецификацией веб-компонентов. Это просто вопрос грамотной реализации».

Некоторые участники сослались на сайт custom-elements-everywhere.com, где демонстрируется прогресс популярных JS фреймворков в плане поддержки Custom Elements для интероперабельности. Матиас Вентура опросил разработчиков React и Vue, чтобы узнать, как веб-компоненты (и их будущее) вписаны в тот и другой фреймворк в данный момент.

«В React у нас есть поддержка некоторых веб-компонентов, но они не имеют высокого приоритета, поскольку в прошлом случаи использования были достаточно ограниченными и малозначимыми. Тем не менее, мы поддерживаем их, и я рада расширить поддержку – либо сейчас, либо в ближайшем будущем», — отметила Софи Альперт.

«Такие фреймворки, как React/Vue, обеспечивают то, что на самом деле не представлено в веб-компонентах: эффективные и декларативные обновления DOM, реагирующие на изменения состояний», — отметил Эван Ю. – «Именно по этой причине Polymer основан на WC (web components). Я всегда признавал ценность WC как интероперабельного интерфейса».

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

Источник: wptavern.com

Поделиться

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

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