Обсуждение выбора WordPress Core JavaScript Framework продолжается при участии лидеров сообщества открытого исходного кода

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

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

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

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

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

«Чтобы дать некоторое представление о том, как решение WP о фреймворке повлияет на последующих разработчиков, я разработчик из Бостонского университета, и наш план состоит в том, чтобы сосредоточиться на любом фреймворке, который выберет WP, даже если у Gutenberg есть полностью независимый API», — сказал Адам Пенязек. . «В первую очередь мы являемся магазином WP (~ 1000 установок WP обеспечивают большую часть нашего общедоступного веб-присутствия) и в конечном итоге создают огромные настройки поверх WP, которые часто требуют погружения в ядро, чтобы увидеть, что на самом деле происходит в фоновом режиме. . Лично мне Vue нравится больше, чем React, но если WP решит использовать React, BU сосредоточится на накоплении опыта в React, когда нам понадобится просмотр/отладка за пределами API. Это не означает, что мы не будем также использовать Vue, но это не будет нашей основной задачей».

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

«Люди в конечном итоге примут все, что использует ядро, по большей части, несмотря на радугу и бабочек, которые, как утверждают некоторые, связаны с созданием слоя абстракции, чтобы разработчики плагинов/тем могли использовать все, что они хотят», — сказал Хэнкок в #core- js ранее на этой неделе.

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

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

Инженер Gutenberg Риад Бенгуэлла резюмировал подход, обсуждаемый командой:

Я думаю, что мы пытаемся сообщить что-то вроде:

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

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

«Если все части пользовательского интерфейса WP могут быть расширены через стандартный интерфейс, будь то простой API «данные вниз, события вверх» или ожидание WC, я думаю, что это четко разделит проблемы «какой фреймворк использовать для ядра». «Какую структуру использовать для разработки расширений», — сказал создатель Vue.js Эван Ю.

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

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

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

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

Когда я читаю обсуждения (например, о WordPress), у меня возникает ощущение, что люди воспринимают каждую команду как враждебную по отношению к другим. Это неверно.

— Дэн (@dan_abramov) 26 сентября 2017 г.

Думайте об этом, как об уходе за садом. Вы можете потусоваться у нас. Другие сады тоже хороши

— Дэн (@dan_abramov) 26 сентября 2017 г.

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

«Да, я думаю, что здесь есть цель не высказывать мнения относительно того, что мы предоставляем авторам плагинов, при условии, что API/интерфейсы, которые мы предоставляем, достаточно гибки (и просты) для создания пользовательских интерфейсов и взаимодействий, которые они должны реализовать, — сказал Эндрю Дати.

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

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

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

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

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

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

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

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