La extinción del perfil de maquetador web

Tras los meses de verano, el inicio del curso en Paradigma ha llegado cargado de nuevos e interesantes proyectos. En previsión de todo este trabajo, durante el mes de julio y agosto hemos desarrollado una intensa labor de selección para ampliar el equipo de Front de Paradigma y poder dar respuesta a las nuevas tareas. Gracias a ello, hemos incorporado personas de gran talento, pero durante este proceso de búsqueda he visto, de forma absolutamente palpable y descorazonadora, una realidad que, aunque ya había ido escuchando en el sector, no había sufrido en mis propias carnes: el perfil de maquetador web ya no existe.

front-enddeveloper

El “mundo” del desarrollo front está viviendo su mejor momento. Gracias al auge de las tecnologías “del lado del cliente” (Javascript sobre todo, pero también HTML5 y CSS3), las single page applications, las progressive web apps, el responsive design, las aplicaciones híbridas (con Ionic o Phonegap), el perfil de desarrollador front (o front-end developer, sin hablar de los full-stack developers) se ha convertido en el más buscado en la gran mayoría de ofertas de trabajo que se publican.

Esto, obviamente, es una muy buena noticia para los que trabajamos en este ámbito. “Tradicionalmente”, el mundo front se reducía al desarrollo en HTML y CSS de las páginas web y a la manipulación del DOM a través de Javascript. Dichas páginas eran posteriormente integradas con la tecnología de turno (léase Java, PHP, .NET, etc).

Este trabajo de front lo realizaba el “maquetador web” y, aunque realizaba un trabajo muy valioso, no tenía mucha visibilidad en la cadena de valor del producto final.

El HTML y el CSS eran tecnologías indescifrables para los programadores. El cross-browser, los “floats”, el “z-index”, la herencia/especificidad y la cascada del CSS, etc, todo eso les hacía huir despavoridos. Sin hablar de Javascript, con su tipado blando, su falta de constructores, la ausencia de compilación… El maquetador era el de “los colorines”, y su tecnología era considerada como el “powerpoint” del stack tecnológico de la época.

maquetador-web

Fósil de maquetador encontrada en el yacimiento de la “Sima de los Divs”.

En la actualidad, como he dicho, el escenario ha cambiado mucho. El front-end es el “tope de gama”. Al olor de estas sardinas han acudido innumerables profesionales de diferentes ámbitos. Al desarrollo front ha llegado mucho programador back (las consecuencias de esto darían para otro post, probablemente muy polémico) “atraídos” por el auge de los frameworks/librerías de Javascript. Estos programadores, que vienen con su bagaje de programación “seria”, para sentirse cómodos con los juguetes del frontal han traído potentísimos frameworks que acercan el Javascript a los lenguajes de verdad, herramientas de compilación/transpilación, de automatización de tareas…

Para poder digerir el CSS (o más bien para encajarlo en sus esquemas mentales de programación) han traído pre-procesadores de diversa índole y completísimos frameworks de CSS que te implementan un grid y el responsive sin tener que mancharte las manos. Y, con suerte, sin tener que diseñar ni hacer UX.

A este panorama también ha contribuido la gran proliferación de startups y las pequeñas empresas de desarrollo, que no pueden disponer de un perfil más específico de front y han creado el desarrollador full-stack.

Tampoco hay que olvidar el bingo de LinkedIn (Angular, React, Node, Polymer… señores, han cantado línea), en el que los perfiles de front tienen más nombres y logotipos de frameworks que el mono de Fernando Alonso y que se venden al peso (un kilo de Angular2, medio de Bootstrap y 300 gramos de Grunt, en filetes y me los haces finitos).

Hay tunos con menos badges que los fronts de hoy en día.

Pues este verano nos hemos pasado las semanas entrevistando maquetador@s que supieran y quisieran maquetar. Que usaran HTML5, CSS3 y Javascript para manipular el DOM. Te preguntarás por qué y la respuesta es muy clara. Porque en Paradigma maquetamos, aunque luego se integre en Angular (o en lo que sea). Porque damos importancia al código limpio y a la semántica. Porque huimos de la “divitis”, del código innecesario y los plugins de terceros “que-hay-que-meter-porque-sí” y buscamos la optimización de nuestro código. Porque menos es más.

Siempre comienzo mis entrevistas de trabajo con una pregunta directa: “¿Cuál es tu punto fuerte en front?” (al grano, vamos) y es descorazonador cuando, en una entrevista con un perfil de maquetación, te responden: “Llevo X años usando Bootstrap”,  y si le re-pregunto, en el mejor de los casos, me dicen que “sólo para el grid y el responsive” o te ponen cara de asombro y te preguntan: “¿Es que no usáis Bootstrap siempre?”.

Y he dicho “quisieran maquetar” porque nos ha pasado que alguien se ha ido de la empresa porque llevaba una semana maquetando y él había venido a programar en Angular. Faltaría más…

Hemos sudado tinta china para encontrar buenos maquetadores. A nuestra oferta han contestado todo tipo de developers con experiencia en una amplio abanico de tecnologías y frameworks de front pero, maquetadores de los que os hablo, muy pocos.

Al final lo hemos conseguido, y estamos muy contentos por haber incorporado nuevo talento al equipo. Pero me queda la triste sensación de que la próxima vez no vamos a tener tanta suerte. ¡Antes todo esto era campo! Ahora son todos supuestos full-stack developers.

O todos hemos sobre-explotado la contratación de maquetadores (y realmente hay legión pero están todos felices en sus respectivas empresas) o es que se ha extinguido ese perfil porque nadie quiere hacer ese trabajo. O podría ser que nadie demande ese perfil y han tenido que evolucionar a arquitectos front. ¿Tú qué opinas?

Luis Calvo comenzó su carrera profesional en Netjuice, a finales de los 90, en pleno "boom" de internet, como maquetador y diseñador web. Experto en el uso de las tecnologías "del lado del cliente" (html, css, javascript, xsl, ...) ha participado en el desarrollo y conceptualización de un gran número de portales, páginas corporativas y aplicaciones web para las principales empresas. Cree firmemente en la accesibilidad web y en el desarrollo bajo estándares.

Ver toda la actividad de Luis Calvo

40 comentarios

  1. Samy dice:

    De haberlo sabido os habria recomendado una y muy buena

  2. OtroFrondEnd dice:

    El tema es complicado, ya que hoy en día se valora más la velocidad que la calidad, y un desarrollador que sepa de todo en un entorno tan cambiante acaba siendo más práctico para una empresa. Me refiero por ejemplo el típico perfil tan demandado estos días: Java 2EE + Angular.js + Bootstrap + loquesea.
    También es mas divertido, porque negarlo.

    Y me surge una duda ¿De verdad se pierde tanto rendimiento utilizando bootstrap?
    Es cierto que menos es más, pero incluso es posible descartar el contenido innecesario como por ejemplo utilizar solo el grid, y mediante compresión, optimización de imágenes, etc se puede conseguir un rendimiento más que aceptable y con un promedio productividad / tiempo dedicado mucho mayor…
    Es como buscar gente que haga el hoyo de la piscina a pico y pala en lugar de con excavadora.. ¿Realmente vale la pena? Un saludo.

    • Luis Calvo dice:

      Los “hombres/mujeres orquestas” son más típicos de los carnavales que de una orquesta filarmónica. Si eres una empresa pequeña con 3 personas (incluido el conserje) que necesita hacer su producto cuanto antes (independientemente de cómo salga), contrata un full-stack de esos que comentas. El pobre se va a divertir, pero la persona que herede su código y tenga que mantenerlo va a pasar muy malos ratos.

      Sobre el uso o no de Bootstrap… si vas a usar sólo el grid de Bootstrap, ¿por qué no hacerlo tú mismo con tu propio CSS? (son 20 líneas de código como mucho). ¿Qué prefieres? ¿hacer un bonsai desde que nace (desde pequeño)? ¿o coger un árbol de 20 metros e ir talando para conseguir un bonsai?. CSS, para un maquetador, debería ser su lengua materna. Un framework CSS es como el translate de Google, viene bien para los que no saben un idioma, pero no puedes fiarte totalmente de él.

      • Jesus dice:

        Totalmente de acuerdo, las plantillas y frameworks como bootstrap a la larga generan más problemas de los que solucionan y te lo dice un maquetador “full stack” de esos de las empresas del conserje.

        Un abrazo

      • Eduardo dice:

        La cosa no es tan simple como Bootstrap sí o bootstrap no, para empezar depende del proyecto, pero no deja de ser un framework(que además te da la ventaja de facilmente incluir sólo lo que necesitas), y como tal tiene la ventaja de que ayuda mucho a trabajar en equipo y a que la persona que venga detrás de ti tenga una rica documentación y un producto bien testado y acogido por la comunidad que le asegure buenas prácticas en lugar de imprevistos, sorpresas e idas de olla.

        Con todos los respetos pero el problema que suele haber con Bootstrap, como con muchas tecnologías que de repente son el mal, es que quien más las critica es quien menos las conoce.

        • Luis Calvo dice:

          Hola Eduardo.

          Yo te hablo de lo que he vivido y de la experiencia que yo tengo. Conozco muchas personas que incluyen siempre frameworks (de css o de javascript o de lo que sea) sin cuestionarse si aplica o si no lo hace. Meter Bootstrap para el grid, en lugar de construirte el tuyo a medida que coincida con tu diseño es el mal, porque si eres maquetador, un grid te lo montas con 15 lineas de css (y sin necesidad de documentar ni necesitar documentación alguna). Si lo tiene que hacer un programador en Java, probablemente no sepa ni lo que es un grid (al igual que yo no sé absolutamente nada de Java). El problema es que, eliminamos la figura del maquetador, para poder tener javeros con bootstrap. Y luego sale el código que sale, claro.

          • Eduardo dice:

            De ahí que depende del proyecto, si el maquetador trabaja solo y va a hacer una maquetación entera que nunca va a cambiar pues bien, pero no suele ser lo habitual, pero ¿qué pasa si trabajan en grupo?, ¿cada quien se va haciendo su propia grid según cada componente que va desarrollando?, ¿y la nomenclatura a seguir?, ¿y si luego se va del proyecto va a saber recoger bien el guante el siguiente, o empezará a hacerse un innecesario código CSS spaguetti? muchas probabilides de tener problemas, en cambio usar una grid de un framework(ya se Bootstrap, Foundation, Material, etc) en cierta forma evita problemas.

            En cualquier caso el CSS de siempre ha dado muchos problemas de mantenibilidad, que han hecho inviables de mantener muchos proyectos, por eso a donde quería llegar es que en mi opinión me parece precipitado descartar a alguien porque use Bootstrap, habría que indagar si realmente lo usa porque no sabe maquetar y le gusta la “magia” que hace o es porque le aporta un extra y luego te maqueta todo ordenado y reutilizable.

            Por otra parte mi experiencia con maquetadores puros es mala, ojo, no digo que no haya buenos maquetadores, pero no he tenido el placer de trabajar con ninguno, y con malo no me refiero a que no sepan maquetar, sino a que sepan estructurar bien, dividir en componentes, usar variables y tener limpio el código, algo que sí he visto más en los híbridos maquetador/js.

            PD: Es sólo mi opinión basada en mi experiencia, que nadie se moleste, salu2!

          • Luis Calvo dice:

            Eduardo, el hecho de que dos maquetadores trabajen en el mismo proyecto no quiere decir que vaya a hacer grids. ¿O es que meten dos bootstrap?. Si varios maquetadores trabajan juntos, como personas sensatas que son, hablan entre ellos y acuerdan la nomenglatura, el grid, se reparten los componentes y ponen en común como se trabaja. No solo los programadores organizan su trabajo, los maquetadores también sabemos.

            Nunca he estado en un proyecto en el que se haya hecho inviable mantener el css, y he estado en proyectos muy grandes, te lo puedo asegurar. Quizá porque en esos proyectos han participado maquetadores y el CSS no tiene secretos para nosotros (y hablamos para no tener que meter varios grids por persona). Nunca he rechazado a nadie por usar Bootstrap, lo que rechazo es el uso de esos frameworks cuando no hay motivo, no a las personas que los usan.

            Siento que hayas tenido que trabajar con maquetadores que programan mal. Pero no está en sus habilidades el hecho de programar. Su función es bien distinta. Un buen maquetador será un nefasto programador porque sus intereses y su formación no van por ahí. Pregúntale a cualquier programador si entiende qué es el float y por qué hay que hacer “clear:both” a ver si te saben contestar. Y eso no los invalida como programadores. Los híbridos siempre tendrán una parte dominante (serán mejores en maquetación o en programación) pero no en ambas. Y a veces hace falta un experto. Si no te gusta la especialización nadie te obliga a hacerlo, pero ser muy bueno en algo (en lugar de mediocre en muchas cosas) es muy gratificante, te lo aseguro.

    • Nacho Igleisas dice:

      y donde dejas el diseño personalizado, y una experiencia de usuario optimizada al máximo para tu web/app/producto??,

      y no me digas que con cualquier framework se puede hacer por que no es cierto, además de tener 80 librerías de js para hacer cualquier cosa.

      La singularidad de una web/webapp/app no te la va a dar un framework que utilizan el 70% de las webs, sino un diseño personalizado, y estudiado y una maquetación acorde, personalizada y estudiada. Seguro que con bootstrap tienes un producto rápido (perdón, el producto será lento, aunque lo crearás rápido), pero también es seguro que será igual que el de los demás.

  3. Gabi dice:

    El problema de la maquetación era que “todo valía” y ahora por suerte los navegadores lo van aguantando todo…
    Hubo un tiempo que tuve que “ilustrar” los problemas IE con quirk mode y que afectaba incluso al JavaScript.. todo por un mal uso del HTML y me miraban asombrados (y no hace tanto de esto).
    Y cuando haces un mal uso de la cascada o te planteas utilizar metodologías BEM o las que sea… como si hablaras en chino, eso sí Bootstrap, materialize, fundation o themes de WordPress los que quieras pero sin saber lo que hay detrás.

    Fast food (or code) frontender y se termina siendo full stack

    • Luis Calvo dice:

      El trabajo de un maquetador nunca ha sido fácil. Antes eran los navegadores, ahora son los múltiples dispositivos… Por eso digo que es tan importante un perfil específico de maquetación. Porque un programador back sabe de muchas cosas, pero de esos temas huye como de la lepra (aunque en su CV ponga que es experto en HTML y CSS, si sabe Java cómo no va a saber de esos “lenguajillos” de niños)

  4. Oscar dice:

    Me alegra ver que existen empresas que cuidan este aspecto. Estoy de acuerdo con que es un perfil que cada vez cuesta más encontrar, en mi opinión esto ocurre porque se considera un perfil bajo o de poco conocimiento técnico (error) y que va acompañado de un sueldo bastante inferior a otros perfiles más especializados en frameworks de moda como React o Angular. Es por ello que la gente “huye” de esta especialidad que, a título personal, me encanta! Después de leer este post me considero más viejo! Saludos y enhorabuena por el artículo

    • Luis Calvo dice:

      Gracias por tu comentario Oscar. En otros sectores, las empresas grandes intentan reducir costes mediante automatización de sistemas productivos (producción en cadena de los productos) y las pequeñas empresas, para poder competir, ofrecen trato cercano, productos naturales/biológicos, o hechos a mano, muy personalizados, únicos….

      En nuestro sector pasa al revés. Las pequeñas empresas fusilan plantillas, usan frameworks conocidos y automatizan todo (hacen aplicaciones webs como churros, todas iguales) y son las grandes empresas las que ofrecen la personalización, el mimo al producto y el trato cercano. Es paradójico pero es así.

  5. Wakkos dice:

    Nah, no desaparecemos los maquetadores, nos cambiamos el nombre a UI Developers o CSS Architect.

    ;)

  6. Federico dice:

    Soy de argentina, particularmente me encanta la parte de maquetado y construir mis propios sitios o apps web desde cero, cuidando la semántica, el orden y la limpieza. Pero lamentablemente eso tampoco es lo que se busca en el mercado, ojalá lo valoraran como lo hacen ustedes, pero no sucede, tan solo piden un sinfín de tecnologías.

    Ojalá hubiera empresas como ustedes acá que buscaran ese tipo de perfiles, ¡estaría encantado en postularme!

    Excelente artículo. ¡Saludos!

  7. Mónica dice:

    Me alegra mucho saber que todavía se valora el perfil de maquetador puro y duro, porque parece que si ahora no sabes de todos los frameworks/tecnologías(node.js, handlerbars, bootstrap, angular, react, ssas, less…) no tienes ninguna opción en el mercado laboral. Personalmente, bootstrap me ha ayudado a saber como manejar opciones responsive pero es cierto que ensucia y carga demasiados estilos y js que luego hay que sobreescribir. Gracias a él ahora puedo hacer una maquetación responsive sin tener que usarlo.
    Hay cosas que te pueden ayudar y como todo hay que saber usarlo todo en su medida… El uso de ssas o less, handlerbars,…. te pueden facilitar el trabajo.

    Muchas gracias por pedir perfiles que ya no están de moda.

    • Luis Calvo dice:

      Gracias a ti por el comentario.

    • Carlos dice:

      Yo lo que menos soporto de Bootstrap es que mucha gente lo considera “un estándar” y crea herramientas, plantillas y un sinfín de cosas “compatibles con Bootstrap” o chorradas así. El estándar es el del W3C, no otro. Y su filosofía y su nomenclatura de clases es bastante debatible.

  8. Nadal dice:

    Luis, me veo super reflejado en muchas de las cosas que cuentas.

    He de decir que siempre he tenido la sensación de que el perfil de “maquetador”, o como a mi me gusta decir de “visual frontend developer”, no se valora lo suficiente. Aunque me encanta mi trabajo a menudo me pregunto si mi perfil está obsoleto, incluso si debería abandonarlo por completo y lanzarme al loco carousel de “fullstack development©”” del que tanto se habla y se demandan profesionales (en muchos casos, dicho sea de paso, sin tener demasiado criterio en lo que se pide por parte de “recruiters” y empresas). El clásico “por pedir que no quede”.

    Aunque me gusta aprender nuevas tecnologías sé que nunca llegaré a ser un gran programador porque, entre otras cosas, no es lo que más me gusta. Siempre he defendido que estar especializado en algo es bueno porque quiere decir que lo que haces lo haces bien. He tenido la suerte de trabajar con maquetadores, frontend developers, frontend engineers, backend developers, devops, full-stack developers… y he de decir que sólo el primer grupo está vacunado contra la “itis”, la “frameworkitis” y otras “itis” (mil gracias al “gran mestre” Jordi Touza por el antídoto).

    Con esto no quiero decir que no existan fullstack developers talentosos (conozco algunos), pero según mi experiencia la mayoría no maquetan correctamente: ya sea porque vienen del mundo backend, ya sea porque son jóvenes y no han tenido que lidiar con IE, “quirksmode”, conexiones lentas, absencia de frameworks, y un largo etc… O bien simple y llanamente porque no les gusta maquetar o no se les da bien (de la misma forma que existen programadores brillantes también existen maquetadores excelentes, QAs cojonudos, etc…). Para mi ninguno de estos perfiles es mejor que otro, ni más ni menos valuoso (aunque el mercado, una vez más, castigue con importantes diferencias salariales), pero si son raramente comunes en un mismo individuo.

    Respondiendo a tu pregunta final no creo que este perfil se esté extinguiendo, pero si creo que está cambiando a marchas forzadas. También creo que debemos hacer lo posible para adaptarnos a las nuevas herramientas y demanda actual, siempre y cuando esto nos haga crecer a nivel profesional y sin dejar de hacer las cosas lo mejor posible.

    Felicidades por el artículo!

    • Carlos dice:

      Aquí otro maquetador al que le apasiona maquetar (saber por qué hay que usar X etiqueta y no otra) y también tiene esas mismas dudas… Me alivia saber que no estoy solo :p

  9. freinn dice:

    Javascript es un lenguaje compilado. Se puede interpretar y de hecho cualquier consola de navegador lo hace, pero eso de ausencia de compilación en JS es un error garrafal.

  10. Zuri dice:

    Luis, solo te dire una palabra, GRACIAS! Por seguir liderando a los maquetadores y a los artistas del css alla donde vas. Nos conocimos en el primer meetup de frontenders de madrid, y saber que aun quedan maquetadores es increible. Hoy en el polymer day, he defendido la maquetacion y las css sobre todos los frontender fullstack que habia y creo que he salido victoriosa. Espero que nos veamos pronto y charlemos. En el codemotion de este año, por ejemplo. Un saludo

  11. Tastafur dice:

    Hola Luis Calvo

    Yo no sabría como definirme me gusta y maqueto, desde IE6, hasta te hago un api REST.

    Me encanta programar suelo programar en front, maquetar o hacer cosas de back.

    Ahora por ejemplo estoy viendo perfiles que les gusta especificarse o acomodarse, es mi opinión. Conozco el caso de un maquetador/diseñador que le da mucho por saco enfrentarse a componentes de react pero el a elegido maquetar y no aprender mucho más pero si quejarse de que tarda mucho más en vez de aceptar o aprender por donde van las tecnologías.
    A mi me gusta maquetar pero mi criterio nunca va a ser muy allá a la hora de que las cosas queden bonitas tendré mi punto de vista pero no es mi especialidad y en ese caso se quien debe dar su criterio o ver como quedaría mejor hasta donde yo sé es el diseñador ilustrador, ux o ui. Entiendo que yo puedo programar plasmar lógica, usar patrones de programación sea el lenguaje que sea… y el tipo de paradigma que sea como si es funcional… pero no me puedo salir de ahí puedo aislar mi función y lo que más me gusta es el front. Lo que acaba mezclándose son los maquetadores/diseñadores aveces y no sale muy bien eso. Por que no acaban de valorarlos y son super importantes igual que cualquier otro elemento del producto en vez de ser billetes que veo que pasa mucho.
    ¿que opinión tenéis vosotros?

    Un saludo

    P.D: Paradigma o sea vosotros me habéis intentando reclutar pero me salió algo muy guay asique lo siento

  12. jescacena dice:

    Genial tu artículo Luis!

    En mi humilde opinión que haya full stacks , programadores back metidos en front, frameworks css/js, etc no es otra cosa que una consecuencia de lo que demanda el mercado. El javascript ya no se usa solo para validar formularios , los clientes piden aplicaciones complejas en front y en base a eso han surgido nuevos frameworks y perfiles más polivalentes.

    Otra cosa es la divitis , el html/css mal tirado, etc que no creo que esté peleado con ser full stack o venir del mundo back , simplemente depende de la experiencia del candidato el que lo sepa hacer mejor o peor.

    Ser especialista en HTML/CSS o ser frontend developer no especialista en nada pero polivalente, no creo que sean ninguno de los dos perfiles que haya que desechar porque ambos pueden resolver proyectos front con calidad. Miguelangel era especialista en pintura y Leonardo Da Vinci era polivalente … y los dos pintaban bien!.

    En resumen me sumo al llamamiento de Luis de cuidar el HTML/CSS de los proyectos pero no creo que por ello haya que demonizar nuevas tecnologías y nuevos perfiles.

    Saludos!

    • Luis Calvo dice:

      Gracias Javier, no estoy en contra de los full stack de verdad, sino de los que lo simulan. Simplemente creo que hay más interés y ruido en temas de Javascript y frmaeworks chulis y estamos perdiendo el foco en el HTML/CSS.

  13. Nacho Navarro dice:

    Luis… eres un grande de entre los grandes y el artículo enamora.

    A mi me gustaría añadir que me da la sensación que CSS y su ecosistema ha evolucionado correctamente. Dándonos herramientas para poder obtener resultados más complejos con menos esfuerzo. Sin embargo, el ecosistema de JS no para de generar frameworks y adaptar paradigmas de programación más complejos, muchas veces, para generar las mismas app que se llevan generando años.

    Soy (era) Javascripter hasta la médula, me encanta seguir creciendo y tener nuevos y apasionantes frameworks, programación reactiva, etc… Creo que nos lo hemos montado muy bien para tener mucho curro y sueldos cada vez más altos, pero no se cuanto durara esta burbuja y hasta cuando esta escalada le será rentable a las empresas. ¿Volverán entonces los maquetadores puros?

    Un saludo.

    • Luis Calvo dice:

      Gracias por el cumplido Nacho, viniendo de alguien como tú es todo un honor.

      Creo que el ecosistema Javascript es tan absolutamente cambiante gracias a la sencillez (aparente) del lenguaje. Mucha gente, al usar un MVC en Javascript piensa “Esto me lo monto yo de cuatro patadas” y se ponen y lo hacen. Es la “democracia” del lenguaje. ¡Por eso hay tantos! En otras tecnologías, montarse un framework es una tarea titánica solo realizable por equipos enormes.

  14. Felipe Alonso dice:

    Me ha gustado el artículo, muy atractivo… el artículo Luis.
    No creo que los maquetadores desapareciesen, creo que, al igual que los diseñadores, los puros y los de imprenta, han tenido que reciclarse para ser más competitivos, para tener más opciones, para poder hacer más con el mismo y probablemente por amor propio, por amor al arte y por amor al código.
    En este mundo hipertrofiado de dispositivos con infinidad de resoluciones, densidades y navegadores ser diseñador puro o maquetador puro es golpearse contra un muro de píxels background:transparent. Tienes que ver más y es lógico que así sea.

    Un buen maquetador querrá que su código fluya por la pantalla en modo responsivo, modificando elementos para que cuadren perfectamente con la funcionalidad adecuada al dispositivo, transformando y terraformando si es necesario toda la interface.
    Esto te lleva a las fronteras de la maquetación más pronto que tarde y es en ese momento cuando decides asaltar HTMLs en llamas más allá de W3C. Esto te lleva a otro perfil profesional, a atravesar la puerta Tannhäuser que separa todos los perfiles profesionales.
    Y si eres un profesional medianamente curioso y como mínimo temeroso de tu futuro laboral, fluirás como las lagrimas en la lluvia o morirás en el intento.

    Y esto es una pena porque te hace perder el foco de la maqueta basica y evolucionar con ella por las diferentes tecnologías que nacen y mueren a diario.
    No todo el mundo quiere o puede pasear por territorios frontend, es otro universo paralelo que no necesariamente es comprensible solo porque mires directo a los punto y coma.

    Aprendí a maquetar porque estaba cansado de ver mis diseños destrozados por programadores backend, – y porque Flash se moría – pero nunca atravesé la puerta del frontend aunque me quedé bailando bajo su quicio.
    Esos conocimientos me permiteron ser mucho más preciso y efectivo en el diseño.

    Como Nacho Navarro pienso que esto es una burbuja que finalmente acabará por explotar o convertirnos en “full stack 360 master class developer system” o en su defecto “full growth hacker of mercy” – por favor entiendan la ironía – pero un maquetad@r sabrá sobrevivir al impacto porque la MAQUETACIÓN es a la web lo que el ADN a la vida.

  15. May Allidem dice:

    Muy buen artículo y un gran debate que se viene mascando desde hace tiempo. A mi me afecta directamente y creo que “no se paga la calidad” con que hagas la base, sino la cantidad de trabajo que saques. “Ser especialista en algo no es rentable”. Además, como dices, no es una profesión que se le haya valorado nunca, lo cual ayuda a que esta situación se dé y en su defecto se vaya perdiendo. Pero también es cierto que los lenguajes van evolucionando, cada proyecto tiene unas necesidades y las prioridades son totalmente distintas, con lo que en unos se hará más hincapié en maquetación y en otros no tanto.

    En definitiva, todo es posible… es posible que desaparezca definitivamente, es posible que sea solamente una pausa, es posible que evolucione a otro perfil… ¿quién sabe?. A la velocidad que van las cosas como para saber que es lo que pasará dentro de 1 año. :)

  16. Sergio dice:

    Lo primero de todo, te felicito Luis por el artículo, que expresa las inquietudes que a más de un maquetador se nos ha pasado por la cabeza viendo las demandas (mejor dicho “sobre-demandas”) del mercado.

    Quién escribe este comentario tiene experiencia trabajando de diseñador, full stack y finalmente maquetador(me encanta) y mi opinión es que si amas tu trabajo y crees en la satisfacción del trabajo bien hecho, se hace necesaria la especialización. ¿Por qué? Primero por que no dispones de todo el tiempo y ganas para abarcar todas las novedades del sector y segundo que la propia evolución de las tecnologías te obliga a “aislarte”, es decir dedicarte de lleno a las áreas en la que destacas por tus capacidades e intereses y más si quieres ser un profesional de la materia y no un chapuzas.

    Está bien aprender de otras áreas porque ayuda a tu propio trabajo pero el sueño de muchas empresas del hombre orquesta y que sea barato solo es posible si no te importa la calidad de tu producto. Y las tecnologías de ahora evolucionan a un nivel cada vez más profundo, en el caso de html + css no hablamos de 4, 5 etiquetas ni de “colorines”, hablamos también de accesibilidad, usabilidad, mejora progresiva,, web perfomance, rwd, escalabilidad, seo, patrones, etc…

    Por cierto, estaría bien otro posts donde el debate fuese el daño que se está haciendo al ecosistema de JavaScript con tanto “hype” de frameworks de ahora éste si y mañana no. El problema es que hoy en día en lugar de hacer hincapié en reforzar la lengua base(html + css, js o el lenguaje que sea) se hace mucho marketing de los frameworks, que son una herramienta, no la sustitución del lenguaje.

  17. Eliana dice:

    Yo soy maquetadora web, y me encanta. Pero en este momento estoy buscando de eso y no hay, todos piden que sepa desarrollar. Me obligan a cambiar de rubro.

  18. Nacho Romo dice:

    Hola Luis, he llegado por casualidad a este blog y me he visto obligado a responder ya que, por desgracia, me veo tremendamente reflejado.

    Verás, yo empecé mi viaje como programador, pero en menos de un año trabajando en web, me di cuenta que lo que realmente era mi vocación era la maquetación y el diseño.
    Llevo 10 años trabajando de maquetador, y me duele ver que el 99% de las ofertas de trabajo son para desarrolladores full-stack. En mi caso, viviendo en Sevilla, es peor aún, créeme.

    No se valora la calidad del trabajo, sino la velocidad en la que se sacan los proyectos, las empresas piden a los maquetadores, no solo que sepan de diseño, HTML y CSS y vale, añadiremos jS, ahora piden angular para desarrollo de aplicaciones (¿desarrollo de aplicaciones?, soy maquetador, no programador), piden node.js, se valoran conocimientos de php…

    Ok, buscáis un chico para todo pero pagando 1 sueldo único, y además, pagando sueldo de maquetador que, parece ser, somos lo más prescindible según los empresarios, ya que “solo hacemos dibujitos” y “cambiamos los colores de las letras”.

    En una entrevista me preguntaron cómo haría para conectar con una base de datos Oracle, le respondí que yo me había presentado a un puesto de maquetador a lo que me respondieron que sí, pero que también tendría que ayudar al equipo de desarrollo con algunas cosillas.

    A día de hoy trabajo en un buen sitio donde se me valora, el pero es que trabajo maquetando aplicaciones en entorno web para empresas y no paginas web, con lo que mi trabajo no se puede mostrar.
    La verdad es que empresas como la tuya escasean y sinceramente, si pensáis en abrir una sede en Sevilla o permitís trabajar a distancia, no me importaría tener una entrevista con vosotros.

    Me alegra ver que hay gente que sigue pensando que para hacer una web responsive no hace falta la ayuda de bootstrap entre otras muchas cosas.

    Un saludo de un maquetador no full-stack.

  19. Camila dice:

    Hola, soy estudiante, no me falta mucho para terminar, espero que no se extinga porque es la rama a la que me quiero dedicar :(

  20. Antonio dice:

    Buenas,

    Tengo sentimientos encontrados sobre lo que dices. En la empresa en la que estaba anteriormente era el único maquetador web (con perfil híbrido ya que he también he hecho /hago backend pero allí sólo hacía maquetación) y me sentía poco valorado por los jefes porque no tenían mucha idea de frontend y no entendían que la maquetación “artesanal” era más proclive a fallos (pruebas y detección de errores, crossbrowsing, etc) que la lógica del backend para esa misma pantalla que se estaba maquetando.

    A pesar de eso, y es aquí donde entro en conflicto con lo que escribes, creo que el uso de un framework como bootstrap aporta más ventajas que inconvenientes. De hecho, fui yo quien al ver el problema de tiempos que tenía a la hora de maquetar entre lo que se estimaba y lo que ellos esperaban propuse en la empresa el uso de bootstrap.

    El que se usen este tipo de frameworks no están reñido con que la web pueda ser optimizada a nivel frontend, de hecho, esa es una de las cosas que más me desmotivan sobre lo que piden las empresas actualmente, prefieren la velocidad en la entrega del producto que la calidad de lo que se entrega. Y, de la misma forma que muy pocas utilizan los test (frontend, backend) correctamente si no más bien para tener un % de cobertura de código, en el frontend no se utilizan herramientas como gtmetrix (probad a pasársela a 5 webs cualesquiera y observad la puntuación) que te den inputs sobre como mejorar el rendimiento de la web a nivel de frontend (número de peticiones al servidor, peso de la web, uso de css sprites, habilitar gzip, optimización de imágenes, uso de cdn, etc…).

    Lo que quiero decir es que maquetar desde 0 una web (html + css) teniendo herramientas que agilizan ese proceso es como hacer el backend sin utilizar ningún framework.

    El problema no es el framework en sí (que también, porque no es lo mismo bootstrap que otras herramientas que te generan el html desde un panel visual con la divitis que mencionas) si no la importancia que se le de a la calidad del producto entregado por encima del tiempo de desarrollo y a la cultura de la empresa en ese sentido.

    Saludos

    • Luis Calvo dice:

      Hola Antonio

      Seguramente ya lo habrás visto, pero si no lo has hecho te recomiendo esta charla de Belén Albeza sobre el uso de framework CSS -> https://youtu.be/kED5eDjMfGM porque resume perfectamente mi opinión al respecto.

      Un saludo

      • Antonio dice:

        Hola Luis,

        Ya lo he visto (no lo había visto antes) pero lo cierto es que estoy bastante en desacuerdo, el peso de la librería es justificable sobre lo que agiliza los tiempos de maquetación y homogeneidad de la misma (vuelvo a insistir en el simil entre usar frameworks de backend y hacer la programación partiendo de 0).

        Sobre los inconvenientes de usarlo (además del supuesto peso, ya que comprimido con gzip el peso del css es ínfimo) te sugiero un curso de codeschool https://www.codeschool.com/courses/blasting-off-with-bootstrap donde exponen una series de bests practices para agilizar el workflow además de solucionar algunos problemas que le véis (como no necesitar el uso del !important para sobreescribir sus reglas).

        Interesante debate en cualquier caso ;)

        Saludos

        • Luis Calvo dice:

          Es muy probable que, en ocasiones muy concretas (empresas o equipos muy pequeños, en proyectos en los que la apariencia gráfica coincida con la de Bootstrap o les dé un poco igual dicha apariencia, en proyectos en los que no se quiera poner atención en el cómo está hecho y solo les importe salir a producción… etc) esté justificado el uso de frameworks de terceros. Pero teniendo un perfil de front, usar un framework es infrautilizar a ese maquetador. Si no lo tienes (empresas pequeñas, por ej) un programador, con Bootstrap puede maquetar una aplicación sencillita sin tener ni idea de CSS y “resolverte la papeleta”.

          Sobre lo de tener que usar buenas prácticas para desarrollar en Bootstrap… prefiero usar buenas prácticas en CSS (ITCSS, BEM, OOCSS, la que más te guste) y hacer el CSS que a mí me gusta y con el que me siento a gusto y que cumple mis estándares de calidad. Y Bootstrap para los programadores back que ni saben ni quieren saber maquetar (porque lo suyo está en “el otro lado”)

          Sobre tu metáfora entre “framework” de front y de back, creo que estás mezclando cosas que no son equiparables. Un framework de back es una herramienta indispensable para poder desarrollar. Te genera el entorno, la arquitectura, etc. Por lo general dichos frameworks orquestan todas las piezas de un proyecto a nivel back (java por ejemplo). Es impensable hacer un proyecto Java sin usar Spring o el framework que sea. Pero Bootstrap es un fichero css y otro js que no necesitas obligatoriamente. Es que si te compras una plantilla de esas que hay por 9€ no necesitas ni Bootstrap.

          • Antonio dice:

            Bueno,

            Quizás estés en lo cierto, yo te hablo desde mi propia experiencia, habiendo trabajado como único maquetador de una empresa pequeña (maquetando de 0 y luego usando bootstrap) y en empresas como miembro de un equipo de más de 20 frontends (con grid propia).

            Desde mi punto de vista, e independientemente del proyecto, el uso de un frameworks es beneficioso por los siguientes motivos:

            – Normalmente está hecho por gente muy capaz, testeada y aportándote la gran mayoría de componentes que vayas a necesitar.
            – Gran comunidad donde preguntar y solucionar problemas con los que posiblemente otro se haya encontrado antes que tú.
            – Agiliza enormemente los tiempos de maquetación de un diseño.
            – Al ser algo de uso tan común, facilita la curva de aprendizaje de gente nueva en el equipo e incluso permite al equipo back participar en el proceso de maquetación (aunque luego tú como maquetador experto puedas corregirlo sobre la marcha).
            – Sobre el diseño, deberíais ver los ejemplos que hay en la propia página web de bootstrap, por el simple hecho de usar la misma grid no significa que todas las webs tengan que ser iguales.
            – Orientado a mobile first, responsive y con breakpoints configurables desde scss.

            Por contra, y ahí si estoy de acuerdo contigo:

            – No es todo lo purista que debiera a nivel semántico (aunque tu puedes ir cambiando los elementos a medidas que vas añadiendo los componentes).
            – Al no utilizar todos los componentes, puedes tener css que no vayas a utilizar (insisto en el bajo peso del fichero comprimido).

            Sin embargo, al hacer uso de tu propia grid, estoy de acuerdo contigo en que:
            – Puedes hacer una maquetación más semántica y limpia reduciendo el peso del .css

            Pero por contra:
            – Tienes que encargarte tú mismo de testear todo el css que añades, tanto a nivel de crosbrowsing como de responsive (revisar breakpoints, etc), aumentando enormemente los tiempos.
            – Alta curva de aprendizaje para todo aquel que entre en el equipo y no sepa la nomenclatura utilizada en el css.
            – En definitiva, reinventar la rueda cada vez que te enfrentas a un proyecto nuevo cuando puede utilizarse una herramienta 100% probada y extenderla o modificarla según tus necesidades en cada proyecto.

            Sobre el simil del framework backend, lógicamente es salvando la distancias, pero no sería la primera vez que veo crear un cms partiendo de 0 habiendo buenas herramientas gratuitas o incluso crear un framework propio.

            Entiendo tu postura como purista y gusto por la perfección, pero lo que tengo claro es que utilizar un framework como bootstrap no es mala opción ni mucho menos y que el uso de éste no implica que la aplicación resultante tenga que estar poco optimizada a nivel de frontend.

Escribe un comentario