Сообщество Drupal рассматривает несвязанную архитектуру

Ранее на этой неделе Дрис Байтарт, создатель и руководитель проекта Drupal, открыл в своем блоге дискуссию о будущем архитектуры Drupal в сообщении под названием « Должны ли мы отделить Drupal от клиентской среды?»

Байтарт утверждает, что пользователи ожидают от веб-сайтов взаимодействия с приложениями, учитывая их опыт взаимодействия с лентой новостей Facebook, почтовым ящиком Gmail и прямой трансляцией Twitter.

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

Дискуссия о том, чтобы отделить Drupal от фреймворка на стороне клиента, возникла в интересное время, когда в своем выступлении Matt Mullenweg State of the Word JavaScript провозгласил будущее WordPress и Интернета. Его заключительные замечания призвали разработчиков изучать JavaScript и приступить к созданию приложений на основе WordPress в будущем.

Комментатор поста Buytaert связывает это с выпуском Automattic Calypso:

Такое ощущение, что этот пост, по крайней мере частично, является реакцией на объявление WordPress о Calypso. Надеюсь, мы сможем сосредоточиться на принятии решений, которые будут правильными для будущего Drupal, а не поспешно реагировать на то, что делает другая CMS, особенно когда вы снова и снова говорите о том, что WordPress не является настоящим конкурентом Drupal.

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

«Что касается объявления WordPress о Calypso — я фактически начал писать этот пост в блоге до того, как было объявлено о Calypso», — сказал он. «Я не верю, что Калипсо повлияла на мою позицию».

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

Проблема стандартизации фреймворка

Во многих отношениях обсуждение поста Buytaert имеет отношение к тому, куда движется WordPress, особенно к рассмотрению вопроса о стандартизации конкретного фреймворка.

Buytaert выступает за постепенное разъединение взаимодействия администратора и конечного пользователя Drupal, а также за создание полностью разъединенного опыта поверх платформы. Он предлагает, чтобы лучший способ сделать это — «формально стандартизировать полнофункциональную среду MV* (например, Angular, Ember, Backbone и Knockout) или библиотеку представлений на основе компонентов (например, React, Vue и Riot). ”

Поскольку он не является фронтенд-разработчиком, Байтарт запрашивает мнение сообщества Drupal о том, какой фреймворк лучше всего подходит для прогрессивного разделения. Он также признает причины, по которым стандартизация конкретного фреймворка может оказаться нежелательной в долгосрочной перспективе:

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

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

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

Если ядро ​​WordPress в конечном итоге примет технологию, лежащую в основе Calypso (или аналогичную Calypso альтернативу), чтобы обеспечить лучший опыт публикации, будет ли ядро ​​стандартизировать фреймворк/библиотеку или оно продолжит позволять разработчикам расширений использовать любой фреймворк?

Один комментатор указывает на потенциальные проблемы с Drupal при выборе фреймворка, что некоторые могут воспринять как официальное одобрение:

Уже есть много корпоративных проектов, использующих несвязанный подход Drupal, и, естественно, они используют множество разных фреймворков, но я вижу, что больше всего используется React. На самом деле в проекте, над которым я сейчас работаю, организация полностью использует React. Например, если Drupal остановился на Angular, как это повлияет на организации, которые вкладывают большие средства в другие фреймворки? Может быть, я не до конца понимаю, как это может работать, но выбор единственной структуры может привести к разногласиям и разрушениям — в плохом смысле, а не в смысле SV.

Я думаю, что упрощение несвязанных архитектур — это здорово, и это должно быть тем, что делает Drupal, но он должен делать это таким образом, который не зависит от используемой среды FE.

Buytaert определяет несколько альтернатив поставке фреймворка на стороне клиента с ядром Drupal, включая рекомендацию фреймворка, но не поставку с ним, или включение его в ядро, но упрощение замены разработчиком на другой фреймворк по выбору.

Его пост и последующие комментарии — это начало оживленной, вдумчивой дискуссии, которая поможет сформировать будущее разработки Drupal. Сегодня Buytaert требует предложений, которые могли бы наметить прототип рабочей версии прогрессивной развязки.

Было бы интересно прочитать предложение о том, как создать прототип рабочей версии прогрессивной развязки: https://t.co/tJxT66cKoy #drupal

— Дрис Байтарт (@Dries) 11 декабря 2015 г.

И WordPress, и Drupal в настоящее время борются за технологический скачок, чтобы предоставить пользователям больше возможностей, подобных приложениям. Разговор о разделении архитектуры Drupal является важным для разработчиков WordPress, чтобы следить за ним и учиться у него.