+33-9-7266-3068
contact@gdm-pixel.fr
TL;DR
En 1984, el primer clic lo cambió todo
Cuarenta años. Es el tiempo que ha sido necesario para que la pregunta siga sin respuesta.
En 1984, Apple presentó el Macintosh con una promesa sencilla: lo que ves en pantalla es lo que obtienes en papel. El paradigma WYSIWYG — What You See Is What You Get — había nacido. Pocos años después, invadía la creación web. Dreamweaver, FrontPage, luego WordPress, Wix, Webflow… La promesa nunca cambió: crear sin codificar.
Cuarenta años después, el debate sigue sin resolverse. Y sin embargo, algo ha cambiado fundamentalmente en los talleres y las agencias web en 2024.
Esto es lo que realmente se ve sobre el terreno — y por qué la verdadera pregunta ya no es “código o interfaz visual”, sino “cuál para qué uso, en qué momento del proyecto”.
La historia de un falso duelo
Haga la pregunta a cualquier desarrollador web de los años 2000: ¿Dreamweaver o el Bloc de notas? Obtendrá una respuesta tajante, a menudo apasionada, a veces despectiva.
Los desarrolladores “puros” miraban las herramientas visuales como generadores de código espagueti. Los diseñadores las adoraban porque no tenían que aprender CSS. Los dos bandos se ignoraron durante mucho tiempo — o se combatieron.
Lo que se olvida es que ese duelo siempre fue artificial.
Una herramienta WYSIWYG nunca pretendió reemplazar a un desarrollador senior en una aplicación compleja. Y un desarrollador que escribe todo a mano nunca fue la solución ideal para una pyme que solo quiere actualizar su página “Nuestros servicios” una vez al mes — un arbitraje que ya hemos detallado a propósito de los constructores visuales bajo WordPress.
El problema es que durante mucho tiempo se presentaron los dos enfoques como mutuamente excluyentes. O codificas, o usas un constructor visual. O eres serio, o haces Wix.
Esta visión binaria ha costado caro a muchos proyectos.
Lo que 15 años de proyectos web me han enseñado
En los proyectos que hemos llevado a cabo en GDM-Pixel, he utilizado ambos enfoques. Y sobre todo he aprendido cuándo cada uno falla.
Las herramientas visuales fallan cuando:
- El cliente quiere una funcionalidad específica que el constructor no contempla
- El rendimiento se vuelve crítico (un Elementor cargado supone fácilmente 4-6 segundos de carga)
- La estructura de datos es compleja (catálogo de productos con variantes, precios dinámicos, integración ERP)
- El proyecto debe evolucionar durante 5 años sin depender de un proveedor externo
El código puro falla cuando:
- El cliente debe actualizar su contenido por sí mismo sin llamar a la agencia
- El presupuesto no justifica 3 semanas de desarrollo para 5 páginas estáticas
- El tiempo de lanzamiento es crítico y no hay el lujo de construir todo desde cero
No es una cuestión de religión. Es una cuestión de contexto.
Lo que vemos concretamente con nuestros clientes: los proyectos que mejor van son aquellos en los que hemos elegido la herramienta adaptada a la restricción dominante — no la herramienta que preferimos por defecto.
2024: el verdadero cambio de paradigma
Aquí es donde se pone interesante.
La oposición código vs WYSIWYG era pertinente cuando los dos bandos estaban realmente separados. Ya no es así.
Figma rompió la frontera en el lado del diseño. Dibujas visualmente, pero exportas tokens de diseño, variables, una estructura que habla directamente al código. Los componentes de Figma se mapean sobre componentes de React o Astro. La brecha entre “he diseñado” y “está codificado” se ha reducido de forma espectacular.
Webflow hizo lo mismo en el lado del desarrollo. Arrastras bloques visualmente, pero detrás, el código generado es limpio, semántico y mantenible. Ya no es el código espagueti de Dreamweaver 2003.
Y sobre todo — la IA ha cambiado las reglas del juego.
Hoy, con Claude Code o GitHub Copilot, un desarrollador que escribe código “a mano” ya no lo escribe realmente a mano. Dirige. Valida. Diseña la arquitectura. La IA genera el 70% del código repetitivo. Lo que queda es la lógica de negocio, las decisiones de arquitectura, las optimizaciones.
Por tanto, la frontera entre “codifico” y “uso una herramienta visual” se ha vuelto difusa en ambas direcciones.
“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
El verdadero coste oculto de cada enfoque
¿Cuántas horas a la semana pasa gestionando las actualizaciones de un sitio WordPress sobrecargado de plugins?
Esa es la pregunta que nadie formula al elegir una herramienta. Se mira el coste de creación. Raramente el coste total de propiedad en 3 años.
Un sitio con un constructor visual de gran consumo:
- Creación rápida, presupuesto inicial controlado
- Pero: dependencia del proveedor, rendimiento a menudo degradado, personalización limitada, migraciones dolorosas
- Coste real en 3 años: suscripción mensual + tiempo dedicado a sortear las limitaciones + rediseño cuando las necesidades evolucionan
Un sitio desarrollado a medida con una stack moderna:
- Coste inicial más elevado, plazo de entrega más largo (salvo si se ha industrializado, véase nuestro flujo de trabajo)
- Pero: rendimiento máximo, cero dependencia de terceros, escalabilidad total, propiedad completa del código
- Coste real en 3 años: mantenimiento ligero, evoluciones puntuales, ninguna suscripción parásita
Un sitio híbrido (CMS headless + front-end moderno):
- Lo mejor de ambos mundos sobre el papel
- Pero: mayor complejidad técnica, requiere un equipo que domine los dos lados
- Coste real en 3 años: depende enteramente de la calidad de la arquitectura inicial
Mi consejo para una pyme con presupuesto limitado: no elija en función de lo que quiere crear hoy. Elija en función de lo que tendrá que modificar en 18 meses — eso es también lo que determina cuándo una remodelación es realmente necesaria en lugar de una simple evolución.
Nuestra stack actual — y por qué nos decidimos
En GDM-Pixel, dejamos de debatir. Elegimos.
Nuestra stack de producción para sitios escaparate y e-commerce: Figma para el diseño → Astro + Tailwind para el front-end → CMS headless para el contenido → Claude Code para acelerar el desarrollo.
¿Por qué esta elección?
Astro genera HTML estático por defecto. Resultado: puntuaciones Lighthouse sistemáticamente por encima de 95. Ningún constructor visual puede competir en este criterio.
Tailwind elimina el 80% de las decisiones CSS repetitivas. Codificamos más rápido, el código es más coherente, el mantenimiento es trivial.
Claude Code genera los componentes repetitivos (tarjetas, secciones, formularios) en segundos a partir de nuestros prompts estandarizados. Lo que antes llevaba 2 horas ahora lleva 20 minutos.
El CMS headless (Sanity o Directus según el proyecto) ofrece al cliente una interfaz de edición clara y sencilla, sin que tenga que tocar nunca el código.
Resultado concreto: entregamos sitios de 5 páginas en 3 días. Proyectos que hace 5 años llevaban 3 semanas.
Esto no es WYSIWYG. Tampoco es código puro. Es un flujo de trabajo industrializado que toma lo mejor de ambos mundos.
“Tools are only as good as the workflow they fit into.” — Anónimo, pero cierto en todos los proyectos que hemos llevado a cabo.
Lo que esto cambia para usted — empresario o decisor
Si está decidiendo cómo rehacer su sitio web, estas son las tres preguntas que realmente importan:
1. ¿Quién va a mantener el contenido día a día? Si es usted o un colaborador no técnico, necesita una interfaz de edición sencilla. No necesariamente un constructor visual completo — un CMS bien configurado es más que suficiente.
2. ¿Cuáles son sus requisitos de rendimiento? Un sitio e-commerce lento pierde ventas. Google lo ha medido: cada segundo adicional de carga puede reducir las conversiones entre un 7 y un 12%. Si el rendimiento es crítico, el código a medida no es un lujo — es una inversión.
3. ¿Su sitio debe evolucionar en 2 años? Si es así, la arquitectura importa tanto como la estética. Un sitio bonito pero construido sobre una stack frágil le costará una reconstrucción completa en lugar de una simple evolución. Es precisamente lo que aseguramos desde el principio en la creación de su sitio web.
Estas tres preguntas valen más que cualquier debate filosófico sobre código vs visual.
En resumen: tres puntos clave
El debate código vs WYSIWYG está superado. La verdadera pregunta es: ¿qué combinación de herramientas corresponde a su contexto de proyecto, su presupuesto de mantenimiento y sus restricciones de evolución?
La IA ha reducido radicalmente el coste del desarrollo a medida. Lo que justificaba elegir un constructor visual “para ir rápido” está desapareciendo. Entregar rápido con código de calidad es ahora accesible, siempre que se haya industrializado el flujo de trabajo.
El rendimiento no es negociable en 2024. Los Core Web Vitals de Google son un factor de posicionamiento directo. Un sitio lento significa menos visibilidad y menos conversiones — independientemente de la herramienta utilizada para crearlo.
¿Está rehaciendo su sitio en 2024?
No elija su herramienta antes de haber definido su restricción principal.
En GDM-Pixel, todos nuestros proyectos comienzan con un diagnóstico de 30 minutos: cuáles son sus necesidades reales, cuáles son sus restricciones reales, y qué stack responde mejor a ellas — sin sobrevender y sin ideología.
Si su proyecto requiere una auditoría técnica en lugar de una reconstrucción completa, se lo decimos. Si un CMS estándar es suficiente, no le vendemos desarrollo a medida.
Cuarenta años después del primer clic WYSIWYG, la mejor interfaz sigue siendo la que le permite alcanzar sus objetivos de negocio — no la que impresiona en una demostración.
Contacte con GDM-Pixel para un diagnóstico sin compromiso. Le decimos lo que realmente funciona para su caso.
Redes sociales
Analizar con IA
