В WordPress рассматривают агностичный подход к выбору JS-фреймворка для блоков Gutenberg

Обсуждение фреймворка JS для WordPress продолжается на канале Slack #core-js наряду с запланированными встречами разработчиков на следующей неделе. Одной из последних тем дискуссий является возможность рендеринга блоков Gutenberg без привязки к какому-то одному конкретному фреймворку JS (агностичный подход). Это позволит разработчикам расширить новый редактор, используя любую предпочтительную JS-библиотеку. В таком случае блоки Gutenberg, в народе именуемые Gutenblocks, могут быть созданы на базе Vue, React, Preact, Angular или любых других решений.

Сторонники этой идеи считают, что применение более гибкого подхода делает выбор базового JS фреймворка для WP менее критичным. Отвечая на вопросы на канале #core-js, Гэри Пендергаст объяснил, как можно построить Gutenberg для поддержания такого разделения.

«Я не шучу, когда говорю, что это решение не играет роли, причем даже для тех, кто вносит вклад в WordPress», — отметил Гэри. – «В #2463 библиотека обрабатывается целиком как вспомогательная, по аналогии с lodash, к примеру. Она выполняет ряд задач, и мы можем относительно легко ее вытащить и заменить на что-то другое, не нарушив остальную кодовую базу. Пользователи, вносящие свой вклад в Gutenberg, улучшают стиль кодирования Gutenberg, а не стиль какой-либо библиотеки, которую мы импортируем».

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

«Никаких дорожных карт, графиков, ничего подобного нет», — отметил Гэри. – «Как сказал Мэтт, это действительно всего лишь техническое решение – важное решение для более широкого сообщества, которое решило отказаться от React. К сожалению, это решение было переоценено и в большей степени сводилось к вопросам, таким как “с помощью какой JS библиотеки я буду создавать свои плагины?” и “методы какой JS библиотеки будут напоминать блоки Gutenberg?”. Ни то, ни другое неверно. Твиты и сообщения, которые рассматривают этот процесс как какую-то гонку, ничем не помогают нам».

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

Тем не менее, другие участники сообщества не согласны со сведением JS-библиотеки, выбранной для ядра, к простому техническому решению или вспомогательной библиотеке.

«Большинство разработчиков понимают, что их плагины никак не привязаны к фреймворку, выбранному для ядра/Gutenberg», — отметил Кевин Хоффман. – «Однако это не умаляет значимости решения. Если мы хотим охватить максимум разработчиков, нам потребуется решение, которое будет понятно и полезно для большинства. Если разработчики раньше создавали плагины с помощью одного фреймворка, а затем им пришлось обучиться другому, чтобы внести свой вклад в ядро, то в таком случае мы просто ограничим число потенциальных участников».

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

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

Каковы последствия гибкого, фреймворк-агностичного подхода к формированию блоков Gutenberg?

Джейсон Бал задался вопросом, что будет, если кто-либо смешает в одном приложении React, Preact, Vue и Angular. Станет ли это «страшным сном для производительности»? Он представил примерный сценарий, в котором Gravity Forms создали блоки Gutenberg на базе Vue, Yoast создали блоки на базе React, WooCommerce – на базе Preact, а другие плагины использовали Ember.

«Звучит неплохо – ведь мы поддержим гибкость и позволим пользователям использовать любые фреймворки и библиотеки. Но что будет в итоге? Не приведет ли это к значительному разделению лучших практик и к потенциальным проблемам с производительностью?»  — задался вопросом Джейсон. – «Мы увидим руководства о том, как создавать блоки Gutenberg в Vue, React, Preact, Ember, Vanilla JS и т.д. Это, конечно, здорово, но в итоге это все будет сильно запутывать, что поддержит разбиение людей в сообществе и помешает принять единые лучшие практики. Определенная гибкость хороша, но только до какого-то момента, когда лучше выбрать конкретное решение».

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

«Люди в конечном счете примут любое решение, используемое в ядре, поскольку оно связано с созданием уровня абстракции, чтобы разработчики плагинов/тем могли использовать все, что им захочется», — отметил Карл. – «Это означает, что сложность, которую будет иметь фреймворк, окажет прямое воздействие на входной порог для разработчиков тем и плагинов. Этот входной порог исторически был достаточно низким до недавнего времени, и это являлось причиной роста WordPress как автономной CMS. Резкое повышение входного порога не обязательно является плохим решением. К примеру, Gravity Forms будет использовать Preact, Vue, что-то еще, не важно, поскольку у нас есть сотрудники и навыки, чтобы сделать это, и мы сделаем это, как только разработчики ядра примут свое решение».

Возможности WordPress для улучшения сети

WordPress в данный момент охватывает примерно 28% всех сайтов сети, согласно W3 Techs, и, какой бы фреймворк не был выбран, это окажет существенное влияние на то, какую библиотеку многие разработчики начнут изучать, чтобы расширить ПО и продвинуться по карьере.

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

«Я очень рад возможности расширить веб-разработку в плане представления JavaScript UI, аналогично тому, как WordPress был движущей силой веб-стандартов в течение последнего десятилетия», — отметил Вентура. – «Здесь мы несем ответственность за проект, поскольку люди будут продолжать изучение веб-разработки через WP. Многие пользователи познакомились с PHP через WordPress, изначально просто взаимодействуя с WP функциями и API, и в конечном счете погрузившись в язык сильнее. Я вижу, что наше ядро остается близко к языку JS, потому он остается наиболее значимым инструментом для изучения, охватывая все фреймворки и библиотеки».

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

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

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

Блог про WordPress
Добавить комментарий

Получать новые комментарии по электронной почте.