Los marcos de front-end modernos requieren constantemente que descargues un entorno de desarrollo completo, completo con dependencias y compiles tu código incluso antes de intentar verlo en tu navegador. ¿Es esto algo bueno? ¿Es el problema que estamos construyendo sitios más complejos, o los marcos son complejos por sí solos y presentan un nivel innecesario de complejidad?

¿Los marcos de front-end son una solución rápida o un problema inflado?

El desarrollo web de hoy ha evolucionado mucho desde los años 90; podemos crear experiencias completas que están muy cerca de lo que cualquier aplicación nativa puede hacer, y el proceso de desarrollo también ha cambiado. Atrás quedaron los días en que ser un desarrollador web front-end era cuestión de abrir el Bloc de notas, escribir algunas líneas de código, verificarlo en el navegador y cargarlo en una carpeta FTP.

El desarrollo web front-end del pasado

Debo comenzar afirmando lo obvio: el mundo no es como lo era hace 10 años. (Impactante, lo sé). Lo único que permanece constante es el cambio. En el pasado, teníamos muy pocos navegadores, pero había muchos problemas de compatibilidad. Hoy en día, no ves mucho las cosas como “mejor visto en Chrome 43.4.1”, pero en ese momento, era bastante común. Tenemos más navegadores ahora, pero menos problemas de compatibilidad. ¿Por qué? Debido a jQuery. jQuery satisfizo la necesidad de tener una biblioteca común y estándar que le permitiera escribir código JavaScript que manipule el DOM sin tener que preocuparse por cómo se ejecutaría en cada navegador y en cada versión de cada navegador, una verdadera pesadilla en la década de 2000

Los navegadores modernos pueden manipular el DOM como estándar, por lo que la necesidad de dicha biblioteca ha disminuido considerablemente en los últimos años. Ya no se necesita jQuery, pero aún podemos encontrar una cantidad de complementos extremadamente útiles que dependen de él. En otras palabras, los marcos web pueden no ser necesarios, pero aún son lo suficientemente útiles como para ser populares y ampliamente utilizados. Este es un rasgo común a la mayoría de los marcos web populares que existen, desde React, Angular, Vue y Ember hasta modelos de estilo y formato como Bootstrap.

Por qué las personas usan marcos

En el desarrollo web como en la vida, tener una solución rápida siempre es útil. ¿Alguna vez has hecho un enrutador en JavaScript? ¿Por qué pasar por el doloroso proceso de aprendizaje cuando puede instalar npm un marco de front-end para superar el problema? El tiempo es un lujo cuando el cliente quiere cosas hechas ayer o heredas el código de otro desarrollador diseñado para un marco particular, o si te estás integrando con un equipo que ya usa un marco determinado. Reconozcámoslo — los marcos existen por una razón. Si no hubiera beneficios para ellos, nadie los usaría.

Entonces, ¿cuáles son algunos de los beneficios y las propiedades únicas de utilizar un marco de desarrollo web?

El tiempo es dinero. Cuando estás desarrollando un proyecto y al cliente no le importa qué marco utilizas -de hecho, probablemente ni siquiera esté al tanto de lo que usas- solo se preocupan por obtener resultados, y cuanto más rápido, mejor. Los marcos establecidos le permiten crear una sensación instantánea de progreso desde el principio, que el cliente anhela desde el día 1. Además, cuanto más rápido se desarrolla, más dinero gana, ya que el tiempo liberado por el marco puede ser redirigido a asumir más proyectos.

Todo se trata de la comunidad. Al elegir un marco, este es un punto muy importante: ¿quién te ayudará cuando te quedes atascado en un problema? Tú y yo sabemos que va a suceder en algún momento. Llegará a un punto en el que necesites hacer algo que el marco no tenía la intención de hacer, o que el marco nunca fue diseñado para darte acceso, por lo que es esencial contar con una comunidad que te respalde. El desarrollo — especialmente independiente — puede ser difícil, ya que estás inmerso en un mundo virtual, y si eres el único desarrollador web front-end en un equipo, significa que tú es el único con la experiencia y la experiencia para encontrar una solución. Pero si el marco de front-end que utiliza tiene una sólida compatibilidad, habrá alguien del otro lado del mundo que se haya enfrentado al mismo problema y pueda ayudarle.

Los estándares son hermosos. ¿Alguna vez te has dado cuenta de que, cuando miras un viejo fragmento de tu propio código, puedes navegarlo fácilmente? ¿O al menos, más fácilmente que un código escrito por otra persona? Piensas de cierta manera, y tienes tu propia manera de nombrar cosas y organizar el código. Eso es un estándar. Todos los seguimos, incluso si son solo para nosotros mismos. Tendemos a comer cosas similares para el desayuno, nos levantamos a cierta hora y colocamos nuestras llaves en el mismo lugar todos los días. Y, de hecho, si cambiamos nuestras rutinas todos los días, la vida sería mucho más difícil solo por la idea de cómo hacer las cosas. ¿Alguna vez perdiste tus llaves porque las pones en un lugar diferente de lo normal? Los estándares hacen la vida más fácil. Cuando trabajas como parte de un equipo o una comunidad de desarrolladores, se vuelven absolutamente indispensables.

Los marcos proporcionan un estándar desde el momento en que los instala, lo que lo guía a pensar y codificar de una manera específica. No necesita perder tiempo creando un estándar con su equipo; simplemente puede seguir cómo se hacen las cosas en el marco. Esto hace que sea más fácil trabajar juntos. Es más fácil buscar una función cuando sabe que la función debe estar en un determinado archivo porque está construida para agregar una ruta en un SPA, y en su marco, todas las rutas se colocan en un archivo con ese nombre. Las personas con diferentes niveles de habilidad pueden trabajar juntas si tienes este nivel de estandarización, porque mientras los codificadores avanzados saben por qué las cosas se hacen de esa manera, incluso los desarrolladores más jóvenes pueden seguir el estándar en sí.

Cuando los marcos falla

Hace unos años, decir algo como “No uso marcos, no veo ningún beneficio real de ellos”, traía a la gente con antorchas y horquillas a su puerta. Pero hoy en día, cada vez más personas se preguntan: “¿Por qué debería usar un marco? ¿Realmente las necesito? ¿Es difícil codificar sin ellas?”

Ciertamente, soy uno de ellos. Nunca he sido fanático de ningún marco específico, y he estado codificando sin ellos durante toda mi carrera. Si tengo una opción en el asunto, mi elección siempre es: “No, gracias”. He estado desarrollando en JavaScript durante años y en ActionScript antes de eso. Estaba codificando en Flash cuando la mayoría de las personas ya lo consideraban muerto. (Lo sé, lo sé … pero estaba haciendo muchas animaciones, y la animación en HTML sencillo es difícil.) Así que si eres uno de los muchos que nunca piensan en codificar sin marcos, déjame mostrarte algunas razones por las cuales puedes estar luchando.

“Una talla para todos” es una mentira. ¿Te imaginas escribir una sola pieza de software que pueda hacer todo lo que has logrado en tu carrera? Ese es uno de los principales problemas con los marcos de desarrollo web. Tu proyecto tiene necesidades muy específicas, que tendemos a resolver agregando bibliotecas, complementos o complementos para ampliar el alcance del marco. Ningún marco ofrece el 100% de lo que necesitas, y ningún marco está compuesto al 100% por cosas que te resultarán útiles.

Tener demasiado código que no use puede ocasionar un retraso en el tiempo de carga de su sitio, que se vuelve más importante con cada usuario adicional. Otro problema es que la mentalidad de “talla única” da como resultado un código ineficiente. Tomemos, por ejemplo, $ ('sku-product'). Html ('SKU 909090');, que es un código de jQuery que, al final, todos sabemos que se traducirá en algo como document.getElementById ('sku-producto'). innerHTML = 'SKU 909090'; .

Ese tipo de diferencia en una sola línea puede parecer poco importante, pero cambiar el contenido de un elemento específico de la página es precisamente la virtud de Reaccionar. Ahora, React pasa por el proceso de crear una representación del DOM y analizar las diferencias en lo que intentas renderizar. ¿No sería más fácil simplemente orientar el contenido que desea cambiar desde el principio?

Ese enredo de malezas por el que estás caminando es cada vez más espinoso. ¿Alguna vez has estado en la situación en la que estás usando tu infraestructura y tratando de agregarle una biblioteca, solo para darte cuenta de que la versión de la biblioteca que necesitas no ¿Funciona bien con la versión de marco que estás usando? A veces se requiere más esfuerzo hacer que dos piezas de código funcionen juntas que escribir el código tú mismo. Y dado que los marcos y las bibliotecas que tú usa a menudo se basan en otros marcos y bibliotecas que pueden tener incompatibilidades ocultas que tú ni siquiera puede anticipar, el problema puede crecer de manera exponencialmente más compleja, alcanzando un punto donde son imposibles de administrar si quiero que el proyecto siga creciendo

Mantenerse al día con los Jones es una cosa. ¿Alguna vez trabajó en un proyecto en AngularJS solo para descubrir que necesita algo que no apareció hasta que se lanzó Angular 4? ¿Sabías que Angular 5 ha sido lanzado? Este es otro gran problema; incluso si se apega a un único marco de front-end, cuando ocurre una nueva versión importante, las cosas pueden cambiar tanto que el código que trabajó tan duro ni siquiera se ejecutará en la nueva versión. Esto podría tener como resultado desde molestos pequeños cambios que deben realizarse en muchos archivos hasta una reescritura completa de su código.

Mantenerse al día con las últimas versiones de un marco es un desafío, pero en la misma nota, otros marcos sufren cuando las actualizaciones se detienen por completo y no pueden mantenerse al día con el resto de la tecnología. En 2010, AngularJS y Backbone fueron lanzados por primera vez. Hoy, Angular está en su quinta versión principal, y Backbone está completamente fuera del foco de atención. Siete años parece mucho tiempo. Si construyes sitios web, probablemente hayan cambiado completamente en estética y función. Si está construyendo una aplicación, apostar por el marco equivocado puede poner a la empresa en una situación difícil, y costosa, más adelante, cuando las cosas deben ser reescritas.

Cuando todo lo que tienes es un martillo, todo parece un clavo. Si usaste marcos de desarrollo web con frecuencia, probablemente te haya pasado a ti, donde una única base de código define la forma del código que usas en el futuro, incluso si sólo está relacionado periféricamente. Digamos que vas a construir una plataforma como YouTube y quieres usar marco X. Puede haber un punto en el que, aunque suene ridículo en este día y edad, decidas usar Flash para los videos porque eso es lo que viene construido con el marco.

Los marcos tienen opiniones, y son fuertes; React, por ejemplo, te obliga a usar JSX de una manera específica. Puede ver que el código se usa de esa manera en todas partes. ¿Hay una alternativa? Sí. ¿Pero quién lo usa? Esto no siempre es malo, pero si necesita realizar animaciones complejas, es posible que solo necesite un marco para animar y no la totalidad de Reaccionar. He visto a gente hacer cosas locas como agregar jQuery a una página solo para agregar un nodo a un elemento, algo que podría lograrse en JS vainilla con document.getElementById ('id_of_node'). AppendChild (node);.

Eval es Malvado, pero .innerHTML es Maquiavélico

Quiero tomarme el tiempo para explorar este punto por separado porque creo que esta es una de las razones por las que más personas no codifican sin marcos. Cuando vea cómo funciona la mayoría del código cuando intente agregar algo al DOM, encontrará un montón de HTML inyectado por la propiedad .innerHTML. Todos parecemos coincidir en que eval es malo para ejecutar código JavaScript, pero quiero poner .innerHTML en el centro de atención aquí. Cuando se inyecta código HTML como una cadena simple, se pierde cualquier referencia que pueda haber tenido a cualquiera de los nodos que ha creado. Es cierto que puedes recuperarlos usando getElementsByClassName o asignándoles un id, pero esto es menos que práctico. Al tratar de cambiar el valor de uno de los nodos, se encontrará devolviendo todo el HTML nuevamente.

Esto es bueno cuando comienzas a codificar. Puedes hacer muchas cosas simples fácilmente sin mucha experiencia. El problema ocurre con la complejidad de los sitios web modernos, que tienden a parecerse más a las aplicaciones; esto significa que tenemos que cambiar constantemente los valores de nuestros nodos, lo cual es una operación de alto costo si lo hace volviendo a conectar el toda la estructura a través de .innerHTML. React resuelve este problema de manera eficiente a través de un DOM sombreado, y Angular lo aborda mediante el enlace como una manera fácil de modificar un valor que se muestra en una página. Sin embargo, también se puede resolver con bastante facilidad si se hace un seguimiento de los nodos que se crean y se guardan los que se reutilizarán o actualizarán en las variables.

También hay otras razones para mantenerse alejado de .innerHTML en general.

Los mayores mitos sobre la codificación sin marcos

El tiempo es dinero. Sip, estoy devolviendo este concepto desde antes. Muchas personas sienten que si dejan de usar un marco web popular, cambiaremos al instante a Internet de los 90, cuando <marquee> era la etiqueta favorita de todos, los GIF girados en un sitio de Geocities eran modernos y vanguardistas, Alta Vista era la go-to para búsquedas web, y los contadores de visitas fueron omnipresentes.

Con los marcos web, sus primeras líneas de código parecen hacer un gran progreso para ahorrar tiempo, pero en algún punto, las ganancias se convierten en pérdidas. Pasas el tiempo leyendo sobre cómo hacer que el marco haga cosas para las que no está construido, cómo integrar bibliotecas y hacer que jueguen bien con el marco, y descubriendo que el código que construiste siguiendo los estándares del marco no funciona para trabajar en absoluto y ahora necesita volver a escribirlo. Cuando haces cosas sin un marco, comienzas más lento, pero progresas constantemente. Al final, todo se trata de dónde quieres que sea la parte fácil. No hará mucha diferencia en el tiempo total.

Mi código será más largo que el Gran Muro. Escribir sin un marco es como comprar una película en lugar de suscribirse a un servicio de transmisión. No tiene acceso instantáneo a cientos de películas que desea ver, pero tampoco tiene que gastar dinero en miles de otras películas que nunca consideraría descargar de la tienda. Puedes escribir lo que necesitas.

¿El intermediario es útil? Por supuesto. Pero usualmente no es necesario. Cada línea de código que escriba tiene más significado, ya que no es necesario que se adapte a los requisitos de un marco. Puede parecer que está escribiendo más código con JavaScript puro porque la forma de crear los elementos DOM toma líneas para crear un elemento, adjuntarlo al DOM y quizás agregar una clase para el estilo, en lugar de llamar una sola línea de código en JSX. Pero si compara el código usando una biblioteca como jQuery o React, vainilla JS puede ser bastante similar en longitud. A veces es más largo, pero a veces es más corto también.

No hay necesidad de reinventar la rueda. El mantra de los profesores de informática en todas partes. Y es verdad — simplemente no tiene que significar marcos específicamente. Enviar una solicitud de Ajax para cargar o guardar datos es un requisito en casi todas las aplicaciones web, por ejemplo, pero no tener un marco no significa que deba volver a escribir el código cada vez. Puede crear su propia biblioteca o base de código, o puede extraer código de otros. Cuanto más pequeño es, más fácil es modificarlo o ajustarlo según sea necesario, por lo que es útil cuando necesita algo específico para un proyecto. Es más fácil modificar de 100 a 200 líneas de código que navegar a través de la montaña de archivos que puede contener una biblioteca o un marco de terceros.

Solo funcionará para proyectos pequeños. Este es un mito muy común, pero no es verdadero en absoluto; Actualmente, estoy trabajando en un sistema completo para administrar todos los aspectos de una empresa en línea en un solo lugar, incluido un módulo que es algo así como Google Drive. Ya sea con marcos o sin ellos, paso por pasos muy similares y encuentro problemas muy similares. La diferencia es insignificante. Sin embargo, sin marcos, mi código completo es más pequeño y más fácil de manejar.

QUIERO PRUEBAS

Bueno. Dejemos de hablar de teoría y saltemos a un ejemplo del mundo real. Hace algunos días, necesitaba mostrar una lista de marcas con logotipos para una tienda. El código inicial usaba jQuery, pero tenía un problema donde, al cargar en Mozilla, mostraba un ícono de imagen roto para las marcas que aún no tenían logos cargados. No podemos hacer que la tienda parezca inacabada solo porque la Compañía X aún no ha terminado su trabajo, pero la función necesitaba activarse.

El siguiente código usa el equivalente jQuery de .innerHTML:

var list_brand_names = ['amazon', 'apple', 'nokia'];
var img_out = '';
for (i=0;i<list_brand_names.length;i++) {
   var brandName = list_brand_names[i].toLowerCase();
  img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>";
}
jQuery("#brand-images").html(img_out);

Sin profundizar en los pros y los contras de jQuery, el problema aquí es que no tenemos ninguna referencia a las imágenes que creamos. Si bien hay soluciones que no implican cambiar el código, usemos esta oportunidad para ver cómo se puede hacer sin ninguna biblioteca:

var brands = ['amazon', 'apple', 'nokia'];
var brand_images = document.getElementById("brand-images");
for (var iBrand = 0; iBrand < brands.length; iBrand++) {
  var link = document.createElement('a');
  link.setAttribute('href', '/pages/' + brands[iBrand]);
  link.style.display = 'none';
  brand_images.appendChild(link);
          
  var image = new Image();
  image.src = "images/" + brands[iBrand] + "png";
  image.onload = function(){
    this.parentNode.style.display = '';
  }
  link.appendChild(image);
}

El código jQuery original tenía seis líneas de longitud, mientras que la solución JS de vanilla tomó doce. Para resolver el problema, ocultar cada imagen hasta que se cargue, toma el doble de tiempo codificar. Entonces veamos la alternativa. ¿Se puede resolver en jQuery también? Echale un vistazo:

img_out += "<a href='/pages/" + brandName + "' style="display:none"><img src='images/" + brandName + "' onload="showImage(this)"/></a>";
function showImage(image){
  image.parentNode.style.display = "";
}

Con un par de líneas adicionales de código, ahora solo hay una diferencia de tres líneas entre jQuery y vanilla, pero en jQuery, puede ver que la línea img_out está creciendo rápidamente y es muy compleja, hasta el punto en que necesita pausar y pensar cuidadosamente sobre lo que estás haciendo. Codificar el DOM directamente mediante el uso de funciones de nodo para agregar atributos, funciones y similares podría ser más largo, pero cada línea tiene un significado más claro y más preciso, lo que hace que sea más fácil de leer y mantener en el futuro.

Echemos un vistazo a React:

function BrandLink(props) {
  var url = "images/" + props.brand + ".png";
  return (<a href="{props.brand}"><img src={url}/></a>);
}
class Brands extends React.Component {
  constructor() {
	super();
	this.state = {brands: ['amazon', 'apple', 'nokia']};
  }
  render() {
	const links = this.state.brands.map((step, move) => {
  	return (<BrandLink brand={step} key={step}/>);
	});
	return (<div className="brands">{links}</div>);
  }
}
ReactDOM.render(<Brands />, document.getElementById("root"));

Esta versión es claramente subóptima. El código no es más corto que en vainilla, y todavía no hemos llegado al punto de resolver el problema y ocultar los enlaces hasta que se cargue la imagen que contienen.

Para cada ejemplo, los resultados van a ser diferentes. A veces, jQuery será más corto. A veces, React ganará. Hay momentos en que vanilla JS puede ser más corto que los dos. En cualquier caso, el objetivo aquí no era probar que uno era intrínsecamente superior al otro, sino demostrar que no hay una diferencia significativa entre el uso de JS vainilla y el uso de un marco cuando se trata de la longitud del código.

Conclusión

Como con casi cualquier problema de la vida real, nada es negro o blanco. La codificación sin marcos de desarrollo web podría ser la mejor solución para algunos de sus proyectos y una pesadilla para otros. Al igual que con todas las herramientas, la clave está en aprender no solo cómo usarlo, sino cuándo, y cuáles son las ventajas y desventajas de su uso. La codificación en JavaScript puro es como cualquier marco: dominarlo lleva tiempo antes de que te sientas cómodo usándolo.

Pero la diferencia clave, al menos para mí, es que los marcos van y vienen, e incluso si un marco es popular durante mucho tiempo, puede cambiar drásticamente de una versión a otra. El JavaScript puro será una opción por mucho más tiempo, hasta que deje de ser relevante por completo y surja algún otro idioma. Incluso entonces, habrá más conceptos y estrategias que puede migrar directamente de un idioma a otro que tú puede con un marco dado a otro. El tiempo y el esfuerzo son más o menos equivalentes cuando se trata de un solo proyecto, la reducción en la depreciación del conocimiento y las lecciones que puede llevar con tú al próximo desafío son factores muy importantes a considerar.

About the author

Juan Carlos Arias Ambriz, Mexico
member since January 22, 2016
Juan has over ten years of freelance UX experience. His projects span a wide variety but are all rooted in his commitment to always provide the best experience to the user. Juan has developed applications used by high-profile clients and so has learned to commit to perfection of detail in his work. [click to continue...]
Hiring? Meet the Top 10 Freelance JavaScript Developers for Hire in December 2018

Comments

comments powered by Disqus
Subscribe
Free email updates
Get the latest content first.
No spam. Just great articles & insights.
Free email updates
Get the latest content first.
Thank you for subscribing!
Check your inbox to confirm subscription. You'll start receiving posts after you confirm.
Trending articles
Relevant Technologies
About the author
Juan Carlos Arias Ambriz
JavaScript Developer
Juan has over ten years of freelance UX experience. His projects span a wide variety but are all rooted in his commitment to always provide the best experience to the user. Juan has developed applications used by high-profile clients and so has learned to commit to perfection of detail in his work.