Implicazioni del pensiero in blocchi anziché in blob

Gutenberg è un editor basato su JavaScript (più precisamente, è un editor basato su React), che presto trasformerà l'esperienza di creazione di contenuti per WordPress e (in una fase imminente quando Gutenberg verrà trasformato in un costruttore di siti) l'esperienza di creazione Siti WordPress.

Gutenberg, il costruttore di siti, richiederà un modo diverso di pensare a come gettare le basi di un sito web. In quello che possiamo già chiamare il "vecchio" modello, i siti WordPress vengono creati dando struttura tramite modelli ( header.php , index.php , footer.php sidebar.php e recuperando il contenuto della pagina da un singolo blob di codice HTML. Nel nuovo modello, la pagina ha componenti (React) posizionati in tutta la pagina, ognuno dei quali controlla la propria logica, carica i propri dati e esegue il rendering automatico.

Per apprezzare visivamente il cambiamento imminente, WordPress si sta muovendo da questo:

…a questo:

Credo che il passaggio da blob di codice HTML a componenti per i cantieri sia a dir poco un cambio di paradigma. L'impatto di Gutenberg è molto più di un passaggio da PHP a JavaScript: ci sono cose che potrebbero essere fatte in passato che probabilmente non avranno più senso. Allo stesso modo, si apre un nuovo mondo di possibilità, come interazioni utente ricche e potenti. Gli sviluppatori Web non passeranno dalla creazione dei loro siti in una lingua alla creazione dei loro siti in un'altra lingua perché il sito non sarà più lo stesso; sarà un sito completamente diverso che verrà costruito.

Letture consigliate : L'anatomia completa dell'editor WordPress di Gutenberg

Gutenberg non è stato ancora completamente accolto dalla community di WordPress, per molte ragioni. Per prima cosa, la nuova architettura si basa su una pletora di strumenti e tecnologie (React, NPM, Webpack, Redux e così via) che è molto più difficile da imparare e padroneggiare rispetto alla vecchia basata su PHP. E mentre potrebbe valere la pena imparare un nuovo stack che offra nuove funzionalità, non tutti i siti mom&pop hanno bisogno di queste nuove e brillanti funzionalità.

Del resto non è un caso che il 30% di tutti i siti nel mondo siano siti WordPress: la maggior parte di questi sono siti davvero semplici come i blog, non social network dinamici come Facebook. Dall'altro, l'inclusività di WordPress significa che chiunque può creare un semplice sito Web, anche le persone senza esperienza di programmazione, come designer, marketer di contenuti e blogger.

Ma la complessità della nuova architettura lascerà fuori molte persone (non voglio nemmeno pensare al debug del mio sito nel codice JavaScript ridotto). E per un altro, una volta che Gutenberg sarà pubblicato, React, supportato da Facebook, verrà aggiunto fino al 30% di tutti i siti Web del mondo, durante la notte. Molte persone sono a disagio nel dare così tanto potere a qualsiasi tipo di libreria JavaScript, mentre molte altre sono diffidenti nei confronti di Facebook. Per alleviare questa preoccupazione, Gutenberg astrae React per abilitare anche la codifica in altri framework o librerie; tuttavia, in pratica, React sarà senza dubbio la libreria JavaScript predominante.

Eppure, la prospettiva di essere offerto un nuovo mondo di possibilità è davvero dolce. Nel mio caso, sono entusiasta. Tuttavia, la mia eccitazione non riguarda la tecnologia (React) o l'implementazione (Gutenberg), ma il concetto, che è quello di creare siti utilizzando i componenti come unità costruttiva. In futuro, l'implementazione potrebbe passare a un'altra piattaforma, come Vue, ma il concetto rimarrà.

Prevedere quali nuove funzionalità saremo in grado di implementare non è sempre facile. Ci vuole tempo per adattarsi a un nuovo paradigma e tendiamo a usare i nuovi strumenti alla vecchia maniera finché non ci viene in mente come usare i nuovi strumenti per raggiungere nuovi obiettivi. Anche i file PDF (che sono una rappresentazione della stampa, la tecnologia predominante prima della nascita del web) sono ancora una vista comune sul web, trascurando i vantaggi che il web ha rispetto alla stampa.

"Imitare la carta sullo schermo di un computer è come strappare le ali di un 747 e usarlo come un autobus in autostrada".

—Ted Nelson

In questo articolo, analizzerò diverse implicazioni della costruzione di cantieri attraverso un'architettura basata su componenti (come il concetto) e attraverso Gutenberg (come l'implementazione), comprese quali nuove funzionalità può offrire, quanto meglio può integrarsi con lo sviluppo di siti Web attuali tendenze e cosa significa per il futuro di WordPress.

Versatilità estesa e disponibilità dei contenuti

Un effetto collaterale molto importante del trattamento di tutti i contenuti come blocchi è che consente di indirizzare blocchi di HTML individualmente e usarli per output diversi. Mentre il contenuto inserito nel BLOB HTML è accessibile solo tramite la pagina Web, come blocchi è possibile accedervi tramite un'API e i suoi metadati sono prontamente disponibili. Prendi elementi multimediali, come video, audio o immagini. Come blocco autonomo, il video può essere riprodotto in un'app, l'audio può essere riprodotto come podcast e le immagini possono essere allegate all'e-mail durante l'invio di un riassunto, tutto questo senza dover analizzare il codice HTML.

Allo stesso modo, i contenuti dei blocchi possono essere adattati a diversi mezzi: dallo schermo più piccolo a quelli più grandi, touchscreen o desktop, comandati dalla voce o dal tocco, 2D/AR/VR o chissà cosa potrebbe riservare il futuro. Ad esempio, un blocco audio consente di riprodurre l'audio su un Apple Watch, comandato dalla voce tramite il sistema In-car o un AWS Echo, o come elemento fluttuante nel nostro mondo virtuale quando si utilizza un visore VR. I blocchi possono anche semplificare l'impostazione di un'unica fonte di verità per i contenuti da pubblicare in diversi output, come un sito Web reattivo, AMP, un'app mobile, e-mail o qualsiasi altro, come è stato fatto da NPR tramite il loro Crea una volta , Approccio Pubblica ovunque (COPE).

Nota : per maggiori informazioni su questi argomenti, suggerisco di guardare il discorso di Karen McGrane in a Zombie Apocalypse.

Anche i blocchi possono migliorare l'esperienza dell'utente. Se si naviga nel sito tramite 3G, i blocchi possono eseguire il rendering automatico in una modalità di connessione lenta per visualizzare immagini di bassa qualità e saltare il caricamento dei video. Oppure può migliorare il layout, ad esempio offrendo di mostrare una galleria di immagini con un clic in qualsiasi punto della pagina Web e non solo nel punto in cui è stata incorporata nell'articolo.

Queste esperienze possono essere ottenute separando il contenuto dalla forma, il che implica che la presentazione e il significato del contenuto sono disaccoppiati e solo il significato viene salvato nel database, rendendo i dati di presentazione secondari e salvandoli in un altro posto. L'HTML semantico è un'espressione di questo concetto: dovremmo sempre usare <em> che implica il significato, invece di <i> che è una forma di presentazione (per far visualizzare il carattere in corsivo), perché allora questo contenuto sarà disponibile per altri mezzi, come la voce (Alexa non può leggere in corsivo, ma può aggiungere enfasi alla frase).

Ottenere una separazione completa del contenuto dalla forma è molto difficile poiché il codice di presentazione verrà spesso aggiunto all'interno del blocco, tramite il markup HTML (l'aggiunta della classe "pull-right" implica già la presentazione). Tuttavia, l'architettura del sito utilizzando i blocchi aiuta già a raggiungere un certo livello di separazione a livello di layout. Inoltre, i blocchi creati per fare solo una cosa, e farla molto bene, possono utilizzare un corretto HTML semantico, avere una buona separazione delle preoccupazioni nella propria architettura riguardo a HTML, JS e CSS (in modo che il loro porting su altre piattaforme può richiedere solo uno sforzo minimo,) ed essere accessibile, almeno a livello di componente.

Nota : una regola generale: più un componente è inclusivo, più è preparato per i mezzi ancora da inventare.

Sfortunatamente, Gutenberg non è stato progettato con questo scopo in mente, quindi i blocchi contengono molto markup HTML anche per la presentazione. Ad esempio, un blocco immagine di un'immagine esterna ha, come significato, solo l'URL dell'immagine, la descrizione alternativa e la didascalia (ed eventualmente anche la larghezza e l'altezza); dopo aver creato un blocco immagine, il seguente blocco di codice è stato salvato nel DB (la classe aligncenter è per la presentazione e il markup <div class="wp-block-image" /> sarebbe completamente ridondante se si memorizza solo il significato):

 <!-- 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 -->

Inoltre, i blocchi vengono salvati all'interno del contenuto del post (che è un grande blob HTML) invece di avere ciascuno una propria voce nel database. Tuttavia, i blocchi riutilizzabili (chiamati anche blocchi globali) hanno la loro voce, il che mi fa temere che gli sviluppatori possano convertire blocchi standard in blocchi riutilizzabili solo per un rapido hack per accedervi direttamente nel DB.

Allo stesso modo, sono preoccupato che, se non adeguatamente progettati, i blocchi possano persino causare il caos nei nostri siti. Ad esempio, gli sviluppatori ignari possono ignorare la regola del minimo potere, utilizzando JavaScript non solo per la funzionalità ma anche per CSS e markup. Inoltre, la funzionalità di rendering lato server (SSR) di Gutenberg non è isomorfa (cioè non consente a una singola base di codice di produrre l'output sia per il codice client che per quello lato server), quindi i blocchi dinamici devono implementare la funzione per generare il codice HTML anche come PHP in modo da offrire un miglioramento progressivo (senza il quale il sito è inaccessibile durante il caricamento iniziale).

In sintesi, i blocchi sono un passo nella giusta direzione per rendere disponibili i contenuti di WordPress su qualsiasi formato e per qualsiasi supporto, ma non sono una soluzione definitiva, quindi c'è ancora molto lavoro da fare.

Prestazione

Le prestazioni contano. I siti più veloci portano a utenti più felici, il che porta a migliori tassi di conversione. Il team di Etsy, ad esempio, propone nuove funzionalità, per quanto interessanti possano essere, se queste fanno sì che il tempo di caricamento del sito superi una soglia critica (consiglio di guardare il discorso di Allison McKnight su Building Performance for the Long Term e diapositive), mentre il team di Twitter ha riprogettato il proprio sito diversi anni fa per supportare il rendering lato server in modo da mostrare i contenuti il ​​prima possibile e implementa continuamente molte piccole modifiche che si sommano per offrire un'esperienza utente veloce.

Essendo JavaScript così attraente per gli sviluppatori, non hanno alcun vincolo sul loro utilizzo, il che è un vero problema: JavaScript è molto costoso in termini di prestazioni e dovrebbe essere usato con molta attenzione.

Allo stato attuale, Gutenberg è tutt'altro che ottimale: mentre la creazione di un post con il vecchio editor (per il quale è necessario installare l'editor classico) richiede il caricamento di circa 1,4 MB di JavaScript, Gutenberg carica circa 3,5 MB di JavaScript, solo per le sue funzioni di base esperienza (ovvero senza installare alcun blocco aggiuntivo):

Ciò significa che, allo stato attuale, 3,5 MB è la linea di base e le dimensioni di caricamento aumenteranno solo da lì man mano che l'amministratore del sito installa più blocchi. Come si è visto in un recente articolo su Smashing Magazine, la creazione di un blocco testimonianze richiedeva 150 KB di JavaScript minimizzato. Quanti blocchi richiederà un sito standard? Quanti MB di JavaScript dovrà scaricare un sito medio?

Le implicazioni sono diverse: per prima cosa, un sito pesante è fuori dalla portata del prossimo miliardo di utenti, che hanno accesso principalmente su connessioni lente e che acquistano piani dati che rappresentano una fetta significativa del loro stipendio. Per loro ogni MB di dati fa la differenza: inviare messaggi Whatsapp è conveniente, scaricare diversi MB di script solo per caricare un sito no.

È vero che l'utente del sito web non avrà bisogno di interagire con Gutenberg, poiché Gutenberg serve semplicemente per costruire il sito, non per usarlo: Gutenberg è un editor di back-end, non un editor di front-end (e potrebbe non essere — almeno come parte del core di WordPress). Tuttavia, i creatori di contenuti saranno penalizzati e sono già un bersaglio considerevole. Inoltre (come ho affermato in precedenza), gli utenti potrebbero finire per essere penalizzati anche da blocchi dinamici, che possono creare il loro markup tramite JavaScript lato client anziché PHP lato server.

C'è anche il problema del rigonfiamento dovuto alla funzionalità duplicata aggiunta da plug-in di terze parti. Ai vecchi tempi, un sito WordPress potrebbe aver caricato diverse versioni di jQuery, il che era relativamente facile da risolvere. Al giorno d'oggi, c'è una vasta gamma di librerie open source tra cui scegliere per implementare una funzionalità necessaria (trascinamento della selezione, calendari, componenti a selezione multipla, caroselli, ecc.), quindi molto probabilmente un sito con dozzine di blocchi di terze parti avrà la stessa funzionalità implementata da diverse librerie, creando inutili rigonfiamenti. Inoltre, c'è un po' di rigonfiamento aggiunto allo stesso Gutenberg: poiché i blocchi sono registrati nel frontend, l'annullamento della registrazione di un blocco già registrato viene eseguito caricando uno script aggiuntivo. A mio avviso, questa è una delle maggiori sfide per i contributori di Gutenberg: mettere in atto un processo snello che consenta a chiunque (non solo agli sviluppatori esperti con Webpack) di rimuovere le librerie indesiderate e impacchettare solo l'insieme minimo di risorse necessarie per l'applicazione .

Infine, menziono ancora una volta che Gutenberg supporta il rendering lato server, ma poiché potrebbe non essere facile da mantenere, gli sviluppatori potrebbero essere tentati di non fare affidamento su di esso. In questo caso, c'è il costo di ulteriori roundtrip necessari per ottenere i dati dagli endpoint REST, solo per eseguire il rendering del layout, durante i quali l'utente sarà in attesa.

A mio avviso, le prestazioni saranno una delle maggiori sfide per Gutenberg, quella che potrebbe fare o rompere in termini di adozione diffusa, e c'è ancora molto lavoro da fare, principalmente mirato alla fase successiva quando Gutenberg diventerà un sito costruttore.

Standard Web

Come accennato in precedenza, Gutenberg astrae React per fornire un approccio indipendente dal framework ai blocchi costitutivi che, se implementati correttamente, possono evitare che WordPress venga bloccato su React. La community di WordPress è cauta nell'unire qualsiasi framework JavaScript nel core di WordPress, in gran parte perché Backbone.js, non molto tempo dopo essere stato aggiunto al core di WordPress, ha visto un forte calo di popolarità e, oltre ad alimentare il Media Manager, non sono state realizzate molte funzionalità con esso. Anche se React è la libreria JavaScript più popolare in questo momento, non c'è motivo di credere che sarà sempre così (come può attestare il disfacimento di jQuery), e WordPress deve essere preparato per quando finalmente arriverà quel giorno (che, data la velocità ritmo della tecnologia, potrebbe avvenire prima del previsto).

Il modo migliore per evitare di essere bloccati su qualsiasi libreria è attraverso standard web e, più specificamente in questo caso, l'implementazione di blocchi tramite componenti web. I componenti Web sono componenti fortemente incapsulati che operano con le API del browser, quindi non richiedono alcuna libreria JavaScript con cui lavorare. Tuttavia, possono essere implementati tramite qualsiasi framework JavaScript lato client.

Anche se React non fornisce ancora una perfetta integrazione con i componenti web, alla fine (o meglio si spera) lo farà. Come spiegato nella documentazione di React, i componenti Web e i componenti React possono lavorare insieme a:

“React e Web Components sono costruiti per risolvere diversi problemi. I componenti Web forniscono un forte incapsulamento per i componenti riutilizzabili, mentre React fornisce una libreria dichiarativa che mantiene il DOM sincronizzato con i tuoi dati. I due obiettivi sono complementari. Come sviluppatore, sei libero di utilizzare React nei tuoi componenti Web, o di utilizzare i componenti Web in React, o entrambi."

Ad oggi, le prospettive di questa situazione in atto non sembrano molto promettenti: non sono stato in grado di trovare alcun tutorial per i blocchi di costruzione con i componenti web. Credo che la comunità dovrebbe concentrare alcuni sforzi verso questa causa, incoraggiando gli sviluppatori a iniziare a costruire blocchi utilizzando i componenti Web, e prima è meglio è, dal momento che Gutenberg ci costringe comunque ad apprendere nuove tecnologie, in questo momento. È un'opportunità per stabilire una solida base con gli standard web, fin dall'inizio.

Interoperabilità tra siti, omogeneizzazione dei siti

Un blocco è un'entità più piccola di un tema o di un plug-in, quindi alla fine i blocchi saranno accessibili da soli e acquisiti attraverso i mercati dei blocchi appena creati. Molto probabilmente ci sarà inizialmente un'esplosione di blocchi cambriani poiché molti attori dell'ecosistema si affrettano a essere i primi a commercializzare le proprie soluzioni, portando a medio e lungo termine verso il consolidamento di quelle di maggior successo.

Una volta che la polvere si sarà depositata, alcuni blocchi si distingueranno e diventeranno i vincitori, ottenendo la maggior parte del mercato sulle loro categorie specifiche. Se/quando ciò accadrà sarà motivo di preoccupazione e giubilo: preoccupazione per una nuova ondata di omogeneizzazione del web in atto (come è successo con Bootstrap), poiché i siti che utilizzano gli stessi componenti potrebbero ritrovarsi con lo stesso aspetto grafico , un tripudio per una maggiore interoperabilità tra i siti derivante dal fare affidamento sugli stessi componenti e sulle stesse API, che può aprire le porte a nuove opportunità.

Sono particolarmente entusiasta di espandere l'interoperabilità tra i siti. È un'area che potrebbe, a lungo termine, annullare regni come quello di Facebook: invece di fare affidamento su un gateway monopolistico per la condivisione delle informazioni, i siti con comunità diverse possono facilmente condividere i dati tra loro, direttamente. Questo non è un concetto nuovo: il movimento IndieWeb lavora da tempo per consentire a chiunque di possedere i propri dati sui propri server, facendo in modo che i siti Web parlino tra loro attraverso microformati. Ad esempio, il loro standard Web Webmention consente a due siti di avere una conversazione, in cui ogni commento e risposta è archiviato in entrambi, e Micro.blog offre una sorta di Twitter ma basato sul Web aperto, in cui i post sulla sequenza temporale dell'utente vengono raccolti dai feed RSS e JSON dei siti a cui si è iscritti. Questi sforzi sono meravigliosi, ma ancora di scarso impatto, dal momento che è necessario un certo livello di competenza tecnologica per farne parte. L'architettura basata sui componenti di Gutenberg può potenzialmente produrre un impatto molto più ampio: i blocchi popolari possono consentire a decine di siti WordPress di comunicare tra loro, consentendo alla fine fino al 30% di tutti i siti sul Web di far parte di una rete decentralizzata e ad accoppiamento libero .

Questa zona avrà bisogno di molto lavoro, però, prima di essere praticabile. Non credo che gli endpoint REST predefiniti siano la migliore interfaccia di comunicazione poiché non sono stati concepiti per questo scopo (la gente di micro.blog ha proposto una soluzione migliore attraverso la loro interfaccia JSON, che si basa sulla specifica RSS). Inoltre, REST stesso viene reso obsoleto da GraphQL, quindi non riporre grandi speranze su di esso a lungo termine. Sono anche coinvolto nella ricerca di un modo migliore, per il quale sto attualmente lavorando su un diverso tipo di API, che può recuperare tutti i dati richiesti in una sola richiesta e supporta l'estendibilità attraverso un'architettura basata su componenti.

Mi aspetto inoltre che l'integrazione con i servizi cloud sia più importante, poiché i provider possono rilasciare i propri blocchi per interagire con i propri servizi. Poiché un componente è un'unità autonoma, semplicemente trascinando il blocco nella pagina fa già tutto il lavoro dal punto di vista dell'utente, rendendo molto semplice la creazione di siti Web potenti con poca o nessuna conoscenza. Ad esempio, un provider di archiviazione di immagini come Cloudinary potrebbe rilasciare un blocco che ritaglia automaticamente l'immagine in base al viewport del dispositivo o richiede l'immagine come WebP se supportata o altri casi d'uso.

In sintesi, il consolidamento del mercato dei blocchi può portare all'omogeneizzazione del modo in cui appare e si sente, il che sarebbe un evento deplorevole e dovrebbe essere evitato, e potenti capacità riguardanti l'interoperabilità e la condivisione dei dati tra i siti e l'integrazione con i servizi cloud.

Integrazione con le librerie di pattern

Una libreria di modelli è una raccolta di elementi di progettazione dell'interfaccia utente, ognuno di essi spesso composto da frammenti di HTML, JS e CSS. Un blocco è un componente autonomo, spesso costituito da bit di HTML, JS e CSS. Quindi i blocchi sono evidentemente adatti per essere documentati/costruiti con librerie di modelli. Avere blocchi che spediscono le loro librerie di modelli sarebbe un ottimo affare poiché potrebbe consentire ai team di non iniziare a implementare la libreria di modelli del sito solo a livello di sito, ma come aggregazione e perfezionamento delle mini librerie di modelli da tutti i blocchi richiesti.

Credo che in questo caso avvenga qualcosa di simile al processo di razionalizzazione per la produzione di pacchetti JavaScript bloatless che ho menzionato in precedenza, ma per quanto riguarda UI/UX/Documentazione. Sarebbe sia una sfida che un'opportunità per i contributori di Gutenberg mettere in atto un processo che renda facile per gli sviluppatori di blocchi creare librerie di modelli per i loro blocchi che, se aggregati tutti insieme, possono risultare in una libreria di modelli coerente per il sito. Ben implementata, tale funzionalità potrebbe ridurre i costi dei cantieri dal punto di vista della documentazione/manutenzione.

Cosa diventerà di WordPress?

Gutenberg renderà sicuramente più attraenti i siti web, anche se a costo di un livello di competenza richiesto che non tutti saranno in grado di gestire. A lungo termine, ciò può portare a una maggiore qualità, a una minore quantità. Venendo dalla massima di WordPress di "Democratizzare l'editoria", questo potrebbe diventare un problema.

Sono entusiasta di Gutenberg, ma più come concetto di architettura basata su componenti, rispetto all'implementazione basata su React. In termini generali, sono d'accordo con quanto affermato da Matt Mullenweg durante il WordCamp Europe 2018 per giustificare Gutenberg:

"Le fondamenta di WordPress che ora ci sono servite bene per quindici anni non dureranno per i prossimi quindici."

Tuttavia, credo anche che il WordPress di quindici anni nel futuro potrebbe finire per essere completamente diverso da quello che conosciamo oggi. Mi chiedo se WordPress finirà per essere principalmente l'editor basato sul client, e non molto di più: l'iniziativa di integrare Gutenberg in Drupal, con l'obiettivo di far diventare Gutenberg l'editor del web aperto, ufficializzerà WordPress come un CMS headless operativo tramite endpoint REST. Questo è di per sé un buon sviluppo, ma renderà WordPress il back-end superfluo: se qualsiasi altra piattaforma di back-end fornisce funzionalità migliori, non c'è più motivo di attenersi al back-end di WordPress. Dopotutto, Gutenberg lato client sarà in grado di lavorare con qualsiasi di loro, mentre la semplicità di creare un sito con WordPress andrà persa, livellando il campo di gioco con tutte le altre piattaforme.

In particolare, non sarei sorpreso se gli sviluppatori ritenessero che mantenere due basi di codice (una in JavaScript e una in PHP) per il rendering di blocchi dinamici sia troppo faticoso e decidessero di passare a piattaforme che supportano il rendering lato server isomorfo. Se questo scenario si verificasse effettivamente, Matt deciderebbe di spostare il backend di WordPress su Node.js?

È principalmente a causa di questo problema che oserei dire che WordPress tra 15 anni potrebbe essere un'entità molto diversa da quella che è oggi. Chi sa cosa accadrà?

Conclusione

Rendendo i componenti la nuova unità per i cantieri, l'introduzione di Gutenberg sarà trasformativa in WordPress. E come per ogni cambio di paradigma, ci saranno vincitori e vinti. Diverse parti interessate considereranno Gutenberg uno sviluppo positivo o negativo a seconda della propria situazione: mentre la qualità di un sito Web aumenterà, aumenterà anche il prezzo della creazione di un sito del genere assumendo sviluppatori in grado di gestirne la complessità, rendendolo meno conveniente e meno popolare.

Sono tempi eccitanti, ma anche cruciali. D'ora in poi, WordPress potrebbe lentamente iniziare a essere un'entità diversa da quella a cui siamo abituati e alla fine potremmo dover pensare di nuovo a cos'è WordPress e cosa rappresenta, ancora una volta.