Questo articolo nasce in risposta alla frustrazione accumulata a seguito di una storia professionale autentica. Una di quelle accadute nei giorni più confusionari in cui potesse capitare, nel bel mezzo del mio più remunerativo lavoro mi sono trovato a lavorare con un page builder.
In fondo quando hai una miriade di cose da fare e a cui pensare capita che ti possa sfuggire quel classico: “si, ok, te lo aggiusto io dopo, tanto si tratta di rendere un bordo trasparente in CSS, massimo un minuto e l’ho sistemato!”.
Male!
Fai che questo non accada mai e soprattutto assicurati di non dover mai mettere mano ad un sito creato completamente con l’uso del visual composer.
All’interno di questo articolo troverai le spiegazioni dettagliate per le quali non ritengo utile e tantomeno professionale richiedere l’aiuto di strumenti come i vari page builder o del famosissimo Visual Composer; ovvero di quelle soluzioni che promettono un “semplice” drag’n drop per la creazione di un sito in WordPress.
Alcune delle critiche mosse in questo articolo fanno riferimento a vecchie versioni del Visual Composer, questo non significa che i concetti presentati non siano comunque validi.
Oltre a questo troverai anche proposte e soluzioni mirate a permetterti di sostituire questi elementi e iniziare ad essere un vero sviluppatore WordPress, uno di quelli seri insomma 😉
Facciamo le dovute premesse
Iniziamo con il dire due cose che a molti potranno sembrare banali ma che ho capito non esserlo dopo averle discusse con parecchi clienti.
La prima cosa da fissare bene in mente è che se vi fanno un sito usando un page builder, beh, il livello di professonalità, di conoscenza del web e di WordPress nello specifico è veramente bassino.
Questo perchè nessun professionista che si trovi a creare un design da zero parte già da un canvas zeppo di funzionalità, widget, framework e ammennicoli vari che si portano inevitabilmente dietro i page builder grafici.
Piuttosto, un vero professionista studia le esigenze del cliente e costruisce al meglio il MINIMO PRODOTTO OTTIMIZZATO (Minimum Viable Product o MVP), concentrandosi sugli aspetti chiave del progetto.
Questo è un metodo di validazione dell’idea che cerchiamo di seguire sempre più spesso e si chiama Lean Startup, mutuato da un libro, ormai famosissimo e che ti consiglio di leggere, Lean Startup di Eric Ries.
Già partire da temi premium multi-purpose per me è follia, figuratevi quando nel backend di un sito di ricette mi ritrovo il widget da inserire in una griglia da 12 elementi (ma che me ne farò mai di tutti quegli elementi in linea?!?!) per mostrare grafici a barre?! Probabilmente qualcuno un’utilità ce la troverà pure, io sinceramente preferisco ottimizzare le risorse finchè non sento la necessità di andare oltre.
Altro elemento di disturbo è quello di impilare sempre più risorse una sull’altra.
In informatica parliamo di stack, ovvero di veri e propri piani sui quali si costruisce un’applicazione. Se contiamo quelli del nostro sito già possiamo notare che il nostro tema è costruito con le funzioni di WordPress che a sua volta poggia su LAMP (OS Linux, Server Apache, DB MySQL e linguaggio PHP).
Normalmente il nostro tema avrà, a sua volta, almeno 3 dipendenze tra framework CSS e JS, questo senza considerare la probabile componente custom.
Ricorda sempre che un page builder porta con se ulteriori dipendenze e il tuo tema ne diventerà schiavo; parliamo di aggiornamenti continui, aumento dei possibili bug e dei problemi di compatibilità tra tutte queste tecnologie che state mescolando su più piani diversi.
Ora magari stai pensando: “Si ma anche se il tema lo costruisco io sarò comunque dipendente da qualche script o libreria”.
Verissimo.
La differenza è tutta nel fatto che puoi scegliere tecnologie e framework molto meno dispersivi e ottimizzati se messi a confronto con un tema costruito su un page builder qualsiasi. A onor del vero devo riconoscere gli sforzi di Beaver Builder e di Divi in tal senso, nel restare piuttosto aderenti alle logiche del framework WordPress ma al tempo stesso ne complicano le dipendenze.
Con quest’ultima dichiarazione però, non voglio invalidare tutto il discorso precedente ma semplicemente sottolineare che esiste un modo per farlo meglio ed è disponibile a chi non ha conoscenza di programmazione ed esigenze piuttosto semplici.
Non condanno infatti, chi usa questi strumenti per scopi personali, senza pretesa di perfezione alcuna. Io condanno chi li usa come strumento professionale per costruire siti web da rivendere ai propri clienti.
Avete visto quante librerie e codice JavaScript viene caricato nel backend solo per permettervi tutto quell’inutile drag’n drop e anteprime live?
Prova a immaginare cosa succede nel momento in cui la tua pagina inizia a riempirsi di elementi multimediali, blocchi di testo, call to action (CTA) e animazioni.
Se non hai mai avuto il privilegio di provare allora te lo dico io, solo scrollando la pagina dell’editor si può provare la sensazione di cosa era Internet negli anni ’90, la lentezza e la sensaizione di bloat che invade pesantemente l’esperienza utente in ogni suo momento.
Oggi esistono strumenti che permettono di avere una vista front end sul lavoro svolto, ma vienimi a dire che è comodo spostare l’ultimo blocco in cima all’articolo semplicemente tracinandolo! 😀
Il fallimento dell’esperienza utente
Partiamo dall’assunto che sento spesso quando si parla di page builder:
“Sono facili da usare e ci puoi fare qualsiasi design, li trovi in tanti temi premium e mi tolgo dalle scatole di dover gestire il cliente pazzo che vuole farsi le modifiche da solo.”
Falso.
Falsissimo come la fantascienza di basso livello, alla stregua di Megaforce ma girato peggio.
Ora vi spiegherò perché l’assunto è profondamente sbagliato smontandolo parte per parte.
Primo mito: i Visual Composer sono facili da usare
Su questo punto ci si ricrede in fretta, spesso dopo i primi venti minuti passati sul software, perché nonostante tu sia un adetto ai lavori e traffichi tutti i giorni con griglie, allineamenti e padding ti accorgerai che non è poi così tutto automatico e ti ritroverai a fare largo uso dei CSS.
Molto spesso sono gli stessi page builder che mettono a disposizione un editor CSS interno ad ogni pagina che inietta codice direttamente nella sezione <head> del tuo sito, consci del fatto che nasceranno sicuramente necessità insoddisfacibili via interfaccia grafica.
Come puoi pensare che per un cliente, al quale probabilmente non interesserà nulla capire come funzioni una griglia e soprattutto mettersi ad imparare uno strumento per costruire strutture e inserire nuovi contenuto, questa rappresenti la persona adatta.
L’unico caso in cui penserei di fare un piacere al committente integrando un page builder, sarebbe solo il caso in cui abbia già tutto un sito basato su quello e che lo conosca così a menadito che è quasi lui a spiegare a me come funziona.
Giuro, sia io che il mio collega Andrea, abbiamo sbattuto la testa su siti fatti con i più disparati visual composer e ci siamo ritrovati sempre a dover imparare la loro logica, quasi ripartendo da zero, e abbiamo sprecato tanto tempo a imparare una cosa che diverrà probabilmente obsoleta e inutile in pochissimo tempo.
[clickToTweet tweet=”Spendere ore a conoscere un nuovo #pagebuilder potrebbe essere una gran perdita di tempo!” quote=”Spendere ore a conoscere un nuovo #pagebuilder potrebbe essere una gran perdita di tempo!”]
Perché non impiegare quel tempo ad imparare un minimo a programmare in WordPress combinandolo magari con Genesis o a un quasiasi starter theme?
In questo modo l’esperienza utente che vendiamo al cliente sarà veramente ben fatta e cucita addosso alle sue esigenze, diamo in mano una serie di campi e opzioni da compilare e le sue preoccupazioni saranno solamente a livello contenutistico.
Questa non è una piccola differenza e può segnare lo scarto tra un lavoro ben recepito perché usabile senza fraintendimenti e uno mal recepito perché troppo sovradimensionato.
Secondo mito: puoi fare qualsiasi design usando un Page Builder
Se non hai mai provato un preprocessore CSS come Sass o un framework CSS come Bootstrap, posso capire che creare griglie e strutture possa sembrare un compito arduo, soprattutto se queste devono essere responsive e accogliere ogni tipo di elemento possibile.
Tuttavia non è tramite un page builder che si ottiene la libertà necessaria a creare design specifici perché parecchio lavoro è già fatto e si deve procedere solitamente al contrario. Smontando quello che ci si trova stilato e scrivendo la propria parte custom che si adatti a questa struttura.
Dov’è l’applicazione della teoria del foglio bianco?
Dove sta la libertà?
Per disegnare un animale puoi tranqullamente partire comprando il libro della savana da colorare all’autogrill, ma poi ti limiterai a scegliere tra i soli soggetti che sono stampati lì sopra, mentre sicuramente il tuo animale preferito sarà il procione 🙂
La conoscenza di HTML e CSS devono essere le basi di un web designer e anche la conoscenza della logica del templating (riusare dei blocchi o intere strutture di pagina per contenuti simili o affini), credere di trovare la libertà creativa data dalla conoscenza di questi due linguaggi in un page builder che invece cerca di “contenerne” l’uso è una pia illusione.
Pensa che neanche il linguaggio CSS alla base dei visual composer è perfetto e per questo in rete si trovano centinaia di CSS tricks/hacks che permettono di creare gli effetti più svariati. Con una ricerca su Google potrai migliorare le tue conoscenze e apprendere nuovi modi di realizzare design sorprendenti soltanto con i CSS o ancora meglio con Sass e qualche suo mixin.
Se questo non bastasse, credi che usare un page builder offra la stessa “user/developer base”, lo stesso ritmo di aggiornamenti, la stessa quantità di materiale formativo e le stesse fonti d’ispirazione che puoi trovare online?
Ti rispondo subito.
No.
Terzo mito: tanti temi premium li integrano
Questa parte è impossibile da smentire, per ovvie ragioni. È verissimo, basta fare un giro sul più grande marketpalce di temi al mondo per accorgersene. Non smentirò questa affermazione, ma ti chiedo semplicemente di spiegarmi come mai piacciono a tanti autori di temi.
Dato che non posso avere adesso la tua opinione, anche se potrai inserirla nei commenti, ti dirò come la vedo io.
Dal mio punto di vista quando si è costretti a puntare sui volumi di vendita (caso molto comune quando vendiamo temi all’interno di un marketplace), per guadagnare si passa a un modello di produzione seriale e general purpose. Quando si vende un tema per 50 euro non ci si può stare a concentrare su come mettere meglio in mostra i contenuti per determinate categorie e tipologie di sito, meglio scaricare la responsabilità del design sul compratore.
Allora ecco che i temi passano dal contenere “di tutto di più” (WooCommerce, BuddyPress, Events Manager, Portfolio, etc etc) al contenere “più del tutto di più” (WooCommerce e relativi widget per il page builder, Event manager e relativi widget, etc etc).
Questa estrema libertà complicherà notevolmente la tua piattaforma e rallenterà la sua esecuzione perché, come detto anche precedentemente, dovrà far girare molto codice general purpose che neanche starai utilizzando.
Sei ancora sicuro che risparmierai del tempo usandone uno?
Sotto la scocca di carta c’è un motore di cristallo
La cosa più fastidiosa di questo tipo di design è che spesso si poggia su assurdi impieghi di shortcode misti a griglie CSS del tutto alieni alle logiche comuni e alle buone pratiche.
In questa sezione critichiamo nello specifico un comportamento di un vecchio plugin, anche se può sembrare un esempio estremo perché oggi abbiamo strumenti migliori, in certi casi viviamo ancora queste situazioni.
Basta passare alla visualizzazione classica dell’editor di WordPress per vedere i pasticci che lasciano nel nostro contenuto. Pensa con queste premesse cosa può diventare il database e che esperienza drammatica porta un cambio di tema.
Se a questo aggiungi anche che hai usato il builder per fare delle personalizzazioni più legate al tema che al plugin, capisci da solo perché considero questo approccio un lock-in piuttosto che una liberazione.
Uno dei più famosi page builder in commercio è addirittura incompatibile con la sua versione precedente, attualmente piena di bug e lasciata a morire senza vero supporto, causando non pochi mal di testa a chi aveva comprato temi ormai obsoleti e che si vede costretta a inventare non so cosa per migrare tutto il proprio contenuto.
Se hai sentito parlare di Web Semantico sarai tra quelli che in questo momento si stanno chiedendo come faccia un sistema del genere a gestire correttamente i vari tag HTML5 e sopratutto l’aspetto SEO di una pagina con tutti i metadati al posto giusto.
Io me lo sono chiesto e sono andato a cercare nel codice, da buon smanettone, la presenza di qualche segnale incoraggiante.
A differenza di alcuni temi che si comportanto come framework e che fanno un buon lavoro di costruzione semantica come il già citato Genesis Framework, i temi che integrano i page builder risultano meno specifici e non ottimizzati.
Dimentica anche tutto ciò che hai imparato sulla gerarchia del DOM perché nel mondo dei page builder tutto è annidabile dentro tutto e la semantica è definita non solo dalla bravura di chi ci ha costruito il tema, ma sopratutto dall’utente finale che ignorando questi temi non potrà fare altro che pasticci…
Vedere nel tema il nome del visual composer con cui ti sei trovato bene la volta precedente non è sinonimo di garanzia, neanche se accompagnato dalla dicitura “SEO Optimized”, perché compreso nel pacchetto dell’utente finale c’è anche la possibilità di corrompere tutta l’ottimizzazione con un paio di drag’n drop di troppo nella pagina sbagliata.
Una <section> per il menù? Forse era meglio usare un elemento <nav>! Per questo visual builder il web semantico si ferma qui.
Conclusioni
Ora vorrei uscire da questi scenari apocalittici e rientrare nel più comune seminato di tutti i giorni, cercando di capire se conviene come professionista legarsi ad uno di questi software.
Ovviamente la mia risposta la conosci già, ma ho visto con i miei occhi “colleghi” vendere siti realizzati in questo modo e voglio darti un consiglio spassionato: se vuoi che i clienti tornino per pagarti altri lavori e non per chiederti “come si fa a infilare il player di SoundCloud che non è disponibile nel menù”.
Studia qualche framework serio basato sul PHP anzichè affidarti al drag’n drop.
Nel mare di Internet, dove regna l’improvvisazione, il professionista si distingue per l’esperienza d’uso che è in grado di proporre al proprio cliente.
Lo sforzo in più mettiamocelo volentieri.
E tu? Hai mai provato un page builder? Pensi che sbagli o semplicemente vuoi darmi dei feedback?
Sarò felice di risponderti nel form di commenti più in basso!
Ci si legge a presto da queste parti.
Articolo eccellente! Provengo da altri linguaggi di programmazione e da poco sto approcciando ai linguaggi web ma, concordo con te che il codice che esce da un CASE non rispettoso del motore (nel nostro caso WP), come potrebbe essere un visual composer, è molto spesso ampolloso, ridondante e… naturalmente poco flessibile.
Grazie mille per i complimenti Marilisa, a volte la via facile attrae di più.
Concordo a pieno con te, un professionista deve sapere che non si possono sacrificere certi aspetti in cambio di interfacce DragAndDrop.
Ciao Eugenio, con questo articolo mi hai colpita e affondata =)
Purtroppo sono una di quelle persone che cercano sempre degli strumenti per rendere la composizione della pagina più semplice e utilizzo spessissimo il visual composer per wp.
Dobbiamo ammettere però che poter inserire alcune immagini o altri elementi interattivi con pochi click è davvero molto utile e purtroppo anche alcuni clienti iniziano a chiedere questo genere di strumenti per poter “gestire” i contenuti del sito.
Per uscire da questa mia brutta dipendenza dai visual composer, cosa mi consiglieresti?
Mi farebbe davvero molto piacere scambiare qualche opinione con te (approposito, quando verranno completati i corsi su Wp presenti nella scuola per sviluppatori?)
Aspetto con ansia una tua reply
ciao
Silvia =)
Ciao Silvia, intanto rispondo io al posto di Eugenio che sicuramente verrà a breve ad aggiungere la sua opinione. Partiamo subito parlando del corso Apprendi il PHP con WordPress del quale mi sento moolto responsabile.
Sto portando avanti il progetto proprio in questi giorni e desidero concluderlo entro metà mese, ti assicuro che il corso sta diventando sempre più completo e non sto passando il tempo a dormire. Allo stesso tempo questo tipo di corso non ti permetterà di creare i tuoi temi e modificare tutto quello che desideri di una pagina generata da WordPress (questo sarà trattato maggiormente su un altro corso), ma con le conoscenze presenti nel corso e quelle di HTML e CSS sarai in grado di modificare gran parte delle implementazioni richieste.
Per quanto riguarda invece il discorso su “che cosa dare al cliente” diciamo che qua dobbiamo aprire un sacco di parentesi e anche reindirizzare la discussione su altri aspetti. Comprendo la difficoltà di farlo capire ma, in fin dei conti, chi è il cliente per permettersi di modificare un layout studiato per tale scopo? Perché dovrebbe utilizzare colori, forme e strutture che non sono naturali del tipo di pagina?
Spero tu capisca che queste domande vogliono essere provocatorie non tanto per te ma perché anche noi lottiamo quotidianamente su questi aspetti e facciamo una grande fatica a far comprendere questi aspetti ai nostri clienti. Se qualcuno ci chiama per un determinato lavoro è perché desidera i nostri servizi e le nostre competenze, se va a modificare le strutture che abbiamo impostato perché mai ha bisogno di noi?
All’interno dei nostri corsi io porto sempre l’esempio: ma perché le persone non si mettono a dare consigli a un dottore mentre nel nostro lavoro sono tutti web designer ed esperti di UX?
La risposta principale e maggiormente condivisa è quella che l’errore è nostro e che dobbiamo imparare a descrivere meglio il valore aggiunto che il nostro cliente otterrà lavorando con noi piuttosto che con il cugino. Ripeto, non voglio risultarti antepatico con questa mia espressività e spero che tu non ti arrabbi con me per quanto detto.
Se vuoi un consiglio spassionato, noi lavoriamo con la libreria CMB2 che permette di creare delle pagine di backend completamente personalizzate per il tipo di dato che deve essere inserito. Per esempio, se un mio cliente ha bisogno di un CPT ricetta noi gli creiamo tutti i campi che ci richiede e solo quelli, se vuoi aggiungere banner o altre immagini potrà utilizzare il classico editor presente in WordPress ma niente di più.
Allo stesso tempo ci sono clienti un po’ più “duri” ai quali, se proprio non possiamo fare a meno di evitarli o a convincerli, gli proproniamo l’acquisto di Divi (come diceva lo stesso Eugenio) e di utilizzare quello solo per le landing page di cui avrà bisogno per promuovere determinati servizi o prodotti.
Torneremo sicuramente a parlare di questi argomenti ma intanto spero di averti fatto capire che usare questi strumenti per qualsiasi pagina di un sito web è un problema sia SEO che di prestazioni; ma se siamo in grado di limitare il loro utilizzo per pagine specifiche allora forse si può sempre salvare qualcosa.
Non mi odiare, ma anzi, continua pure ad arricchire questa conversazione che sono sicuro possono nascere degli spunti interessanti 🙂
Ciao Andrea e grazie per la risposta. Devo dire che mi stai facendo riflettere tanto sugli errori che commetto con i clienti e anche nell’approccio con wordpress. Forse bisognerebbe parlarne ancora tanto per evitare di lavorar male e proporre anche strumenti che forse sono superflui anche al cliente finale.
Ora rimango in fase di riflessione ma non mancheranno altri miei interventi
Grazie ancora
Silvia
Ciao di nuovo Silvia e grazie per non esserti arrabbiata con me 😀
Riconosco che gli aspetti trattati sono molti e richiedono una riflessione, ricorda che noi siamo sempre qua o su skillsAndMore per aiutarti a chiarire i tuoi dubbi quindi non esitare a riproporre i tuoi dubbi perché siamo sempre pronti a nuovi confronti.
Buon proseguimento e a presto,
Andrea
Salve,
questo articolo ha colpito anche me, purtroppo utilizzo page builder per i siti i cui contenuti saranno gestiti dal cliente, tipo creazioni di nuove pagine. Se io utilizzo un sistema griglie, dove in una pagina wordpress devo scrivere codice html (div) per richiamare e varie classi, per il cliente che deve aggiungere una nuova pagina diventa difficile.
Cosa consigliate in questo caso ?
Ciao James,
noi utilizziamo con immenso piacere la libreria CMB2 che ci permette di creare delle aree ad hoc per i nostri clienti per l’inserimento di determinate informazioni che andranno a popolare la pagina. L’uso è molto intuitivo dato che segue la logica WordPress e le modifiche da fare alle pagine riguardano soltanto l’inserimento del codice necessario per prendere le informazioni dal database.
Prova a dare una letta a questo vecchio articolo di Daniele che a breve verrà ripreso e approfondito dal nuovo blog di skillsAndMore.
Ciao! Grazie per le interessanti osservazioni condivise. Ti chiedo un grande piacere: immagina una persona che abbia buona e consolidata confidenza con CSS, ma scarsissima con HTML e nulla con PHP. Questa persona ha sempre lavorato editando con CSS i contenuti che venivano inseriti nella varie pagine tramite Visual Composer, e che quindi davano la possibilità di creare una struttura schematica dei contenuti per poi modificare qualsiasi stile tramite CSS.
Ora: sto lavorando a un progetto nel quale, giustamente, nessun tipo di composer è previsto, io sono colui che ha la responsabilità di creare i contenuti delle pagine “statiche” quali landing pages e pagine promozionali all’interno di un e-commerce.
Qual’è il metodo più veloce, facile e intuitivo per poter “ricreare” uno schema nella sezione di modifica della pagina wordpress, nel quale io possa inoltre assegnare le classi css, sulla falsa riga di ciò che VC mi permette di fare “automaticamente”. (Il tutto usando solamente l’editor base di wordpress o comunque con aggiunte che non facciano storcere il naso ai bravissimi tecnici che stanno seguendo l’infrastruttura del sito).
E’ cruciale per me, spero possiate aiutarmi.
Ciao Eugenio,
la via più semplice che conosco sarebbe quella di utilizzare un plugin come ACF che permette di creare delle aree di inserimento contenuto all’interno di un editor WordPress in modo da aiutarti maggiormente nella creazione delle varie sezioni.
Ovviamente dovrai chiedere agli sviluppatori di integrare i nuovi campi all’interno della pagina dedicata, ma a parte questo ACF offre un’intuitiva soluzione per andare a creare i campi che desideri e magari ripeterli. Sicuramente non avrai un feedback per il look&feel come viene offerto da VC ma allo stesso tempo avrai pieno controllo sul codice generato e nella semantica delle tue pagine.
Spero di averti aiutato e non esitare a continuare questa interessante conversazione.
Fantastico articolo che ricalca in pieno la mia filosofia. Ho abbandonato i temi da marketplace quasi 10 anni fa e già allora iniziavano a comprendere i primi builder, piano piano mi sono costruito le competenze e creato un mio flusso di lavoro basato su sage (ex roots roots.io) adottando la filosofia che se posso evitare di installare un plugin scrivendo facilmente il codice preferisco questa seconda opzione (ovviamente non mi metto a riscrivermi uno slider o un sistema di traduzione per le lingue). Temi pronti builder etc limitano tantissimo e in caso di problemi sono solo malditesta. Preferisco sapere esattamente dove ho messo cosa e dare al cliente un tema costruito esattamente sulle sue esigenze con solo le librerie che gli servono e ottimizzate in file unici per ridurre al minimo le chiamate al server…
Grande Davide questa è proprio la filosofia che cerchiamo di condividere! Siate curiosi! Se un piccolo codice risolve il problema usate/cercate quello al posto di spendere delle ore a provare diversi plugin che oltre la soluzione portano anche un sacco di spazzatura!
Nella nostra agency abbiamo optato per Genesis come framework di partenza e anche se i child che offrono sono molto buoni capita spesso di usare soltanto qualche spunto di codice da implementare nel child che sviluppiamo da zero.
A presto!
I veri sviluppatori non usano i page builder ? E’ dura vivere sapendo di non essere un vero sviluppatore … ma sono in buona compagnia visto che la maggior parte dei veri sviluppatori riesce a malapena a sopravvivere !
fintosviluppatore mi dispiace che tu abbia reagito in questo modo ma gli sviluppatori hanno conoscenze di matematica e di linguaggi di programmazione che non vengono messi all’opera quando usiamo un page builder.
I page builder risolvono tutti i grattacapi e le soluzioni che vengono implementate attraverso il codice.
Non vogliamo sembrare offensivi ma semplicemente tracciare una linea sulla sabbia. Quando usiamo un page builder non svolgiamo un lavoro da sviluppatori (neanche gli stessi), stiamo creando un sito web con gli stessi strumenti che potrebbero essere utilizzati dal nostro cliente.
Questo è vero solo se si considera un sito web un ammasso di codici, che decisamente, nel 2018, non è.
L’impatto della semantica del codice sull’indicizzazione Google è irrilevante rispetto ad altri fattori decisamente più importanti, come contenutistica e backlinks.
L’impatto sulle prestazioni è irrilevante, dato dal caching, da un buon hosting, e da una buona ottimizzazione delle immagini.
Insomma, un sito web STATICO, al giorno d’oggi, si può tranquillamente creare con un visual builder (dimezzando i costi di realizzazione per tutte le parti coinvolte). E no, non può farlo il cliente che può a malapena accendere il computer. Un visual builder è un word di siti web. Tutti possono usarlo, ma non tutti ci possono tirare fuori un libro fatto e finito.
Io capisco i puristi del codice. Davvero, vi capisco. Ma secondo me state proprio sbagliando settore di accanimento.
I visual builder fanno fare siti statici per aziende statiche. Al posto di cercare soluzioni a come evitare l’inevitabile, perché non focalizzarsi su ciò per il quale DAVVERO è indispensabile lo sviluppo a codice?
Secondo me sarebbe un impiego migliore delle energie. Ma parere personale.
PS. non sono uno sviluppatore, sono un digital marketer. Mi capita di realizzare siti web per i clienti. i siti si posizionano bene, si caricano in meno di due secondi, sono validati w3, hanno ottimi punteggi (>90) nell’ottimizzazione. Utilizzano CDN e sono sicuri. Sinceramente, non mi sembra di vendere nessun tipo di fuffa e, soprattutto, non mi sembra minimamente che i miei clienti lo avrebbero potuto fare da soli.
PS2. non mi sono mai venduto, ad ogni modo, come sviluppatore. Perché per me gli sviluppatori non sono quelli che fanno siti statici, ma sono coloro che si occupano di sviluppare applicativi nuovi 🙂
Ciao Giorgio,
apprezzo molto il tuo commento e sotto certi punti di vista sono anche d’accordo con te e ti faccio anche i miei complimenti per i risultati che ottieni che però sono ben lontani dalla media, te lo posso assicurare.
Il tuo approccio all’uso dello strumento è di una persona coscente dei limiti imposti dallo strumento stesso, infatti tu appoggi a un sito costruito con il page builder un buon hosting, una cache e una CDN. Inoltre sei ben coscente del fatto che un buon sito ha bisogno di buoni contenuti e di backlink rilevanti per il posizionamento del sito stesso.
Però l’argomento dell’articolo vuol mirare proprio a quelle persone che si propongono come sviluppatori e non a persone che curano altri aspetti della promozione di un’azienda e offrono la realizzazione del sito come un add-on, come hai chiarito anche tu non ti ritieni uno sviluppatore e la cosa va anche bene.
Non credo però che la tua definizione di sviluppatore sia del tutto corretta perché io mi ritengo tale e i prodotti che sviluppiamo per i nostri clienti diventano statici soltanto se la persona al quale consegnamo il sito web non lo aggiorna e questo è fuori dal nostro controllo e dal nostro lavoro.
L’articolo è stato creato proprio per “citare” una categoria professionale che si propone come web developer ma che alla fine della fiera di developer non ha niente, si limita a installare un plugin e fare copia/incolla di codici senza avere la minima idea di quello che stia facendo.
Stessa cosa va detta della mantenibilità del prodotto stesso.
Lo screenshot che puoi vedere nell’articolo proviene da un sito vero e sviluppato da “professionisti” che fanno questo per lavoro, modificare un elemento all’interno di una pagina costruita in questo modo prendeva decine di minuti (anche per colpa del server sul quale era ospitato). Cosa che se avessi potuto gestire tutto dal codice ci avrei messo pochi secondi.
Insomma la nostra non vuol essere una guerra verso tutti coloro che utilizzano dei page builder, se questi strumenti hanno riscosso così tanto successo un motivo ci sarà ed è perché il mercato li richiede.
Piuttosto il nostro tentativo è quello di educare neo-sviluppatori e potenziali clienti nel rischio che si potrebbe correre nell’utilizzare soluzioni di questo tipo senza sapere veramente quello che si sta facendo o il prodotto che si otterrà una volta terminati i lavori.
Tra l’altro lo stesso WordPress sta subendo una trasformazione in questo campo e sta introducendo il suo “page builder” che però lavora in modo mooolto diverso dalla concorrenza e offre un grande controllo anche allo sviluppatore che dovrà gestirlo. Se ti interessa dare un’occhiata il nuovo editor prende il nome di Gutenberg e anche se non è un completo page builder offre molte funzionalità simili e soprattutto permetterà all’utente finale di costruire la pagina come desidera senza inserire un’alberatura degli elementi confusa e complicata come accade oggi.
Grazie per essere passato da queste pagine e per aver condiviso il tuo pensiero.
Buongiorno!
Mi chiamo Mattia Rasulo ho da poco iniziato a studiare il web coding con particolare focus su Javascript.
NON sono ancora esperto né ho ancora una web agency.
Ho da poco, avendo completato lo studio della parte front-end, inziato a studiare node col suo npm ed express.
Mi chiedo veramente con ingenuità..
Ma perché le web agency in Italia, da quanto leggo online, usano TUTTE WordPress?
Non sarebbe meglio usare nuovi linguaggi come NodeJS o Python e abbandonare un po’ tutti il PHP, a maggior ragione reso così pesante da WordPress e soprattutto dai suoi plugin e temi così complessi a livello di codice?
Insomma, perché vendere al cliente un CMS come WP anziché creare una vera web app?
Ripeto, chiedo veramente PER CAPIRE, non capendo la quotidianità di chi fa questo lavoro.
Questo va più in profondità dell’uso di Divi o altro, che ovviamente lascia un codice dal peso di due tonellate come gli editor visuali hanno sempre fatto dagli anni ‘90..
Grazie dell’attenzione!
Ciao Mattia,
intanto complimenti per aver già capito che gli editor visuali inseriscono più codice del dovuto 🙂
Venendo invece al nocciolo della questione, anche se non ritengo corretto dire che TUTTE le web agency italiane usano WordPress (sono sicuramente molte ma se cerchi bene trovi persone che lavorano anche con altri strumenti), c’è da dire che sia PHP che JS (e tutto ciò che porta con Node.js e i vari pacchetti) possono avere dei lati negativi e ci sono casi in cui è preferibile usare uno piuttosto che un altro.
Ti chiedo di prendere per buona questa cosa perché per validarla avrei bisogno di scrivere molto più testo di quello che posso fare in questo commento e ti consiglio di leggere articoli di persone molto più esperte di me sulla questione. Aprire Google e scrivere “PHP vs JS” dovrebbe essere più che sufficiente 😉
Dato che vuoi capire, come hai ben detto, diciamo che in molti utilizzano WordPress (purtroppo) per la quantità di page builder presenti mentre altri (come il sottoscritto) lo utilizzano come un framwork sul quale basare il codice del proprio progetto.
WordPress offre molte soluzioni già integrate che uno sviluppatore può semplicemente usare e personalizzare come:
un login system sicuro
gestione del cron (per esempio per pubblicare articoli in futuro)
gestione dei redirect e permalink
una ACL abbastanza buona
e molto altro…
Sicuramente negli oltre 10 anni da quando WordPress è stato creato sono venute fuori delle soluzioni interessanti ma siamo ancora distanti anni luce dall’avere un confronto “alla pari” tra questa e le altre piattaforma JS.
Non credere che JavaScript sia la soluzione a tutti i problemi perché in molti casi è stato dimostrato anche il contrario, ovvero che ne può causare diversi.
Ciao, sono sempre più dell’opinione che un professionista non debba utilizzare WordPress, personalmente ho sviluppato un mio CMS che nella mia agenzia utilizziamo per sviluppare i prodotti dei clienti.
Questo ci permette di creare un prodotto ad-hoc senza dover utilizzare stupidi plugin pieni di bug. Purtroppo per esigenza del cliente spesso ci troviamo a dover ripiegare su WordPress e quindi, nel caso di prodotti in essere, di sbattere la testa contro questi page-builder sopracitati.
Credo che l’evoluzione di WordPress sempre più noob-friendly abbia purtroppo portato a questo, permettendo anche a “mio cugino” di sviluppare un sito web che visivamente sembra professionale semplicemente scaricando un template a 50€ dai marketplace.
Questo mette in difficoltà i veri sviluppatori, quella gente che ha competenze nello sviluppo di frontend e backend, che ha studiato una vita e ha impiegato notte e giorno a migliorare i propri prodotti.
Onestamente, in 10 anni di attività a stretto contatto con le aziende, raramente mi son trovato davanti un cliente che voleva effettivamente un prodotto che presentasse un codice di qualità, solitamente basta che funzioni e che rispecchi le sue aspettative grafiche ( stendiamo un velo pietoso su questo per favore).
Questo porta inevitabilmente ad un panorama web costellato di prodotti di bassissima qualità ma che vendono, forti del loro basso prezzo e tempi di consegna esageratamente veloci.
Quindi ci troviamo con siti web senza la ben che minima ottimizzazione, che caricano le pagine nel tempo record di 8 minuti netti, con migliaia di bug e plugin non aggiornati. Questo è WordPress oggi.
Ciao Andrea,
concordo all’80% su quanto detto ma non credo che la creazione di un CMS proprietario sia la soluzione ideale perché, per quanto tu ti possa impegnare a scrivere del buon codice, i problemi di sicurezza sono dietro l’angolo e spesso ho avuto a che fare con CMS proprietari che sono stati bucati e che per un motivo o per un altro non sono mai stati corretti.
Sia chiaro che non sto puntando il dito contro il tuo che onestamente neanche conosco.
Per le mie necessità di sviluppo uso WordPress perché mi permette di dedicarmi alle cose che so fare meglio e non ad altre in cui farei un lavoro a malapena decente. Ho tirato su il fattore sicurezza perché se usi WordPress e pochi plugin selezionati le falle di sicurezza vengono chiuse in tempo record, sia nel core che dagli sviluppatori (seri) di plugin.
Ripeto, non me ne volere perché non sto puntando il dito contro di te.
Condivido la frustrazione nei confronti del cliente che non apprezza un sito web fatto bene e che si carica in tempi accettabili ma forse questa è anche colpa nostra che non riusciamo a far capire la necessità di siti web fatti bene, forse se fossimo più bravi a far capire il danno arrecato da un sito web lento e fatto male (in termini di mancati guadagni così parliamo lingua del cliente) saremo in grado di alzare le nostre tariffe e farci rispettare maggiormente.
Concludo dicendo che io uso WordPress per lavoro e spero che tu possa capire, anche dagli argomenti che tratto in questo sito, che lo utilizzo come se fosse il mio framework di sviluppo con alcuni vantaggi come quelli della community e dei (buoni) plugin che utilizzo.
Poi la programmazione è bella e chiunque può prendere l’approccio che preferisce.
Decisamente d’accordo, il nostro puntare su di un CMS proprietario è stata una scelta quasi dettata interamente dalla necessità di sviluppare molto spesso plugin ad hoc, per cui, abbiamo deciso in fine di creare qualcosa di più veloce e immediato.
Concordo con te sul discorso sicurezza, ma voglio scagliare una lancia a favore di soluzioni proprietarie. É vero che, grandi team di sviluppatori riescono a chiudere falle di sicurezza in tempi record ma, la stragrande maggioranza degli sviluppatori, una volta consegnato il lavoro, abbandona gli aggiornamenti del core e dei plugin, lasciando esposto il prodotto a qualsiasi possibile attacco in poco tempo, vero che è possibile attivare gli aggiornamenti automatici ma, come ben sappiamo, soprattutto nelle major, salta un plugin e ciao! Personalmente, non riusciamo, nonostante la bravura del ns commerciale, a vendere ai clienti chissà quanti pacchetti di manutenzione, spesso nemmeno il blog viene aggiornato. Questa era una digressione sul panorama e la consapevolezza che hanno nel web le aziende del luogo a cui, devi necessariamente fare un mini corso per spiegare le potenzialità ed i pericoli.
Purtroppo nel tempo, il ns lavoro si è svalutato talmente tanto, (mettiamoci in mezzo i vari wix e boiate varie che permettono a tutti di costruire un sito web in 1 ora, tralasciando ovviamente la qualità e l’impatto sul cliente finale), che uno sviluppatore deve ripiegare, abbassare il prezzo, consegnare un lavoro fatto in fretta e a volte male.
Il tutto per rientrare nel prezzo, già stracciato e non perdere tempo inutile che non viene retrivuito.
Questo articolo tralascia un aspetto FONDAMENTALE: il BUDGET
Se un cliente ha soldi, io non uso WP per farli un sito ma glielo faccio da zero totalmente custom
Se il cliente non li ha (il 90% piange miseria) io glielo faccio con WP e in 48 ore è pronto.
Poi avete preso come esempio Visual Composer che è forse uno dei peggiori Builder in commercio.
Ma resta il fatto che se un sito viene venduto a quattro spiccioli fatturati (quindi con un guadagno di quasi il 50% nett0), col piffero che gli faccio un lavoro custom
Ciao Maurizio,
grazie per il tuo intervento ma in tutta onestà io tengo in considerazione anche il budget quando non utilizzo un page builder e sì Visual Composer è stato facile da attaccare ma è stato il lavoro che ci ha fatto perdere più tempo e che ci ha dato l’ispirazione di scrivere questo articolo. A mio avviso alcuni aspetti sono replicabili anche in builder come Elementor o altri ma condivido il tuo pensiero sul fatto che Visual Composer è il peggiore di tutti.
Riprendendo il discorso “budget” io trovo di essere molto più veloce con il codice rispetto a un builder ma anche io, come te, non mi sognerei mai di sviluppare un sito da zero se non vengo pagato abbastanza. Quello che ho scelto di fare è utilizzare un framework come Genesis che, grazie ai suoi child theme, mi permette di dare un avvio veloce ai lavori e se il budget è poco (anche se generalmente non accetto lavori a basso costo ed è una cosa che consiglio di fare a chiunque) faccio capire al cliente che al massimo posso cambiare due colori.
In questo modo posso consegnare al cliente un sito performante senza la presenza di strumenti che non utilizzerà in futuro o che possono appesantire il suo sito.
Sul discorso del budget poi c’è moltissima letteratura e anche su questo sito abbiamo affrontato l’argomento arrivando fino alla pubblicazione di un corso. Che sia chiaro, non sto dicendo che questa è l’unica via ma è quella che ho provato sulla mia pelle e che, per fortuna, sta dando i suoi frutti.
Poi il mondo è bello perché vario e nessun campo come quello dell’informatica offre così tante alternative e possibilità per raggiungere un obiettivo.
Ci sarà un motivo per cui WP è diventato un page builder, con lo stramaledetto Gutenberg.
E gli sviluppatori ormai vagano nel panico, perchè già da un po’ di tempo nessuno fa più un sito proprietario, e sono pochi quelli disposti a pagare 50-80€/ora per un lavoro che poi alla fine (anche senza page builder) uno si fa da solo. I page builder sarebbero da abolire, ma non possiamo più permetterci che il web stia in mano ad un élite
Sicuramente i page builder sono in grado di realizzare un sito custom con pochi click e se l’imprenditore di turno ritiene che il suo tempo vale poco sarà disposto a passare molte ore a combattere con lo strumento che ha scelto per realizzare il proprio sito web.
Guarda io non sono contrario ai page builder al 100%, anzi conosco diversi sviluppatori che li usano e se sis considera Gutenberg con i suoi sviluppi futuri e l’ottimo lavoro ed esperienza portata da altri page builder. Quello che mi da fastidio onestamente è avere la richiesta di qualcuno che si è costruito il sito con uno di questi strumenti e poi contatta me per una “piccola modifica”, che spesso invece è una personalizzazione molto avanzata. Mi infastidisce perchè, giustamente, dalla sua esperienza è stato tutto un punta e clicca e un collage di funzionalità che le decine di plugin installati forniscono alla piattaforma e quello che diventa difficile far comprendere è che almeno il 70% del tempo che verrà speso per realizzare la “piccola modifica” verrà impiegato facendo debugging ?
La mia scelta definitiva è stata cambiare campo da gioco perchè a questo punto hai due scelte:
Il mondo dello sviluppo si evolve velocemente, gli strumenti pure quindi è bene che questo ritmo venga seguito anche dalle nostre attività.
Ovviamente questo è il mio punto di vista.
Condivido molte cose che dici, ma forse non conosci Oxygen Builder.
Ciao Rodolfo,
grazie per aver condiviso la tua opinione ma anche considerando che l’articolo è vecchio continuo a preferire seguire la strada che WordPress mette a disposizione al 100% senza utilizzare plugin aggiuntivi per lo stile del contenuto.
Esistono diversi modi di lavorare e quello che ho deciso di adottare è fornire al mio cliente la possibilità di inserire il contenuto senza preoccuparsi troppo dello stile con il quale viene presentato.
Questo mi permette di evitare che il design custom sia rispettato senza inoltre appesantire la mia installazione con un plugin che può essere tanto complesso da rallentarne il caricamento.
Ovviamente io non condanno chi li usa, anche se credo che per essere chiamato sviluppatore WordPress bisogna conoscere questa piattaforma dall’interno e non basta mettere insieme qualche regola CSS per essere tale. Le argomentazioni sono molte e anche su Facebook tempo fa si è scatenato un putiferio, quindi preferisco concludere dicendo che è giusto usare gli strumenti che si sanno usare.
L’obiettivo finale deve essere la soddisfazione del cliente e non la soluzione utilizzata.
Ciao caro Andrea, l’articolo che hai scritto mi ha colpito molto ed infetti non ho mai visto di buon occhio i builder però sono effettivamente veloci, soprattutto quando il capo di una agenza ti chiede di fare siti contemporaneamente e di fretta, cosa notevolmente assurda e controproducente.
Vorrei però chiederti se potresti spiegarmi meglio per quanto riguarda “framework serio basato sul PHP”, capisco che il linguaggio php sia migliore in assoluto, ma vorrei approfondimenti o se conosci articoli affidabili riguardanti questa tematica dato che vorrei davvero crescere in questo settore. Un’altra domanda che vorrei farti e se bocci proprio tutti i builder come divi e wpbakery.
Grazie davvero per il tuo tempo. Aspetto tue notizie.
Ciao Federica,
comincio subito con il dire che l’articolo che hai letto è stato pubblicato più o meno 5 anni fa, il che lo rende alquanto vecchiotto.
In questi anni i vari builder si sono evoluti moltissimo e confesso di non essere più cosí contrario. Se fino a qualche anno fa difendevo le idee definite in questo articolo e consigliavo (fortemente) di sviluppare siti WordPress con codice, in certi casi aiutati da un buon framework come Genesis, oggi non è più cosí.
Le motivazioni sono diverse e difficili da riassumere in un singolo commento ma diciamo semplicemente che se da una parte i builder si sono evoluti dall’altra, con l’inserimento del nuovo editor, la creazione di temi si è complicata parecchio e – a mio avviso ancora più grave – non si è ancora raggiunto uno standard.
Cercando di essere di aiuto ti confesso che al giorno d’oggi userei un builder come Elementor (gli altri li ritengo eccessivamente complessi) per qualsiasi sito WordPress mi trovo a creare, anche se con WordPress non svilupperei qualsiasi sito…
Lasciando da parte quali siti farei in WordPress e quali c’è un grandissimo MA che vorrei discutere prima di concludere il commento.
Io consiglio di usare un builder al giorno d’oggi ma chiunque lo utilizzi deve comunque avere delle solide conoscenze su come si sviluppa un sito web.
Ti dico presto perchè: questi strumenti permettono di creare velocemente dei siti accattivanti ma che possono diventare lenti o difficili da gestire nel tempo se non si possiedono le conoscenze necessarie a prendere delle decisioni informate. Ogni widget, ogni personalizzazione che farai avrà un peso e se inizi a mettere insieme pezzi a caso e a sistemarli con la stessa logica capisci da sola che i problemi possono crescere in maniera esponenziale.
Ultima cosa, il PHP non è il linguaggio migliore in assoluto (anzi non esistono linguaggi migliori in assoluto ma, anche se ce ne sono alcuni migliori di altri) e ti confesso che io ho smesso di scrivere codice PHP da circa 2 anni. Se il tuo lavoro ti porta a utilizzare questo linguaggio ti consiglio di consultare anche i corsi presenti in questo stesso sito, sono tutti gratuiti e anche se un po’ datati ti forniranno le conoscenze necessarie per comprendere il linguaggio che sta alla base di WordPress.
Ti ringrazio per la risposta e vorrei chiederti un ultima cosa per vedere se ho capito bene. Dunque se modifico, anche di poco con il css, un blocco di un elemento preimpostato il sito si appesantirà e rallentarà?
Ciao di nuovo Federica,
no non sto dicendo che appena modifichi un po’ di CSS il sito si rallenta, altrimenti anche solo sviluppare un sito web sarebbe un problema.
Quello che sto cercando di dire è che se si creano siti web con Elementor senza sapere quello che si sta facendo il rischio è di creare siti web lenti, ovvero cerco di farti capire (a te e alle persone che leggeranno i nostri commenti) che Elementor non è la soluzione a tutti i nostri problemi quando si tratta di creare siti con WordPress ma soltanto uno strumento che semplifica un aspetto specifico del nostro lavoro.