Implicații ale gândirii în blocuri în loc de blobs

Gutenberg este un editor bazat pe JavaScript (mai precis, este un editor bazat pe React), care va transforma în curând experiența de a crea conținut pentru WordPress și (într-o etapă viitoare când Gutenberg este transformat într-un constructor de site) experiența de a crea Site-uri WordPress.

Gutenberg, constructorul site-ului, va cere un alt mod de a gândi cum să pună bazele unui site web. În ceea ce putem numi deja modelul „vechi”, site-urile WordPress sunt create dând structură prin șabloane ( header.php , index.php , sidebar.php , footer.php ) și preluând conținutul paginii dintr-un singur blob. de cod HTML. În noul model, pagina are componente (React) plasate pe toată pagina, fiecare dintre ele controlându-și propria logică, încărcându-și propriile date și auto-randarea.

Pentru a aprecia vizual schimbarea viitoare, WordPress trece de la aceasta:

…la acest:

Cred că trecerea de la blocuri de cod HTML la componente pentru site-uri de construcție nu este nimic mai puțin decât o schimbare de paradigmă. Impactul lui Gutenberg este mult mai mult decât o trecere de la PHP la JavaScript: există lucruri care ar putea fi făcute în trecut, care probabil nu vor mai avea sens. De asemenea, se deschide o nouă lume de posibilități, cum ar fi interacțiunile bogate și puternice ale utilizatorilor. Dezvoltatorii web nu vor trece de la crearea site-urilor într-o limbă la crearea site-urilor într-o altă limbă, deoarece site-ul nu va mai fi același; va fi un site complet diferit care va fi construit.

Lectură recomandată : Anatomia completă a editorului WordPress Gutenberg

Gutenberg nu a fost încă acceptat pe deplin de comunitatea WordPress, din multe motive. În primul rând, noua arhitectură se bazează pe o multitudine de instrumente și tehnologii (React, NPM, Webpack, Redux și așa mai departe) care este mult mai dificil de învățat și de stăpânit decât vechea cea bazată pe PHP. Și, deși poate merita să înveți o nouă stivă care oferă noi funcționalități, nu orice site mom&pop are nevoie de aceste funcții noi, strălucitoare.

La urma urmei, nu este o coincidență că 30% din toate site-urile de pe glob sunt site-uri WordPress: cele mai multe dintre acestea sunt site-uri cu adevărat simple, cum ar fi blogurile, nu rețele sociale dinamice precum Facebook. Pe de altă parte, incluziunea WordPress înseamnă că oricine ar putea construi un site web simplu - chiar și oameni fără experiență de codare, cum ar fi designeri, marketerii de conținut și bloggeri.

Dar complexitatea noii arhitecturi va lăsa pe mulți oameni afară (nici măcar nu vreau să mă gândesc la depanarea site-ului meu în cod JavaScript miniat). Și, pe de altă parte, odată ce Gutenberg va fi lansat, React, susținut de Facebook, va fi adăugat la până la 30% din toate site-urile web din lume - peste noapte. Mulți oameni nu se simt confortabil să acorde atât de multă putere oricărui tip de bibliotecă JavaScript, în timp ce mulți alții nu au încredere în Facebook. Pentru a atenua această îngrijorare, Gutenberg a rezumat React pentru a permite și codarea în alte cadre sau biblioteci; cu toate acestea, în practică, React va fi, fără îndoială, biblioteca JavaScript predominantă.

Și totuși, perspectiva de a vi se oferi o nouă lume de posibilități este într-adevăr dulce. În cazul meu, sunt entuziasmat. Cu toate acestea, entuziasmul meu nu este legat de tehnologie (React) sau de implementare (Gutenberg), ci de concept, care este de a crea site-uri folosind componente ca unitate de construcție. În viitor, implementarea poate trece pe o altă platformă, cum ar fi Vue, dar conceptul va rămâne.

Nu este întotdeauna ușor să prevăd ce funcții noi vom putea implementa. Este nevoie de timp pentru a ne adapta la o nouă paradigmă și avem tendința de a folosi noile instrumente în modul vechi până când ne dăm seama cum să folosim noile instrumente pentru a realiza noi obiective. Chiar și fișierele PDF (care sunt o reprezentare a tipăririi, tehnologia predominantă înainte de nașterea web-ului) sunt încă o vedere comună pe web, neglijând avantajele pe care le are web-ul față de tipărire.

„A imita hârtie pe ecranul unui computer este ca și cum ai rupe aripile unui 747 și a-l folosi ca autobuz pe autostradă.”

— Ted Nelson

În acest articol, voi analiza câteva implicații ale construirii site-urilor printr-o arhitectură bazată pe componente (ca concept) și prin Gutenberg (ca implementare), inclusiv ce funcționalități noi poate oferi, cât de mai bine se poate integra cu dezvoltarea actuală a site-ului web. tendințe și ce înseamnă pentru viitorul WordPress.

Versatilitate extinsă și disponibilitate a conținutului

Un efect secundar foarte important al tratării întregului conținut ca blocuri este că permite să țintiți bucăți de HTML individual și să le folosiți pentru diferite ieșiri. În timp ce conținutul inserat în blob-ul HTML este accesibil numai prin intermediul paginii web, în ​​bucăți, acesta poate fi accesat printr-un API, iar metadatele sale sunt ușor disponibile. Luați elemente media - cum ar fi videoclipuri, audio sau imagini. Ca bloc autonom, videoclipul poate fi redat într-o aplicație, audio poate fi redat ca un podcast, iar imaginile pot fi atașate la e-mail atunci când trimiteți un rezumat - toate acestea fără a fi nevoie să analizați codul HTML.

La fel, conținutul din blocuri poate fi adaptat pentru diferite medii: de la cel mai mic ecran la cele mai mari, touchscreen sau desktop, comandat prin voce sau prin atingere, 2D/AR/VR, sau cine știe ce ar putea aduce viitorul. De exemplu, un bloc audio permite redarea sunetului pe un Apple Watch, comandat prin voce prin sistemul In-car sau un AWS Echo, sau ca element plutitor în lumea noastră virtuală atunci când folosiți o cască VR. Blocurile pot facilita, de asemenea, configurarea unei singure surse de adevăr pentru conținutul care urmează să fie publicat în diferite rezultate, cum ar fi un site web receptiv, AMP, aplicație mobilă, e-mail sau orice altul, așa cum a făcut NPR prin intermediul programului Create Once. , abordare Publicare peste tot (COPE).

Notă : Pentru mai multe informații despre aceste subiecte, vă sugerez să vizionați conținutul lui Karen McGrane într-o discuție despre Apocalipsa zombie.

Blocurile pot îmbunătăți și experiența utilizatorului. Dacă navighează pe site prin 3G, blocurile se pot auto-renda într-un mod de conexiune lentă pentru a afișa imagini de calitate scăzută și pentru a omite încărcarea videoclipurilor. Sau poate îmbunătăți aspectul, cum ar fi oferirea de a afișa o galerie de imagini cu un singur clic în orice punct al paginii web și nu doar în locul în care a fost încorporată în articol.

Aceste experiențe pot fi obținute prin separarea conținutului de formă, ceea ce implică faptul că prezentarea și sensul conținutului sunt decuplate și doar sensul este salvat în baza de date, făcând datele de prezentare secundare și salvându-le în alt loc. HTML semantic este o expresie a acestui concept: ar trebui să folosim întotdeauna <em> care implică sens, în loc de <i> care este o formă de prezentare (pentru a face ca caracterul să fie afișat cu italice), pentru că atunci acest conținut va fi disponibil pentru alte medii, cum ar fi vocea (Alexa nu poate citi cu caractere cursive, dar poate pune accent pe propoziție).

Obținerea unei separări temeinice a conținutului de formă este foarte dificilă, deoarece codul de prezentare va fi adesea adăugat în interiorul blocului, prin marcaj HTML (adăugarea clasei „pull-right” implică deja prezentare). Cu toate acestea, arhitectura site-ului folosind blocuri ajută deja la atingerea unui anumit nivel de separare la nivel de aspect. În plus, blocurile create pentru a face un singur lucru, și pentru a-l face foarte bine, pot folosi HTML semantic adecvat, au o bună separare a preocupărilor în propria arhitectură referitoare la HTML, JS și CSS (astfel încât să le portați pe alte platforme). poate necesita doar un efort minim) și să fie accesibil, cel puțin la nivel de componentă.

Notă : o regulă generală: cu cât o componentă este mai incluzivă, cu atât este mai pregătită pentru medii care nu au fost încă inventate.

Din păcate, Gutenberg nu a fost conceput cu acest scop în minte, așa că blocurile conțin o mulțime de markup HTML și pentru prezentare. De exemplu, un bloc de imagine dintr-o imagine externă are, ca semnificație, doar URL-ul imaginii, descrierea alternativă și legenda (și posibil, de asemenea, lățimea și înălțimea); după crearea unui bloc de imagine, următoarea bucată de cod a fost salvată în DB (class aligncenter este pentru prezentare, iar marcajul <div class="wp-block-image" /> ar fi complet redundant dacă stochează numai sens):

 <!-- wp:image {"align":"center"} --> <div class="wp-block-image"> <figure class="aligncenter"> <img src="https://cldup.com/cXyG__fTLN.jpg" alt="Beautiful landscape"/> <figcaption>If your theme supports it, you'll see the "wide" button on the image toolbar. Give it a try.</figcaption> </figure> </div> <!-- /wp:image -->

În plus, blocurile sunt salvate în conținutul postării (care este un blob HTML mare) în loc ca fiecare să aibă o intrare proprie în baza de date. Blocurile reutilizabile (numite și blocuri globale) au însă propria lor intrare, ceea ce mă face să mă tem că dezvoltatorii ar putea converti blocurile standard în blocuri reutilizabile doar pentru un hack rapid pentru a le accesa direct în DB.

În mod similar, sunt îngrijorat că, dacă nu sunt proiectate corespunzător, blocurile pot provoca chiar ravagii în site-urile noastre. De exemplu, dezvoltatorii inconștienți pot ignora regula puterii minime, folosind JavaScript nu doar pentru funcționalitate, ci și pentru CSS și markup. În plus, funcționalitatea de redare pe partea serverului (SSR) a lui Gutenberg nu este izomorfă (adică nu permite unei singure baze de cod să producă ieșirea atât pentru codul client, cât și pe partea serverului), prin urmare blocurile dinamice trebuie să implementeze funcția pentru a genera codul HTML de asemenea, ca PHP pentru a oferi îmbunătățiri progresive (fără de care site-ul este inaccesibil în timp ce este încărcat inițial).

Pe scurt, blocurile sunt un pas în direcția corectă spre a face conținutul WordPress disponibil pe orice format și pentru orice mediu, dar nu sunt o soluție definitivă, așa că mai trebuie de făcut multă muncă.

Performanţă

Performanța contează. Site-urile mai rapide conduc la utilizatori mai fericiți, ceea ce duce la rate de conversie mai bune. Echipa de la Etsy, de exemplu, elimină funcții noi, oricât de interesante ar fi, dacă acestea fac ca timpul de încărcare a site-ului lor să depășească un prag critic (recomand să urmăriți discursul lui Allison McKnight despre performanța construcției pe termen lung și diapozitive), în timp ce echipa de la Twitter și-a re-arhitectat site-ul în urmă cu câțiva ani pentru a sprijini randarea pe server pentru a afișa conținutul cât mai curând posibil și implementează continuu o mulțime de mici modificări care se adună pentru a oferi o experiență rapidă de utilizator.

JavaScript fiind atât de atractiv pentru dezvoltatori, ei nu se confruntă cu nicio constrângere în ceea ce privește utilizarea acestuia, ceea ce este o problemă reală: JavaScript este foarte scump în ceea ce privește performanța și ar trebui să fie folosit cu mare atenție.

Așa cum este acum, Gutenberg este departe de a fi optim: în timp ce crearea unei postări cu editorul vechi (pentru care trebuie să instalăm Editorul clasic) necesită încărcarea a aproximativ 1,4 MB de JavaScript, Gutenberg încarcă aproximativ 3,5 MB de JavaScript, doar pentru elementul său de bază . experiență (adică fără a instala niciun bloc suplimentar):

Asta înseamnă că, așa cum este acum, 3,5 MB este linia de bază, iar dimensiunea de încărcare va crește doar de acolo, pe măsură ce administratorul site-ului instalează mai multe blocuri. După cum sa văzut într-un articol recent de pe Smashing Magazine, crearea unui bloc de mărturii a necesitat 150 KB de JavaScript redus. Câte blocuri va necesita un site standard? Câți MB de JavaScript va trebui să descarce site-ul mediu?

Implicațiile sunt mai multe: pentru unul, un site greu este în afara accesului următorului miliard de utilizatori, care au acces în principal pe conexiuni lente și care cumpără planuri de date care reprezintă o parte semnificativă din salariul lor. Pentru ei, fiecare MB de date face diferența: trimiterea de mesaje Whatsapp este accesibilă, descărcarea mai multor MB de scripturi doar pentru a încărca un site nu este.

Este adevărat că utilizatorul site-ului web nu va trebui să interacționeze cu Gutenberg, deoarece Gutenberg este pur și simplu pentru a construi site-ul, nu pentru a-l folosi: Gutenberg este un editor back-end, nu un editor front-end (și poate niciodată fi — cel puțin ca parte a nucleului WordPress). Cu toate acestea, creatorii de conținut vor fi penalizați și sunt deja o țintă considerabilă. În plus (așa cum am argumentat mai devreme), utilizatorii pot ajunge să fie penalizați și prin blocuri dinamice, care își pot crea marcajul prin JavaScript la nivelul clientului în loc de PHP pe partea serverului.

Există, de asemenea, problema balonării din funcționalitatea duplicată adăugată de pluginuri terță parte. Pe vremuri, un site WordPress putea să fi încărcat mai multe versiuni de jQuery, ceea ce era relativ ușor de remediat. În zilele noastre, există o gamă largă de biblioteci open source din care să alegeți pentru implementarea unei funcționalități necesare (glisare și plasare, calendare, componente cu selecție multiplă, carusele etc.), așa că este mai probabil decât nu un site cu zeci de blocuri terțe. va avea aceeași funcționalitate implementată de biblioteci diferite, creând balonare inutilă. În plus, se adaugă un pic de umflare la Gutenberg însuși: deoarece blocurile sunt înregistrate în frontend, dezregistrarea unui bloc deja înregistrat se face prin încărcarea unui script suplimentar. În opinia mea, aceasta este una dintre cele mai mari provocări pentru colaboratorii Gutenberg: să pună în aplicare un proces simplificat care să permită oricui (nu doar dezvoltatorilor experimentați cu Webpack) să elimine bibliotecile nedorite și să împacheteze doar setul minim de resurse necesare aplicației. .

În sfârșit, menționez din nou că Gutenberg acceptă randarea pe server, dar pentru că s-ar putea să nu fie ușor de întreținut, dezvoltatorii pot fi tentați să nu se bazeze pe ea. În acest caz, există costul unor călătorii dus-întors suplimentare necesare pentru a obține datele de la punctele finale REST, doar pentru a reda aspectul, timp în care utilizatorul va aștepta.

În opinia mea, performanța va fi una dintre provocările majore pentru Gutenberg, cea care ar putea face sau sparge în ceea ce privește adoptarea pe scară largă, și mai este încă multă muncă de făcut, vizând în principal următoarea etapă când Gutenberg devine site. constructor.

Standarde web

După cum s-a menționat mai devreme, Gutenberg renunță la React pentru a oferi o abordare agnostică a cadrului de construcție care, dacă sunt implementate corect, pot evita blocarea WordPress în React. Comunitatea WordPress este precaută atunci când îmbină orice cadru JavaScript în nucleul WordPress, în mare parte pentru că Backbone.js, la scurt timp după ce a fost adăugat la nucleul WordPress, a înregistrat o scădere bruscă a popularității și, în afară de alimentarea Media Manager, nu au fost realizate multe caracteristici. Cu acesta. Chiar dacă React este cea mai populară bibliotecă JavaScript în acest moment, nu există niciun motiv să credem că acesta va fi întotdeauna cazul (după cum poate atesta dezlegarea jQuery), iar WordPress trebuie să fie pregătit pentru când va sosi în sfârșit acea zi (ceea ce, având în vedere rapiditatea). ritmul tehnologiei, se poate întâmpla mai devreme decât era de așteptat).

Cea mai bună modalitate de a evita blocarea oricărei biblioteci este prin standardele web și, mai precis în acest caz, implementarea blocurilor prin componente web. Componentele web sunt componente puternic încapsulate care funcționează cu API-urile browserului, deci nu necesită nicio bibliotecă JavaScript pentru a lucra. Cu toate acestea, ele pot fi implementate prin orice cadru JavaScript la nivelul clientului.

Chiar dacă React nu oferă încă o integrare perfectă cu componentele web, în ​​cele din urmă (sau mai degrabă sperăm) o va face. După cum este explicat în documentația React, componentele web și componentele React pot funcționa alături de:

„Componentele React și Web sunt create pentru a rezolva diferite probleme. Componentele Web oferă o încapsulare puternică pentru componentele reutilizabile, în timp ce React oferă o bibliotecă declarativă care menține DOM-ul sincronizat cu datele dvs. Cele două obiective sunt complementare. În calitate de dezvoltator, sunteți liber să utilizați React în Componentele dvs. Web sau să utilizați Componentele Web în React sau ambele.”

De astăzi, perspectivele acestei situații nu par foarte promițătoare: nu am reușit să găsesc niciun tutorial pentru blocuri de construcție cu componente web. Cred că comunitatea ar trebui să-și concentreze eforturile către această cauză, încurajând dezvoltatorii să înceapă să construiască blocuri folosind componente web și cu cât mai devreme, cu atât mai bine, deoarece Gutenberg ne obligă oricum să învățăm noi tehnologii, chiar acum. Este o oportunitate de a stabili o bază puternică cu standarde web, încă de la început.

Interoperabilitatea între site-uri, omogenizarea site-urilor

Un bloc este o entitate mai mică decât o temă sau un plugin, așa că în cele din urmă blocurile vor fi accesibile pe cont propriu și vor fi achiziționate prin piețele de bloc nou create. Cel mai probabil va avea loc inițial o explozie cambriană de blocuri, deoarece mulți jucători din ecosistem se grăbesc să fie primii care își comercializează soluțiile, conducând pe termen mediu și lung spre consolidarea celor mai de succes.

Odată ce praful s-a așezat, câteva blocuri vor ieși în evidență și vor deveni câștigători, obținând cea mai mare parte a pieței pe categoriile lor specifice. Dacă/când se va întâmpla asta va fi o cauză atât de îngrijorare, cât și de jubilație: îngrijorarea cu privire la un nou val de omogenizare a web-ului care are loc (cum s-a întâmplat cu Bootstrap), deoarece site-urile care folosesc aceleași componente pot ajunge să aibă același aspect și simț. , o jubilare cu privire la o interoperabilitate crescută între site-uri de la baza pe aceleași componente și pe aceleași API-uri, care pot deschide porțile către noi oportunități.

Sunt deosebit de încântat de extinderea interoperabilității între site-uri. Este o zonă care ar putea, pe termen lung, să anuleze regnuri precum Facebook: în loc să se bazeze pe o poartă monopolistă pentru partajarea informațiilor, site-urile cu comunități diferite pot partaja cu ușurință date între ele, direct. Acesta nu este un concept nou: mișcarea IndieWeb a lucrat de mult timp pentru a permite oricui să-și dețină propriile date pe propriile servere, prin faptul că site-urile web vorbesc între ele prin microformate. De exemplu, standardul lor web Webmention permite două site-uri să aibă o conversație, în care fiecare comentariu și răspuns este stocat în ambele, iar Micro.blog oferă un fel de Twitter, dar bazat pe web deschis, în care postările pe cronologia utilizatorului sunt adunate din fluxurile RSS și JSON de pe site-urile abonate. Aceste eforturi sunt minunate, dar totuși un impact foarte mic, deoarece există un anumit nivel de cunoștințe tehnologice necesare pentru a fi parte din ele. Arhitectura bazată pe componente a lui Gutenberg poate produce un impact mult mai larg: blocurile populare pot permite a zeci de site-uri WordPress să vorbească între ele, permițând în cele din urmă ca până la 30% din toate site-urile de pe web să facă parte dintr-o rețea descentralizată, slab cuplată. .

Această zonă va avea nevoie de multă muncă, totuși, înainte de a fi viabilă. Nu cred că punctele finale REST implicite sunt cea mai bună interfață de comunicare, deoarece nu au fost concepute în acest scop (cei de la micro.blog au propus o soluție mai bună prin interfața lor JSON, care se bazează pe specificația RSS). În plus, REST este însuși depășit de GraphQL, așa că nu aș pune mari speranțe în el pe termen lung. De asemenea, sunt implicat în găsirea unei modalități mai bune, pentru care lucrez în prezent la un alt tip de API, care poate prelua toate datele necesare într-o singură cerere și acceptă extensibilitatea printr-o arhitectură bazată pe componente.

De asemenea, mă aștept ca integrarea cu serviciile cloud să fie mai proeminentă, deoarece furnizorii își pot elibera propriile blocuri pentru a interacționa cu propriile servicii. Deoarece o componentă este o unitate autonomă, doar prin glisarea și plasarea blocului în pagină face deja toată munca din perspectiva utilizatorului, făcând foarte ușor să construiți site-uri web puternice, cu puține sau deloc cunoștințe. De exemplu, un furnizor de stocare a imaginilor precum Cloudinary ar putea elibera un bloc care decupează automat imaginea în funcție de portul de vizualizare al dispozitivului sau solicită imaginea ca WebP dacă este acceptat sau alte cazuri de utilizare.

Pe scurt, consolidarea pieței de blocuri poate aduce omogenizare a modului în care arată și se simte, ceea ce ar fi un eveniment regretabil și ar trebui evitat, și capabilități puternice privind interoperabilitatea și partajarea datelor între site-uri și integrarea cu serviciile cloud.

Integrare cu bibliotecile de modele

O bibliotecă de modele este o colecție de elemente de proiectare a interfeței cu utilizatorul, fiecare dintre ele adesea compusă din fragmente de HTML, JS și CSS. Un bloc este o componentă autonomă, adesea alcătuită din biți de HTML, JS și CSS. Deci blocurile sunt în mod evident potrivite pentru a fi documentate/construite cu biblioteci de modele. Ca blocurile să își livreze bibliotecile de modele ar fi foarte mult, deoarece ar putea permite echipelor să nu înceapă implementarea bibliotecii de modele a site-ului doar la nivel de site, ci ca o agregare și o rafinare a bibliotecilor de mini-modele din toate blocurile necesare.

Cred că ceva asemănător cu procesul de simplificare pentru producerea pachetelor JavaScript fără bloat, despre care am menționat mai devreme, se întâmplă în acest caz, dar în ceea ce privește UI/UX/Documentație. Ar fi atât o provocare, cât și o oportunitate pentru colaboratorii Gutenberg să pună în aplicare un proces care facilitează dezvoltatorilor de blocuri să creeze biblioteci de modele pentru blocurile lor care, atunci când sunt agregate toate împreună, pot duce la o bibliotecă de modele coerentă pentru site. Bine implementată, o astfel de caracteristică ar putea reduce costurile șantierelor din perspectiva documentării/întreținerii.

Ce va deveni WordPress?

Gutenberg va face cu siguranță site-urile web mai atractive, chiar dacă cu prețul unui nivel necesar de expertiză pe care nu toată lumea va fi capabilă să-l descurce. Pe termen lung, acest lucru poate duce la o calitate mai mare, o cantitate mai mică. Venind de la maxima WordPress „Democratizing Publishing”, aceasta poate deveni o problemă.

Sunt entuziasmat de Gutenberg, dar mai mult ca concept de arhitectură bazată pe componente, decât implementarea bazată pe React. În termeni generali, sunt de acord cu ceea ce Matt Mullenweg a spus în timpul WordCamp Europe 2018 pentru a-l justifica pe Gutenberg:

„Fondul WordPress, care acum ne-a servit bine timp de cincisprezece ani, nu va dura în următorii cincisprezece.”

Cu toate acestea, cred și că WordPress-ul de cincisprezece ani în viitor poate ajunge să fie complet diferit de cel pe care îl cunoaștem astăzi. Mă întreb dacă WordPress va ajunge în primul rând să fie editorul bazat pe client, și nu mult mai mult: inițiativa de a integra Gutenberg în Drupal, cu scopul de a-l face pe Gutenberg să devină editorul web-ului deschis, va oficializa WordPress ca un CMS care operează fără cap. prin punctele finale REST. Aceasta este o dezvoltare bună în sine, dar va face back-end-ul WordPress dispensabil: dacă orice altă platformă back-end oferă caracteristici mai bune, nu mai există niciun motiv să rămânem la back-end-ul WordPress. La urma urmei, Gutenberg din partea clientului va putea lucra cu oricare dintre ele, în timp ce simplitatea creării unui site cu WordPress se va pierde, egalând condițiile de joc cu toate celelalte platforme.

În special, nu aș fi surprins dacă dezvoltatorii consideră că menținerea a două baze de cod (una în JavaScript și una în PHP) pentru randarea blocurilor dinamice este prea grea și decid să se orienteze către platforme care acceptă randarea izomorfă pe server. Dacă acest scenariu se întâmplă cu adevărat, Matt ar decide să schimbe backend-ul WordPress la Node.js?

În principal din cauza acestei probleme, îndrăznesc să spun că WordPress de peste 15 ani poate fi o entitate foarte diferită de ceea ce este în prezent. Cine știe ce se va întâmpla?

Concluzie

Prin transformarea componentelor în noua unitate pentru șantiere, introducerea lui Gutenberg va fi transformatoare pentru WordPress. Și ca în orice schimbare de paradigmă, vor exista câștigători și învinși. Diferiți factori interesați vor considera Gutenberg o evoluție pozitivă sau negativă, în funcție de propria situație: în timp ce calitatea unui site web va crește, prețul construirii unui astfel de site din angajarea dezvoltatorilor care pot face față complexității acestuia va crește și el, făcându-l mai puțin accesibil. și mai puțin populare.

Sunt vremuri interesante, dar și momente cruciale. De acum înainte, WordPress poate începe încet să fie o entitate diferită de ceea ce suntem obișnuiți și, în cele din urmă, ar putea fi nevoie să ne gândim din nou la ce este WordPress și ce reprezintă acesta.