\n<\/p>\n
Desde hace casi 10 a\u00f1os, la hegemon\u00eda de los CMS tradicionales tipo WordPress est\u00e1 en entredicho en favor de las llamadas soluciones de \u201cgesti\u00f3n de sitios web\u201d.sin cabeza<\/em>\u201d. En esta concepci\u00f3n, desacoplamos (el cuerpo (back-end<\/em>) de la cabeza (Interfaz<\/em>). Al ofrecer una interfaz de gesti\u00f3n de contenidos independiente de la presentaci\u00f3n gr\u00e1fica, estos CMS pretenden ser m\u00e1s sencillos para contribuyentes y desarrolladores, m\u00e1s escalables y pretenden ofrecer mejores experiencias de usuario multicanal.<\/p>\n Despu\u00e9s de esta carrera hacia la decapitaci\u00f3n, el bombo publicitario <\/em>Parece caer de nuevo. Si este m\u00e9todo de gesti\u00f3n de sitios web es relevante para algunas empresas, no lo es para todas. Por lo tanto, muchas empresas se est\u00e1n recuperando de esto, en particular debido a las rigideces que provoca en los equipos de marketing.<\/p>\n A partir de mediados de la d\u00e9cada de 2010 surgi\u00f3 gradualmente una alternativa: el CMS h\u00edbrido. Algunas de las funciones m\u00e1s intuitivas que ofrecen los CMS tradicionales, como la edici\u00f3n de contenido WYSIWYG (Lo que ves es lo que obtienes<\/em>), se conservan y se asocian con llamadas de contenido a trav\u00e9s de API para visualizaci\u00f3n omnicanal. Para las empresas que buscan simplicidad y agilidad, la idea es atractiva y, naturalmente, el CMS h\u00edbrido se destaca como la soluci\u00f3n que se supone ofrece lo mejor de ambos mundos.<\/p>\n \u00bfPromesa cumplida? No exactamente. O al menos no para todos. En esta gran ventana de transferencia de CMS, los desarrolladores, aunque est\u00e1n en el coraz\u00f3n del reactor, tienen la sensaci\u00f3n de haber sido dejados al margen.<\/p>\n Si en comunicaci\u00f3n y marketing la opci\u00f3n h\u00edbrida cumple muchos requisitos, los desarrolladores a veces todav\u00eda tienen algunas dificultades para orientarse.<\/p>\n En los CMS tradicionales, la tecnolog\u00eda CMS les viene impuesta por la soluci\u00f3n elegida. En el Headless CMS son mucho m\u00e1s libres, pero en detrimento del marketing. En el CMS h\u00edbrido no s\u00f3lo no siempre est\u00e1n libres del lenguaje de desarrollo, sino que adem\u00e1s deben dominar dos en lugar de uno solo.<\/p>\n De hecho, deben utilizar diferentes tecnolog\u00edas para construir \u201ccontenido est\u00e1tico\u201d<\/strong> como plantillas de p\u00e1ginas web y para crear experiencias din\u00e1micas<\/strong> (encuestas, cuestionarios, formularios, simuladores, etc.).<\/p>\n Para las empresas, esto a menudo resulta en la contrataci\u00f3n de habilidades variadas y, por lo tanto, en un aumento en el costo de operaci\u00f3n de los sitios web.<\/p>\n Sin mencionar que este problema se extiende a los desaf\u00edos de los creadores de contenido: si bien Headless facilita la reutilizaci\u00f3n de contenido o un componente de un sitio a otro, no es posible reutilizar el c\u00f3digo<\/strong> entre contenido est\u00e1tico y din\u00e1mico en un CMS h\u00edbrido. Sin embargo, la simple reutilizaci\u00f3n de elementos en diferentes p\u00e1ginas y diferentes sitios responde a un problema de productividad que cada vez ocupa m\u00e1s espacio en los equipos web.<\/p>\n Este es, por tanto, uno de los obst\u00e1culos que quedan para la generalizaci\u00f3n de los CMS h\u00edbridos. O mejor dicho \u201clo fue\u201d.<\/p>\n Del CMS tradicional al Headless CMS, de lo que las empresas han estado huyendo en los \u00faltimos a\u00f1os es de la rigidez. Mientras que el primero es demasiado r\u00edgido para los desarrolladores, el segundo lo es para los especialistas en marketing. Con el CMS h\u00edbrido, es la complejidad lo que a menudo falla: proyectos web que tardan a\u00f1os en concretarse, desarrolladores complicados de reclutar, infraestructuras web dif\u00edciles de mantener…<\/p>\n Entonces, \u00bfc\u00f3mo podemos mantener las ventajas del CMS tradicional y las del headless, evitando al mismo tiempo estas limitaciones de desarrollo? JavaScript es una de las claves de una nueva generaci\u00f3n de CMS, igual de eficiente, pero m\u00e1s sencilla.<\/p>\n Por buenas razones, JavaScript se ha convertido en el principal lenguaje de desarrollo web. Es compatible con los principales navegadores, tiene un gran ecosistema de bibliotecas y marcos y tambi\u00e9n se puede ejecutar en el lado del servidor. Cualquier desarrollador que quiera crear experiencias din\u00e1micas aprende JavaScript, que de hecho es la \u00fanica tecnolog\u00eda que permite reutilizar el c\u00f3digo en experiencias est\u00e1ticas y din\u00e1micas.<\/p>\n Por lo tanto, un CMS que permite codificar \u00fanicamente en JavaScript responde a los desaf\u00edos de productividad, disponibilidad de recursos humanos, rendimiento web e incluso creaci\u00f3n de contenidos y marketing. A falta de una soluci\u00f3n tecnol\u00f3gica alternativa, estos objetivos tambi\u00e9n pueden lograrse eligiendo sitios web m\u00e1s refinados, que tengan s\u00f3lo las funcionalidades esenciales para las necesidades de los usuarios. Incluso si no siempre es f\u00e1cil mantenerlo simple.<\/p>\n Como dijo Steve Jobs: \u201c La simplicidad puede ser m\u00e1s dif\u00edcil que la complejidad: tienes que trabajar duro para aclarar tu pensamiento y hacerlo simple. Pero vale la pena, porque una vez que llegas all\u00ed, puedes mover monta\u00f1as.<\/em> \u00bb<\/p>\n<\/div>\nCMS h\u00edbrido, \u00bflo mejor de ambos mundos?<\/h2>\n
Cuando el h\u00edbrido restringe a los desarrolladores<\/h2>\n
JavaScript: mantenlo simple<\/h2>\n