+33-9-7266-3068
contact@gdm-pixel.fr
TL;DR
Nel 1984, il primo clic ha cambiato tutto
Quarant’anni. È il tempo che ci è voluto affinché la domanda restasse aperta.
Nel 1984, Apple introduceva il Macintosh con una promessa semplice: ciò che vedete sullo schermo è ciò che ottenete sulla carta. Il paradigma WYSIWYG — What You See Is What You Get — era nato. Qualche anno dopo, invadeva la creazione web. Dreamweaver, FrontPage, poi WordPress, Wix, Webflow… La promessa non è mai cambiata: creare senza programmare.
Quarant’anni dopo, il dibattito non è ancora risolto. Eppure, qualcosa è fondamentalmente cambiato nei workshop e nelle agenzie web nel 2024.
Ecco cosa si vede realmente sul campo — e perché la vera domanda non è più “codice o interfaccia visuale”, ma “quale per quale uso, in quale momento del progetto”.
La storia di un falso duello
Fate la domanda a qualsiasi sviluppatore web degli anni 2000: Dreamweaver o il Blocco Note? Otterrete una risposta netta, spesso appassionata, a volte sprezzante.
Gli sviluppatori “puri” guardavano gli strumenti visuali come generatori di codice spaghetti. I designer li amavano perché non dovevano imparare il CSS. I due campi si sono a lungo ignorati — o combattuti.
Quello che si dimentica è che questo duello è sempre stato artificiale.
Uno strumento WYSIWYG non ha mai preteso di sostituire uno sviluppatore senior su un’applicazione complessa. E uno sviluppatore che scrive tutto a mano non è mai stato la soluzione ideale per una piccola impresa che vuole solo aggiornare la propria pagina “I nostri servizi” una volta al mese — un arbitraggio che abbiamo già dettagliato a proposito dei costruttori visuali su WordPress.
Il problema è che per molto tempo le due approcci sono stati presentati come mutualmente esclusivi. O programmate, o usate un costruttore visuale. O siete seri, o fate Wix.
Questa visione binaria è costata cara a molti progetti.
Cosa mi hanno insegnato 15 anni di progetti web
Sui progetti che abbiamo condotto in GDM-Pixel, ho usato entrambi gli approcci. E soprattutto ho imparato quando ciascuno si rompe.
Gli strumenti visuali si rompono quando:
- Il cliente vuole una funzionalità specifica che il costruttore non prevede
- Le prestazioni diventano critiche (un Elementor carico significa facilmente 4-6 secondi di caricamento)
- La struttura dei dati è complessa (catalogo prodotti con varianti, tariffazione dinamica, integrazione ERP)
- Il progetto deve evolversi nel corso di 5 anni senza dipendere da un editore terzo
Il codice puro si rompe quando:
- Il cliente deve aggiornare i contenuti da solo senza chiamare l’agenzia
- Il budget non giustifica 3 settimane di sviluppo per 5 pagine statiche
- Il time-to-market è critico e non c’è il lusso di costruire tutto da zero
Non è una questione di fede. È una questione di contesto.
Quello che vediamo concretamente con i nostri clienti: i progetti che vanno meglio sono quelli in cui è stato scelto lo strumento adatto al vincolo dominante — non lo strumento che si preferisce per impostazione predefinita.
2024: il vero cambio di paradigma
Ecco dove diventa interessante.
L’opposizione codice vs WYSIWYG era pertinente quando i due campi erano davvero separati. Non è più così.
Figma ha abbattuto il confine lato design. Disegnate visivamente, ma esportate token di design, variabili, una struttura che parla direttamente al codice. I componenti Figma si mappano su componenti React o Astro. Il divario tra “ho progettato” e “è codificato” si è ridotto in modo spettacolare.
Webflow ha fatto lo stesso lato sviluppo. Trascinate blocchi visivamente, ma dietro, il codice generato è pulito, semantico, manutenibile. Non è più il codice spaghetti di Dreamweaver 2003.
E soprattutto — l’IA ha cambiato le regole del gioco.
Oggi, con Claude Code o GitHub Copilot, uno sviluppatore che scrive codice “a mano” non lo scrive davvero a mano. Dirige. Valida. Architetta. L’IA genera il 70% del codice ripetitivo. Ciò che rimane sono la logica di business, le decisioni architetturali, le ottimizzazioni.
Quindi il confine tra “programmo” e “uso uno strumento visuale” è diventato sfumato in entrambe le direzioni.
“The best interface is no interface — but until we get there, the best interface is the one your team actually uses.” — Golden Krishna, The Best Interface Is No Interface
Il vero costo nascosto di ogni approccio
Quante ore a settimana passate a gestire gli aggiornamenti di un sito WordPress sovraccarico di plugin?
È la domanda che nessuno si pone quando sceglie uno strumento. Si guarda il costo di creazione. Raramente il costo di possesso su 3 anni.
Un sito con costruttore visuale consumer:
- Creazione rapida, budget iniziale controllato
- Ma: dipendenza dall’editore, prestazioni spesso degradate, personalizzazione limitata, migrazioni dolorose
- Costo reale su 3 anni: abbonamento mensile + tempo speso ad aggirare i limiti + rifacimento quando le esigenze evolvono
Un sito sviluppato su misura con uno stack moderno:
- Costo iniziale più elevato, tempi di consegna più lunghi (salvo se si è industrializzato il workflow)
- Ma: prestazioni massime, zero dipendenza da terzi, scalabilità totale, piena proprietà del codice
- Costo reale su 3 anni: manutenzione leggera, evoluzioni mirate, nessun abbonamento parassita
Un sito ibrido (CMS headless + front-end moderno):
- Il meglio dei due mondi sulla carta
- Ma: complessità tecnica più elevata, richiede un team che padroneggi entrambi i lati
- Costo reale su 3 anni: dipende interamente dalla qualità dell’architettura iniziale
Il mio consiglio per una piccola impresa con budget limitato: non scegliete in base a ciò che volete creare oggi. Scegliete in base a ciò che dovrete modificare tra 18 mesi — è anche questo a determinare quando un rifacimento è davvero necessario piuttosto che una semplice evoluzione.
Il nostro stack attuale — e perché abbiamo scelto
In GDM-Pixel, abbiamo smesso di dibattere. Abbiamo scelto.
Il nostro stack di produzione per i siti vetrina e e-commerce: Figma per il design → Astro + Tailwind per il front-end → CMS headless per i contenuti → Claude Code per accelerare lo sviluppo.
Perché questa scelta?
Astro genera HTML statico per impostazione predefinita. Risultato: punteggi Lighthouse sistematicamente superiori a 95. Nessun costruttore visuale può competere su questo criterio.
Tailwind elimina l’80% delle decisioni CSS ripetitive. Si programma più velocemente, il codice è più coerente, la manutenzione è banale.
Claude Code genera i componenti ripetitivi (schede, sezioni, moduli) in pochi secondi a partire dai nostri prompt standardizzati. Ciò che richiedeva 2 ore ora richiede 20 minuti.
Il CMS headless (Sanity o Directus a seconda del progetto) offre al cliente un’interfaccia di editing chiara e semplice, senza mai toccare il codice.
Risultato concreto: consegniamo siti da 5 pagine in 3 giorni. Progetti che 5 anni fa richiedevano 3 settimane.
Non è WYSIWYG. Non è codice puro neanche. È un workflow industrializzato che prende il meglio dei due mondi.
“Tools are only as good as the workflow they fit into.” — Anonimo, ma vero in tutti i progetti che abbiamo condotto.
Cosa cambia per voi — imprenditore o decisore
Se state scegliendo come rifare il vostro sito, ecco le tre domande che contano davvero:
1. Chi gestirà i contenuti quotidianamente? Se siete voi o un collaboratore non tecnico, avete bisogno di un’interfaccia di editing semplice. Non necessariamente un costruttore visuale completo — un CMS ben configurato è ampiamente sufficiente.
2. Quali sono i vostri vincoli di prestazione? Un sito e-commerce lento perde vendite. Google l’ha misurato: ogni secondo di caricamento aggiuntivo può ridurre le conversioni dal 7 al 12%. Se le prestazioni sono critiche, il codice su misura non è un lusso — è un investimento.
3. Il vostro sito deve evolversi entro 2 anni? Se sì, l’architettura conta quanto l’estetica. Un sito bello ma costruito su uno stack fragile vi costerà un rifacimento completo invece di una semplice evoluzione. È precisamente ciò che garantiamo fin dalla creazione del vostro sito internet.
Queste tre domande valgono più di qualsiasi dibattito filosofico sul codice vs il visuale.
In sintesi: tre punti da ricordare
Il dibattito codice vs WYSIWYG è superato. La vera domanda è: quale combinazione di strumenti corrisponde al vostro contesto di progetto, al vostro budget di manutenzione e ai vostri vincoli di evoluzione?
L’IA ha ridotto radicalmente il costo dello sviluppo su misura. Ciò che giustificava la scelta di un costruttore visuale “per andare veloci” sta scomparendo. Consegnare rapidamente con codice di qualità è ormai accessibile, a condizione di aver industrializzato il proprio workflow.
Le prestazioni non sono negoziabili nel 2024. I Core Web Vitals di Google sono un fattore di posizionamento diretto. Un sito lento significa meno visibilità e meno conversioni — qualunque sia lo strumento utilizzato per crearlo.
State rifacendo il vostro sito nel 2024?
Non scegliete lo strumento prima di aver definito il vostro vincolo principale.
In GDM-Pixel, iniziamo tutti i nostri progetti con una diagnosi di 30 minuti: quali sono le vostre reali esigenze, quali sono i vostri vincoli effettivi, e quale stack vi risponde meglio — senza sovravendere e senza ideologie.
Se il vostro progetto richiede un audit tecnico piuttosto che un rifacimento completo, ve lo diciamo. Se un CMS standard è sufficiente, non vi vendiamo sviluppo su misura.
Quarant’anni dopo il primo clic WYSIWYG, la migliore interfaccia rimane quella che vi fa raggiungere i vostri obiettivi di business — non quella che impressiona in demo.
Contattate GDM-Pixel per una diagnosi senza impegno. Vi diciamo cosa funziona davvero per il vostro caso.
Social network
Analizza con l'IA
