+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 tardado la pregunta en quedar sin respuesta.
En 1984, Apple presentó el Macintosh con una promesa simple: lo que ves en pantalla es lo que obtienes en papel. El paradigma WYSIWYG — What You See Is What You Get — había nacido. Unos años después, invadió la creación web. Dreamweaver, FrontPage, luego WordPress, Wix, Webflow… La promesa nunca cambió: crear sin programar.
Cuarenta años después, el debate sigue sin resolverse. Y sin embargo, algo ha cambiado fundamentalmente en los talleres y agencias web en 2024.
Esto es lo que vemos realmente 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
Pregúntale a cualquier desarrollador web de los años 2000: ¿Dreamweaver o el Bloc de notas? Obtendrás 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 olvidamos es que este 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 pequeña empresa 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 en WordPress.
El problema es que durante mucho tiempo se presentaron los dos enfoques como mutuamente excluyentes. O programas, o usas un constructor visual. O eres serio, o usas 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 usado ambos enfoques. Y sobre todo he aprendido cuándo falla cada uno.
Las herramientas visuales fallan cuando:
- El cliente quiere una funcionalidad específica que el constructor no prevé
- El rendimiento se vuelve crítico (un Elementor cargado fácilmente suma 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 necesita actualizar su contenido sin llamar a la agencia
- El presupuesto no justifica 3 semanas de desarrollo para 5 páginas estáticas
- El time-to-market 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 funcionan son los que eligen la herramienta adaptada a la restricción dominante — no la herramienta que se prefiere 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 el caso.
Figma rompió la frontera por el lado del diseño. Diseñas visualmente, pero exportas tokens de diseño, variables, una estructura que habla directamente al código. Los componentes de Figma se mapean sobre componentes React o Astro. La brecha entre “lo diseñé” y “está codificado” se ha reducido de forma espectacular.
Webflow hizo lo mismo por el lado del desarrollo. Arrastras bloques visualmente, pero por detrás, el código generado es limpio, semántico, 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 “programo” y “uso una herramienta visual” se ha vuelto difusa en ambos sentidos.
“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 dedicas a gestionar las actualizaciones de un sitio WordPress sobrecargado de plugins?
Es la pregunta que nadie hace al elegir una herramienta. Miramos el coste de creación. Rara vez el coste total de propiedad a 3 años.
Un sitio con constructor visual masivo:
- Creación rápida, presupuesto inicial controlado
- Pero: dependencia del proveedor, rendimiento a menudo degradado, personalización limitada, migraciones dolorosas
- Coste real a 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 que hayas industrializado tu flujo de trabajo)
- Pero: rendimiento máximo, cero dependencia de terceros, escalabilidad total, propiedad completa del código
- Coste real a 3 años: mantenimiento ligero, evoluciones puntuales, ninguna suscripción parásita
Un sitio híbrido (CMS headless + front-end moderno):
- Lo mejor de los dos mundos sobre el papel
- Pero: mayor complejidad técnica, requiere un equipo que domine ambos lados
- Coste real a 3 años: depende enteramente de la calidad de la arquitectura inicial
Mi consejo para una pequeña empresa con presupuesto limitado: no elijas en función de lo que quieres crear hoy. Elige en función de lo que necesitarás modificar en 18 meses — eso también determina cuándo un rediseño es realmente necesario en lugar de una simple evolución.
Nuestra stack actual — y por qué tomamos una decisión
En GDM-Pixel, hemos dejado de debatir. Hemos elegido.
Nuestra stack de producción para sitios corporativos y e-commerce: Figma para el diseño → Astro + Tailwind para el front-end → CMS headless para el contenido → Claude Code para la aceleración del 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 rivalizar en este criterio.
Tailwind elimina el 80% de las decisiones CSS repetitivas. Programamos 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) da al cliente una interfaz de edición clara y sencilla, sin que jamás toque 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.
Lo que esto cambia para ti — empresario o responsable de decisiones
Si estás decidiendo cómo rehacer tu sitio, aquí están las tres preguntas que realmente importan:
1. ¿Quién va a mantener el contenido en el día a día? Si eres tú o un colaborador no técnico, necesitas 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 tus restricciones 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. ¿Tu sitio debe evolucionar en 2 años? Si es así, la arquitectura importa tanto como la estética. Un sitio bonito construido sobre una stack frágil te costará una refactorización completa en lugar de una simple evolución. Es precisamente lo que aseguramos desde la creación de tu 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 tu contexto de proyecto, tu presupuesto de mantenimiento y tus 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 hayas industrializado tu 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 equivale a menos visibilidad y menos conversiones — independientemente de la herramienta utilizada para crearlo.
¿Rehaces tu sitio en 2024?
No elijas tu herramienta antes de haber definido tu restricción principal.
En GDM-Pixel, comenzamos todos nuestros proyectos con un diagnóstico de 30 minutos: cuáles son tus necesidades reales, cuáles son tus restricciones concretas, y qué stack responde mejor a ellas — sin vender de más y sin ideología.
Si tu proyecto necesita una auditoría técnica más que una refactorización completa, te lo decimos. Si un CMS estándar es suficiente, no te vendemos desarrollo a medida.
Cuarenta años después del primer clic WYSIWYG, la mejor interfaz sigue siendo la que te ayuda a alcanzar tus objetivos de negocio — no la que impresiona en una demo.
Contacta con GDM-Pixel para un diagnóstico sin compromiso. Te decimos lo que realmente funciona para tu caso.
Redes sociales
Analizar con IA
