La discussione sulla selezione del framework JavaScript Core di WordPress continua con il contributo dei leader della comunità open source

Il canale #core-js Slack di WordPress ha ospitato questa mattina un incontro vivace e produttivo guidato da Andrew Duthie. La discussione si è concentrata meno sui confronti di framework specifici e più sul ruolo che un framework svolgerà nella creazione di interfacce basate su JavaScript per WordPress. Ai contributori si sono uniti sviluppatori e leader principali delle comunità React e Vue, ingegneri di Chrome e altre parti interessate esterne alla comunità di WordPress.

"Questa chat si concentrerà principalmente sull'identificazione dei requisiti nella creazione di funzionalità di base, sulla sovrapposizione con gli autori di plugin e temi e sui modelli per ridurre il blocco del framework", ha affermato Duthie. "Idealmente si tratta di un livello superiore rispetto al semplice dibattito sui meriti di framework specifici nel vuoto e dovrebbe essere visto come un'opportunità per collaborare tra progetti per impostare un percorso da seguire per WordPress che fornirà flessibilità e resilienza al futuro abbandono".

Duthie ha iniziato chiedendo quale ruolo dovrebbe svolgere un framework nel flusso di lavoro di uno sviluppatore WordPress e ha anche chiesto ai contributori del framework di offrire le loro prospettive sui consigli per le interfacce estensibili. Questa domanda ha fornito ai partecipanti l'opportunità di approfondire argomenti come il supporto per i componenti Web, l'interoperabilità dei blocchi indipendente dal framework per Gutenberg e come ciò potrebbe influenzare l'ecosistema dei plug-in di WordPress.

"Sono un po' in disaccordo con l'idea che qualsiasi core (in questo caso Gutenberg) utilizzato per alimentare alcune delle complessità della creazione di un'app stateful sarà lo standard de facto per lo sviluppo di plug-in", ha affermato Matias Ventura, ingegnere di Gutenberg. "Il framework effettivo qui, in termini generali, sarà ciò che WordPress espone e le API".

Con un approccio indipendente dal framework alla creazione di Gutenblocks, la libreria su cui il core decide di costruire non deve diventare lo standard de facto per gli sviluppatori di plugin, ma molti al di fuori del team di Gutenberg credono che inevitabilmente finirà in questo modo nella pratica. Ci sono interi team di ingegneri in attesa di questa decisione che si impegnano ad adottare qualsiasi framework su cui WordPress scommetta.

"Per fornire una prospettiva su come la decisione di WP su un framework influisca sugli sviluppatori a valle, sono uno sviluppatore della Boston University e il nostro piano è di concentrarci su qualsiasi framework WP decida, anche se Gutenberg ha un'API completamente agnostica", ha affermato Adam Pieniazek . "Siamo principalmente un negozio di WP (~ 1.000 installazioni di WP del sito alimentano la maggior parte/molta della nostra presenza sul Web pubblico) e finiamo per creare enormi personalizzazioni in cima a WP che spesso richiedono un'immersione nel core per vedere cosa sta effettivamente accadendo in background . Mi piace Vue più di React personalmente, ma se WP decide su React, BU si concentrerà sulla creazione di competenze in React per quando dobbiamo sbirciare/debug oltre l'API. Ciò non significa che non utilizzeremo anche Vue, ma non sarà il nostro obiettivo principale".

Il feedback di Pieniazek fa eco a quello del co-fondatore di Gravity Forms Carl Hancock, il quale ha affermato che il suo team è pronto ad adottare qualsiasi libreria selezionata da WordPress.

"Le persone finiranno per adottare qualsiasi cosa utilizzi per la maggior parte del nucleo, nonostante gli arcobaleni e le farfalle che alcuni sostengono in relazione alla creazione di un livello di astrazione in modo che gli sviluppatori di plugin/tema possano usare quello che vogliono", ha detto Hancock nel #core- js channel all'inizio di questa settimana.

Molti partecipanti al di fuori della comunità di WordPress sembravano essere d'accordo con un approccio indipendente dal framework e nessuno era ansioso di imporre un unico framework a tutti gli sviluppatori che lavorano con WordPress. La preoccupazione rimanente è come funziona praticamente e se mette gli sviluppatori nella posizione confusa di utilizzare un framework sopra un framework.

"Dato che la stessa Gutenberg diventerà una piattaforma per la creazione, il miglior livello di separazione è se il framework viene utilizzato per costruire il core, ma non viene esposto come API ai block builder", ha affermato l'ingegnere AMP Paul Bakaus. "Questo dà la possibilità di sostituire la base sottostante ogni volta che è necessario."

L'ingegnere di Gutenberg Riad Benguella ha riassunto l'approccio di cui il team ha discusso:

Penso che quello che cerchiamo di comunicare sia qualcosa del tipo:

– WordPress Core utilizzerà internamente questo framework X
– Se vuoi usarlo, pensiamo che sia buono
– Se vuoi usare qualcos'altro, puoi facilmente come useresti il ​​framework scelto da Core

Benguella ha anche affermato che uno degli obiettivi di Gutenberg è "porre le basi per il modo in cui estenderemo l'interfaccia utente di WordPress in futuro". Una volta spedito, il team probabilmente punterà gli occhi su altre parti di wp-admin e le costruirà allo stesso modo.

"Se tutte le parti dell'interfaccia utente di WP possono essere estese tramite un'interfaccia standard, sia che si tratti di una semplice API 'data down, events up' o che si aspetti un WC, penso che questo separerebbe in modo netto le preoccupazioni su 'quale framework usare per il core ' vs. 'quale framework utilizzare per lo sviluppo di estensioni'", ha affermato il creatore di Vue.js Evan You.

Quando gli è stato chiesto quali fossero le sue opinioni sul fatto che React diventasse un framework principale per WordPress, il manutentore di React Dan Abromov era riluttante a sostenere che WordPress adottasse la libreria. La sua risposta ha sottolineato la necessità di avere un approccio indipendente dal framework per estendere Gutenberg e le future revisioni dell'interfaccia WP.

"Non conosco molto bene WordPress, quindi è difficile per me dire se è adatto o meno per il caso d'uso", ha detto Abramov. “In genere utilizziamo React per interfacce utente altamente interattive e scopriamo che si adatta bene alle dimensioni dell'app. Sono anche felice di rispondere a domande tecniche a riguardo. Ma penso che in generale le persone abbiano opinioni forti, ad esempio, su modelli e espressività, e non credo che forzare React su tutti sia il modo migliore".

"Anch'io mi sento allo stesso modo", ha detto Evan You. "Forzare un unico framework a tutti, indipendentemente da quale, l'IMO non è una buona idea perché è destinato ad alienare il gruppo di sviluppatori che non sono in quel framework e impone un rischio maggiore per la stabilità a lungo termine".

Abramov ha anche affermato che le persone sono già "molto amareggiate e divise" sull'argomento della selezione di un quadro. Ha anche twittato un sentimento simile prima dell'incontro.

Quando leggo discussioni (ad es. su WordPress) ho la sensazione che le persone percepiscano ogni team come ostile agli altri. È falso.

— Dan (@dan_abramov) 26 settembre 2017

Pensalo come prendersi cura di un giardino. Sei il benvenuto da noi. Anche altri giardini sono fantastici

— Dan (@dan_abramov) 26 settembre 2017

"Credo sia importante (e tecnicamente fattibile) separare 'quale framework usare per il core' e 'quale framework gli sviluppatori della community usano per le estensioni'", ha affermato Evan You.

"Sì, penso che qui ci sia un obiettivo per essere discreti su ciò che stiamo esponendo agli autori di plug-in, a condizione che le API/interfacce che esponiamo siano sufficientemente flessibili (e facili) per creare le interfacce utente e le interazioni che devono implementare, ” ha detto Andrew Duthie.

Durante l'incontro è stato discusso anche il tema del supporto dell'interoperabilità dei componenti Web per Gutenblocks.

"Anche se a questo punto meno potenti della maggior parte dei framework attuali, è probabile che diventino uno standard del W3C, assicurando che rimangano e si evolvano", ha affermato Felix Arntz. "Inoltre, una volta che il supporto del browser è completamente disponibile, c'è meno funzionalità da implementare da un vero framework costruito sopra."

Il rappresentante di Polymer.js, Justin Fagnani, ha affermato di non essere d'accordo sul fatto che siano "meno potenti" e ha notato che i componenti Web sono già uno standard del W3C.

"Penso che WP sia anche posizionato in modo unico per aiutare a portare avanti il ​​supporto per i componenti Web in modo nativo ovunque", ha affermato Darren Ethier, core dev di EventEspresso. “Quasi tutti i framework ora hanno la capacità di lavorare con le specifiche dei componenti web. È solo una questione di corretta attuazione".

Diversi partecipanti hanno fatto riferimento a custom-elements-everywhere.com, un sito che mostra i progressi dei framework JS popolari nella comunicazione di elementi personalizzati in un modo che promuove l'interoperabilità. Matias Ventura ha chiesto ai core devs di React e Vue in che modo i componenti web (e il loro futuro) si adattano a ciascun framework al momento.

"In React, abbiamo il supporto di alcuni componenti Web ma non lo abbiamo reso una grande priorità poiché i casi d'uso sembravano scarsi in passato, soprattutto perché l'aggiunta di componenti Web non aveva molto senso in un'applicazione proprietaria in cui controllare l'intero stack, ma abbiamo comunque un po' di supporto per loro e sono felice di divertirmi ad aggiungere altro, ora o in futuro", ha detto Sophie Alpert.

"A livello elevato, penso che framework come React/Vue forniscano ciò che non è realmente affrontato nei componenti Web: aggiornamenti DOM efficienti e dichiarativi che reagiscono ai cambiamenti di stato", ha affermato Evan You. “Questo è anche il motivo per cui Polymer esiste sopra il WC. Ho sempre riconosciuto il valore di WC come interfaccia di interoperabilità".

Nel complesso, i partecipanti alla riunione sono stati rispettosi, collaborativi e desiderosi di contribuire con la loro esperienza per aiutare i contributori di WordPress a trovare la strada migliore da seguire nel processo di selezione del framework. La discussione continuerà all'incontro della prossima settimana e probabilmente nei commenti di un prossimo post Make/Core che riassume l'incontro.