Estás leyendo la publicación: Una introducción a los marcos frontend
Los frameworks frontend aparentemente han conquistado el mundo del desarrollo web en los últimos años. Cualquiera que opere como desarrollador, diseñador, programador o arquitecto web, especialmente aquellos nuevos en este juego y aún más aquellos que solo trabajan en el diseño web como un pasatiempo en lugar de un rol de tiempo completo, sabrán muy bien el ritmo al que se mueve esta industria. Mantenerse al día con la implacable velocidad a la que se lanzan nuevas tecnologías y se actualizan las tecnologías antiguas es una de las tareas más cruciales y críticas que cualquier persona en esta industria debe emprender. No hacerlo durante más de unos pocos meses hace que nos sintamos perdidos en un mar de información, incapaces de consumir a un ritmo más rápido que la producción tecnológica. Una vez que estás fuera de contacto, es difícil volver a estar en contacto.
Y esto nos lleva a los marcos frontend; Podría decirse que es uno de los desarrollos más básicos, pero genuina y técnicamente beneficiosos, que la industria del desarrollo de sitios web ha visto en los últimos tiempos. (Por cierto, cuando decimos ‘industria’, nos referimos tanto a profesionales como a aficionados… es una industria rara que no distingue entre los dos, pero la nuestra es una de ellas).
¿Qué son los marcos frontend?
Posiblemente los conozcas como Bootstrap o Foundation. Estos son los dos marcos frontend más populares, pero hay muchos más que discutiremos más adelante en esta publicación de blog.
Los marcos frontend en sí mismos no son nada nuevo. En su forma más básica, no son más que un conjunto predefinido de clases de CSS y funciones de Javascript para que un desarrollador las utilice rápida y fácilmente. Algunos son incluso más básicos, ya que eliminan el Javascript y solo son una lista de clases de CSS.
Esta técnica de predefinir piezas de marcado para su reutilización con el tiempo ha existido durante muchos años, pero la mayoría de las veces en privado, ya sea una agencia que ha creado sus propias clases, bibliotecas y funciones para acelerar la producción, o un aficionado que quería trabajar de manera más inteligente, en lugar de más duro. La diferencia ahora, por supuesto, es que los marcos frontend se han hecho públicos, se han generalizado y se han vuelto accesibles para las masas.
Una de las claras desventajas de un marco interno desarrollado de forma privada fue el trabajo preliminar que se necesitó para desarrollarlo en primer lugar. Claro, les ahorró tiempo y esfuerzo a esas personas a largo plazo (y no tengo dudas de que valió la pena a largo plazo), pero ese trabajo preliminar inicial para crear un marco interno fue (y sigue siendo, si creas el tuyo propio) lo suficientemente importante como para ser considerado un flujo de proyecto separado en sí mismo.
Sin embargo, un marco público, convencional, accesible y predesarrollado, como Bootstrap de Twitter o Foundation de ZURB, le quita este trabajo inicial al usuario y lo coloca en manos de los propios desarrolladores del marco. Así que ahora los marcos, un concepto desarrollado principalmente de forma privada para acelerar el desarrollo interno, han ayudado a los desarrolladores web a ser aún más eficientes gracias a un grupo de personas amigables cuya función es desarrollar marcos para aquellos de nosotros que no solo carecemos de tiempo para escribir todo el marcado desde cero (primer problema), sino que también tenemos poco tiempo y ni siquiera podemos escribir nuestro propio marco para resolver el primer problema. ¡Inteligente e increíblemente útil!
¿Por qué usaría un marco frontend?
Los marcos frontend tienen una variedad de beneficios, que se centran principalmente en ayudar al desarrollador a acelerar la producción y reducir los errores a lo largo de la etapa de desarrollo de marcado de todos los proyectos de desarrollo web frontend.
Velocidad y Simplicidad
El objetivo principal de los marcos frontend siempre ha sido acelerar la producción para el desarrollador, reducir costos, aumentar el rendimiento y hacerlo manteniendo la sencillez, concisión y claridad incluso para los desarrolladores web más novatos. Todo buen marco frontend logra este objetivo, lo que permite a aquellos que no están familiarizados con el marcado retomar y aprender rápidamente las clases y funciones definidas con un mínimo esfuerzo.
No hay nada más frustrante que hacerse cargo de un sitio web que no desarrolló y tener que pasar días, o posiblemente semanas, familiarizándose con el marcado de los desarrolladores anteriores. Todos tenemos una escritura a mano única, y el marcado HTML, CSS y Javascript es el mismo. Cada desarrollador web tiene su propia firma única; su propia forma de estructurar el marcado y sus propios enfoques para corregir errores comunes. Un marco público común resuelve este problema de inmediato, ya que la estructura y la firma del marcado no son definidas por el usuario final, sino por los desarrolladores del marco, y son reconocidas en todo el mundo.
Podría entrar en cualquier empresa, en la oficina de cualquier aficionado, en cualquier agencia, y siempre que usaran uno de los marcos enumerados en este artículo, podría reconocer, comprender y, lo que es más importante, sentirme cómodo con su marcado en unos pocos minutos. Ese es el beneficio de un lenguaje común respaldado por una estructura común y un conjunto común de reglas para lograr objetivos comunes. Sin un marco, o con un marco desarrollado internamente, este beneficio no existe. En cambio, los desarrolladores están atascados tratando de familiarizarse con el marcado heredado durante los primeros días o semanas de cualquier proyecto que emprendan de una persona anterior.
Compatibilidad receptiva entre dispositivos integrada
En un mundo en el que la mayoría del tráfico de Internet a los sitios web en el mundo occidental proviene de un dispositivo portátil, ya sea una tableta o un teléfono inteligente, hay muy pocas excusas para no satisfacer este mercado con un sitio web receptivo. Desarrollar una hoja de estilo receptiva para todos los dispositivos y tamaños de pantalla requeridos puede ser complicado de dominar desde cero. ¿A qué resolución de pantalla debería activarse el CSS del paisaje del teléfono inteligente? ¿Qué hay del retrato de teléfono inteligente? Y no se olvide de la tableta horizontal y vertical. Y resoluciones extragrandes vistas en algunos televisores y pizarras inteligentes. Y dispositivos con pantallas retina. ¿Sabe cuál es el punto de corte de ancho para todos esos dispositivos y escenarios potenciales para permitirle dirigirse a ellos individualmente con CSS? Algunos de ustedes pueden. Muchos otros no lo harán.
Si bien es útil investigar y saber (lo recomiendo encarecidamente), solo la idea de tener que escribir la plantilla de la hoja de estilo para apuntar a todos esos escenarios me hace temblar.
Sin embargo, hay buenas noticias. La mayoría de los marcos frontend están diseñados para ser receptivos, para expandirse y contraerse con gracia para cualquier dispositivo y cualquier resolución de pantalla.
Por ejemplo, la capacidad de ocultar y mostrar diferentes contenedores en diferentes tamaños de pantalla no es más que agregar una clase a su
Marcado previamente probado
Puede estar seguro de que el marcado contenido dentro de cualquier buen marco de front-end ha sido probado y ha pasado un conjunto riguroso de criterios antes de que se firmara y se le entregara a usted, el usuario final. Los errores comunes y no tan comunes ya han sido identificados, evaluados y resueltos, lo que le deja muy poca corrección de errores para hacer a lo largo de su proyecto.
El proceso de toma de decisiones se simplifica
Al desarrollar sitios web, a menudo el aspecto que consume más tiempo no es escribir marcas, sino tomar decisiones con respecto a la funcionalidad a medida que codificamos. Incluso los mejores diseñadores a veces dejan elementos abiertos para que el desarrollador los interprete, por lo que tomar decisiones sobre si tener un encabezado fijo, una barra de navegación deslizante o un pie de página fijo a veces puede recaer en nosotros mientras codificamos.
Sin un marco, implementar algunos de estos llevaría mucho tiempo y potencialmente no tendría sentido, si decidiéramos usar un método diferente después de haberlo construido y visto que funciona. Sin embargo, con un marco de front-end, activar elementos como barras de navegación deslizantes, encabezados y pies de página fijos y otros elementos interactivos, así como botones de estilo y proporcionar efectos de desplazamiento suave, es tan simple como agregar una lista definida de clases a los elementos correctos en su marcado. Ahora, crear una barra de navegación con botones con estilo, un menú desplegable y un encabezado fijo es un trabajo de cinco minutos en lugar de un trabajo de más de 30 minutos.
Documentación detallada y amplia red de soporte
Como discutimos anteriormente, los marcos son muy útiles cuando tiene la documentación que lo respalda. Es una herramienta inútil sin la documentación que explique la estructura del marco y las clases y funciones disponibles para que las utilice. Afortunadamente, todos los buenos marcos frontend vienen con una excelente documentación, y la mayoría viene con una fantástica red de soporte comunitario, compuesta tanto por desarrolladores del marco como por usuarios finales experimentados.
Los defectos de los marcos frontend
Hay muchos beneficios de usar marcos, pero también hay fallas. No sería correcto discutir uno sin señalar el otro, por lo que a continuación discutimos algunos de los problemas que los marcos pueden generar en la mezcla.
Dificultades de personalización
Si bien los marcos y su estructura y reglas comunes a lo largo del marcado pueden ser positivos de varias maneras, este mismo beneficio también puede convertirse en una falla cuando intenta personalizar en gran medida un sitio web utilizando un marco.
Los marcos deben tratar de encontrar un equilibrio entre proporcionarle elementos listos para usar y, al mismo tiempo, no bloquear la funcionalidad y la capacidad de personalización de estos elementos. A veces, este equilibrio no se encuentra y terminamos usando funciones y clases que ya están diseñadas para nosotros y programadas para funcionar de una manera específica. Desviarse de esto es a menudo bastante difícil. Esto nos lleva al siguiente defecto.
El potencial de los sitios web para tener el mismo aspecto
Con la lucha por personalizar elementos específicos de los marcos, siempre existe la posibilidad de que los sitios web tengan el mismo aspecto. Si bien es absolutamente posible personalizar el diseño de todo el sitio web y de cada página individual, los elementos de esa página podrían (y probablemente lo harán) tener un aspecto similar al de otros sitios web. Por ejemplo, Bootstrap tiene botones prediseñados. Si bien es rápido y fácil cambiar los colores de estos para que coincidan con su sitio web, lleva más tiempo comenzar a cambiar el estado de desplazamiento, la animación y el efecto degradado. La mayoría de los usuarios finales de un marco solo cambian la configuración de estilo básica, como las fuentes y los colores, lo que deja otros estilos más sutiles en su lugar según el marco predeterminado. Es posible que no note esto demasiado, pero le garantizo que una vez que haya visto un botón de estilo Bootstrap o Foundation, y haya tomado nota de los efectos de desplazamiento y transición, comenzará a detectarlos en Internet.
Una falta de familiaridad con el código
Si bien es una excelente ventaja usar un marco común y poder editar sitios web en todo el mundo a los pocos minutos de inspeccionar la fuente, una vez que comienza a intentar editar el marcado sin formato de un marco, en lugar de usar el sistema como un usuario final, se vuelve complicado. Con cientos de líneas de CSS y cientos de líneas de Javascript, todas escritas por los desarrolladores del marco, su familiarización con ese código será inexistente, por lo que será extremadamente laborioso si desea editar la funcionalidad del marco en sí.
Una necesidad de actualizar el marco
Al igual que un paquete de software, tome WordPress por ejemplo, los marcos deben actualizarse regularmente. Los equipos del marco desarrollan nuevas versiones, los errores se corrigen a medida que la comunidad los informa y se producen nuevas funciones.
Si bien es posible que deba actualizar su marcado una vez cada pocos años a medida que se desarrollan nuevas versiones de HTML/CSS si lo ha codificado desde cero sin marco, puede terminar actualizando su marcado de marco cada pocos meses. Esto requiere mucho tiempo y es potencialmente riesgoso.
¿Restringimos nuestro propio conocimiento sobre el desarrollo?
Un argumento en contra de los frameworks es que restringen nuestro conocimiento en bruto de HTML, CSS y Javascript. Después de todo, si alguien nos proporciona una lista de clases CSS, ya diseñadas y predefinidas en una hoja de estilo, así como una estructura HTML común y funciones Javascript preescritas, seguramente nuestro propio conocimiento como usuario final tiene el potencial de disminuir. Tal vez sea así, y es por esta razón que siempre debemos esforzarnos e impulsar los marcos para garantizar que nosotros (y nuestros clientes, si desarrolla para ellos) siempre obtengamos la mejor experiencia de usuario, independientemente de si usamos o no un marco.
Los marcos frontend más populares
Entonces, suponiendo que le gustaría usar un marco frontend, ¿cuál usa? Hay muchos por ahí, algunos más populares que otros, y algunos hechos para aquellos más técnicos que principiantes. Aquí, veremos brevemente algunos de los más populares.
Twitter Bootstrap
Bootstrap, desarrollado por dos empleados de Twitter, se ha convertido ampliamente en el framework frontend más popular del mundo.
Si bien no es el primer marco que responde completamente, ahora lo es y maneja todos los dispositivos y resoluciones de pantalla excepcionalmente bien.
Hay una excelente comunidad de desarrolladores de Bootstrap y usuarios finales experimentados disponibles para ayudar, y la documentación está cuidadosamente pensada.
Las clases y funciones de Bootstrap tienden a ser muy ‘completas’, a menudo diseñadas completamente con fuentes, colores y la marca tradicional de Bootstrap. Como resultado, puede ser difícil desviar su barco de esta sensación para asegurarse de que se vea único. Dicho esto, con algo de trabajo es absolutamente posible desarrollar un sitio web de Bootstrap que parezca personalizado y único para usted.
Más información sobre Bootstrap
.
Fundación ZURB
Muy a menudo, la elección entre usar Bootstrap o Foundation es una preferencia puramente personal debido a lo similares que son, pero Foundation tiene varias características que pueden influir en su voto en esta dirección.
En primer lugar, los elementos de Foundation no son tan ‘completos’ a primera vista, por lo que alejarse de la apariencia predeterminada para darle a su sitio web su propia marca única es generalmente muy fácil.
Foundation, a diferencia de Bootstrap que usa píxeles, usa rems para el tamaño de fuente. Si bien esto puede parecer una diferencia sutil, tiene mucho sentido usar una unidad relativa, como rems, en un diseño receptivo, en lugar de una unidad absoluta, como píxeles.
Foundation también tiene algunas funciones integradas excelentes que Bootstrap no contiene, como la validación de formularios integrada y el Intercambio, un sistema que se usa para cargar dinámicamente contenido receptivo para diferentes navegadores según el dispositivo y el tamaño de la pantalla (esto es especialmente útil para cargar imágenes más pequeñas en dispositivos móviles, en lugar de cargar imágenes de dimensiones más grandes que uno podría necesitar en una computadora de escritorio).
Además, otras características integradas incluyen soporte de derecha a izquierda para
le permite cambiar fácilmente la copia para que se lea de derecha a izquierda, así como las tablas de precios integradas.
Foundation tiene todas estas características, además de la mayor parte de lo que contiene Bootstrap, y como resultado, a menudo se lo considera el marco de referencia para desarrolladores web intermedios y profesionales.
Más información sobre la Fundación
.
Puro.css
Una de las quejas más grandes de los desarrolladores que usan Bootstrap o Foundation es la cantidad de marcas infladas que contienen. Hay miles de líneas de CSS y Javascript, y lo más probable es que solo vaya a aprovechar y usar una pequeña proporción de esto.
Pure.css, conocido simplemente como ‘Pure’, combate este problema con su versión minimalista del desarrollo. Como sugiere el nombre, este marco es puramente CSS (es decir, sin Javascript).
Para usarlo, es tan simple como incluir un archivo CSS en su sitio web.
Pure tiene muchos elementos diferentes que se pueden tomar y consumir, o puede decidir qué elementos tomar y eliminar el resto, por lo tanto, manteniendo el margen de beneficio al mínimo.
Los elementos predesarrollados incluyen un sólido sistema de cuadrícula sensible para trabajar, muy parecido a Bootstrap y Foundation, así como estilos de formularios, botones, tablas y menús.
Más información sobre Pure
.
¿Qué marco debo usar?
Hay tantos marcos para elegir. Hemos enumerado tres arriba, pero hay incluso más, algunos más conocidos que otros. A menudo, la elección se reduce a las preferencias personales.
Mi propia preferencia siempre sería elegir Bootstrap o Foundation, simplemente porque sé que esto me prepara bien para trabajar en decenas de miles de otros sitios web. Si me encuentro en una posición en la que tomo el control de un sitio web de otro desarrollador, existe una alta probabilidad de que el desarrollador haya usado Bootstrap o Foundation.
Al decidir entre Bootstrap y Foundation, a menudo evalúo las funciones que sé que necesitaré para cada sitio web en particular. Por ejemplo, un sitio de alojamiento web en árabe lleno de tablas de precios me empujará directamente hacia Foundation por su compatibilidad con tablas de precios y de derecha a izquierda.
Un sitio web de folleto básico para un cliente que busca algo rápido y simple con un mínimo de complicaciones me va a cambiar más hacia Bootstrap, con la certeza de que los componentes de Bootstrap brindan una base sólida y completa con la que modificar y modificar.
Mi consejo sería probarlos todo el tiempo y aprenderlos bien para que pueda elegir el marco correcto en función de sus necesidades para cada proyecto.
¿Debería incluso usar un marco?
Casi se siente mal hacer esta pregunta al final de un artículo que habla sobre los beneficios de los marcos individuales, pero es una pregunta que se hace a menudo entre la comunidad de desarrollo y, en última instancia, como todo lo relacionado con los marcos, es una preferencia puramente personal.
Si tiene el tiempo y la inclinación para escribir puntos de interrupción receptivos y desarrollar un sistema de cuadrícula cada vez que desarrolla un nuevo sitio web, y prefiere escribir su propio marcado para menús desplegables y menús desplegables receptivos, entonces mi consejo no sería utilizar un marco. Sin embargo, estoy casi seguro de que si elige escribir todo eso desde cero, una vez que lo haya hecho más de dos veces, comenzará a guardarlos por separado como componentes para usar en proyectos futuros. Y de repente, al hacer esto, está comenzando a construir su propio marco.
En última instancia, todos los marcos son herramientas poderosas para mejorar nuestro rendimiento como desarrolladores, al mismo tiempo que nos ayudan a mantener una estructura común. Son una forma excelente de desarrollar rápida y fácilmente sitios web receptivos potentes y fáciles de usar. Ya sea que desarrolle sus propios componentes y los tenga rápidamente a mano, o use un marco común de acceso público, nuestro trabajo como desarrolladores ahora es un poco más fácil gracias a las personas que intentan trabajar de manera más inteligente, no más difícil.
Las siguientes dos pestañas cambian el contenido a continuación.
Jamie Harrop es un gerente de comercio electrónico, desarrollador front-end y escritor con sede en el Reino Unido con 14 años de experiencia independiente y en comercio electrónico.
