Społeczność Drupala rozważa architekturę decoupled

Na początku tego tygodnia Dries Buytaert, twórca i lider projektu dla Drupala, otworzył na swoim blogu dyskusję na temat przyszłości architektury Drupala w poście zatytułowanym Czy powinniśmy oddzielić Drupala od frameworka po stronie klienta?

Buytaert twierdzi, że użytkownicy oczekują od stron internetowych wrażeń przypominających aplikacje, biorąc pod uwagę ich wrażenia z interakcji z kanałem wiadomości na Facebooku, skrzynką odbiorczą Gmaila i transmisją na żywo na Twitterze.

„Wiele interfejsów administracyjnych Drupala i witryn Drupal mogłoby skorzystać z podobnie płynnego, natychmiastowego doświadczenia użytkownika” — powiedział Buytaert. „Jako kierownik projektu Drupala zadaję sobie pytanie: w jaki sposób nasza społeczność może czuć się aktywna i zachęcona do budowania bogatych doświadczeń użytkowników?”

Dyskusja na temat oddzielenia Drupala od frameworka po stronie klienta toczy się w interesującym czasie, ponieważ opis State of the Word Matta Mullenwega zapowiadał JavaScript jako przyszłość WordPressa i sieci. Jego uwagi końcowe zachęciły programistów do nauki JavaScript i rozpoczęcia tworzenia aplikacji opartych na WordPressie na przyszłość.

Komentator postu Buytaert nawiązuje do wydania Calypso przez Automattic:

Wydaje się, że ten post jest przynajmniej częściowo reakcją na ogłoszenie Calypso przez WordPressa. Mamy nadzieję, że możemy skupić się na podejmowaniu decyzji, które są właściwe dla przyszłości Drupala, zamiast pochopnie reagować na to, co robi inny CMS, zwłaszcza gdy mówiłeś w kółko, że WordPress nie jest prawdziwą konkurencją dla Drupala.

Buytaert utrzymuje, że jego rozważania na temat Drupala były motywowane niezależnie i nie jest to pierwszy raz, kiedy pisze o rozdzieleniu tylnego i przedniego końca.

„Jeśli chodzi o ogłoszenie Calypso w WordPressie — właściwie zacząłem pisać ten wpis na blogu przed ogłoszeniem Calypso” — powiedział. „Nie wierzę, że Calypso wpłynęło na moją pozycję”.

Buytaert poprzedził tę dyskusję faktem, że użytkownicy uznali doświadczenia podobne do aplikacji za pewnik jako podstawę interakcji na stronach internetowych. Cała sieć zmierza w tym kierunku, a systemy CMS, takie jak Drupal i WordPress, są teraz zmuszone wspiąć się na tę górę, jeśli chcą pozostać aktualne. Oba projekty grają od tyłu, starając się dogonić oczekiwania użytkowników.

Wyzwanie standaryzacji ram

Pod wieloma względami dyskusja na temat wpisu Buytaert dotyczy tego, dokąd zmierza WordPress, a zwłaszcza rozważenie standaryzacji na konkretnym frameworku.

Buytaert opowiada się za stopniowym oddzieleniem środowiska administratora i użytkownika końcowego Drupala, jednocześnie umożliwiając budowanie w pełni oddzielonych doświadczeń na platformie. Sugeruje, że najlepszym sposobem, aby to zrobić, jest „formalna standaryzacja w oparciu o w pełni funkcjonalne ramy MV* (np. Angular, Ember, Backbone i Knockout) lub bibliotekę widoków opartą na komponentach (np. React, Vue i Riot). ”

Ponieważ nie jest front-end developerem, Buytaert prosi społeczność Drupala o informację, jaki framework najlepiej sprawdzi się w przypadku progresywnego rozdzielania. Uznaje również powody, dla których standaryzacja określonych ram może być niewskazana na dłuższą metę:

Pomimo potencjalnych korzyści, istnieją również dobre powody, aby nie stosować jednego frameworka po stronie klienta. Nowe frameworki front-end są tworzone w tempie, które wydaje się niemożliwe do utrzymania; co dziewięć miesięcy w bloku pojawia się nowy dzieciak. Projektowi tak dużemu jak Drupal trudno jest objąć pojedynczą technologię, gdy nie ma gwarancji jej długowieczności.

Niemniej jednak Buytaert uważa, że ​​przemyślany wybór i okresowa ponowna ocena struktury może przezwyciężyć te wady.

Zachęcając programistów WordPressa do nauki JavaScriptu, Matt Mullenweg nie zidentyfikował ani jednego frameworka, ale pozostawił go otwarty. Ponieważ Calypso firmy Automattic jest oparte na React, wydaje się, że jest wczesnym faworytem.

Jeśli rdzeń WordPressa przyjmie technologię stojącą za Calypso (lub alternatywę podobną do Calypso), aby zapewnić lepsze wrażenia z publikowania, czy rdzeń będzie standaryzował framework/bibliotekę, czy będzie nadal umożliwiał i zachęcał programistów rozszerzeń do korzystania z jakichkolwiek frameworków?

Jeden z komentatorów wskazuje na potencjalne problemy z wyborem frameworka przez Drupala, co niektórzy mogą postrzegać jako oficjalną rekomendację:

Istnieje już wiele projektów korporacyjnych wykorzystujących oddzielone podejście Drupala i oczywiście używają one wielu różnych frameworków, ale ten, który najczęściej używam, to React. W rzeczywistości w projekcie, nad którym teraz pracuję, organizacja wkracza na całość z Reactem. Jeśli Drupal zdecydowałby się na przykład na Angular, jak wpłynęłoby to na organizacje, które dokonują dużych inwestycji w inne frameworki? Może nie rozumiem do końca, jak to może działać, ale wybór jednego frameworka wydaje się być podziałem i destrukcją – destrukcją w zły sposób, a nie w sposób SV.

Myślę, że ułatwianie architektur oddzielonych jest świetne i powinno być czymś, co robi Drupal, ale powinno to robić w sposób niezależny od używanego frameworka FE.

Buytaert wskazuje kilka alternatyw dla dostarczania frameworka po stronie klienta z rdzeniem Drupal, w tym polecanie frameworka, ale nie dostarczanie z nim, lub włączanie go do rdzenia, ale ułatwianie zastąpienia innym frameworkiem wybranym przez programistę.

Jego post i komentarze, które następują, to początek ożywionej, przemyślanej dyskusji, która pomoże ukształtować przyszłość rozwoju Drupala. Dzisiaj Buytaert wzywa do składania propozycji, które nakreśliłyby prototyp działającej wersji progresywnego rozdzielania.

Chciałbym przeczytać propozycję prototypu działającej wersji progresywnego rozdzielania: https://t.co/tJxT66cKoy #drupal

— Dries Buytaert (@Dries) 11 grudnia 2015 r.

Zarówno WordPress, jak i Drupal są obecnie zaangażowane w walkę o dokonanie skoku technologicznego, aby zapewnić użytkownikom bardziej zbliżone do aplikacji doświadczenia. Rozmowa dotycząca oddzielenia architektury Drupala jest bardzo ważna dla programistów WordPressa, z których mogą się uczyć i od nich czerpać.