+33-9-7266-3068
contact@gdm-pixel.fr
TL;DR
Nel 1984, il primo clic ha cambiato tutto
Quarant’anni. È il tempo necessario perché la domanda rimanga senza risposta.
Nel 1984, Apple presentava il Macintosh con una promessa semplice: ciò che vedete sullo schermo è ciò che ottenete su 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 codificare.
Quarant’anni dopo, il dibattito non è ancora risolto. Eppure, qualcosa è cambiato fondamentalmente 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
Ponete 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 adoravano perché non dovevano imparare i CSS. I due campi si sono a lungo ignorati — o combattuti.
Quel 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 semplicemente aggiornare la sua pagina “I nostri servizi” una volta al mese — un arbitraggio già approfondito a proposito dei costruttori visuali sotto WordPress.
Il problema è che i due approcci sono stati a lungo presentati come mutualmente esclusivi. O si programma, o si usa un costruttore visuale. O si è seri, o si fa Wix.
Questa visione binaria è costata cara a molti progetti.
Cosa mi hanno insegnato 15 anni di progetti web
Nei progetti che abbiamo condotto in GDM-Pixel, ho utilizzato entrambi gli approcci. E soprattutto ho imparato quando ciascuno si inceppa.
Gli strumenti visuali si inceppano quando:
- Il cliente vuole una funzionalità specifica che il costruttore non prevede
- Le prestazioni diventano critiche (un Elementor carico raggiunge facilmente 4-6 secondi di caricamento)
- La struttura dei dati è complessa (catalogo prodotti con varianti, prezzi dinamici, integrazione ERP)
- Il progetto deve evolversi per 5 anni senza dipendere da un fornitore esterno
Il codice puro si inceppa 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 religione. È una questione di contesto.
Quello che vediamo concretamente con i nostri clienti: i progetti che vanno meglio sono quelli in cui abbiamo scelto lo strumento adatto al vincolo dominante — non lo strumento che preferiamo per default.
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 rotto il confine sul lato del design. Si disegna visualmente, ma si esportano design token, 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 sul lato dello sviluppo. Si trascinano 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 più davvero a mano. Dirige. Valida. Architetta. L’IA genera il 70% del codice ripetitivo. Ciò che rimane è la logica di business, le decisioni di architettura, le ottimizzazioni.
Di conseguenza, il confine tra “codifico” 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 ciascun approccio
Quante ore a settimana passate a gestire gli aggiornamenti di un sito WordPress sovraccarico di plugin?
È la domanda che nessuno si pone quando si sceglie uno strumento. Si guarda il costo di creazione. Raramente il costo totale di proprietà in 3 anni.
Un sito con un costruttore visuale di largo consumo:
- Creazione rapida, budget iniziale controllato
- Ma: dipendenza dal fornitore, prestazioni spesso degradate, personalizzazione limitata, migrazioni dolorose
- Costo reale in 3 anni: abbonamento mensile + tempo dedicato 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, vedi il nostro workflow)
- Ma: prestazioni massime, zero dipendenze da terzi, scalabilità totale, proprietà completa del codice
- Costo reale in 3 anni: manutenzione leggera, evoluzioni mirate, nessun abbonamento parassita
Un sito ibrido (CMS headless + front-end moderno):
- Il meglio di entrambi i mondi sulla carta
- Ma: maggiore complessità tecnica, richiede un team che padroneggi entrambi i lati
- Costo reale in 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 ciò che determina 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 il contenuto → Claude Code per accelerare lo sviluppo.
Perché questa scelta?
Astro genera HTML statico per default. 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 che debba 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 è nemmeno codice puro. È un workflow industrializzato che prende il meglio di entrambi i 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 — imprenditori e decisori
Se state decidendo 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 una semplice interfaccia di editing. Non necessariamente un costruttore visuale completo — un CMS ben configurato è più che sufficiente.
2. Quali sono i vostri requisiti di prestazione? Un sito e-commerce lento perde vendite. Google lo ha misurato: ogni secondo aggiuntivo di caricamento 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 tra 2 anni? Se sì, l’architettura conta quanto l’estetica. Un sito bello ma costruito su uno stack fragile vi costerà una ricostruzione completa invece di una semplice evoluzione. È precisamente ciò che garantiamo fin dall’inizio nella creazione del vostro sito web.
Queste tre domande valgono più di qualsiasi dibattito filosofico su codice vs 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à è ora 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 — indipendentemente dallo strumento utilizzato per crearlo.
State rifacendo il vostro sito nel 2024?
Non scegliete il vostro 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 vere esigenze, quali sono i vostri vincoli reali, e quale stack risponde meglio — senza sopravvendere e senza ideologia.
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 permette di raggiungere i vostri obiettivi di business — non quella che impressiona in una demo.
Contattate GDM-Pixel per una diagnosi senza impegno. Vi diciamo cosa funziona davvero per il vostro caso.
Social network
Analizza con l'IA
