Frameworks front-end: ¿soluciones o problemas inflados?

Los marcos front-end modernos requieren que descargue un entorno de desarrollo, completo con dependencias y compile su código antes incluso de intentar verlo en su navegador. ¿Es esto algo bueno? ¿El problema es que estamos construyendo sitios más complejos, o es que los marcos son complejos por derecho propio, introduciendo un nivel innecesario de complejidad?

El desarrollo web actual ha evolucionado mucho desde los años 90; somos capaces de crear experiencias completas que están muy cerca de lo que puede hacer cualquier aplicación nativa, y el proceso de desarrollo también ha cambiado. Atrás quedaron los días en que ser un desarrollador web front-end era una 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 diciendo lo obvio: el mundo no es como 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 se ven mucho cosas como "se ve mejor en Chrome 43.4.1", pero en ese entonces, era bastante común. Ahora tenemos más navegadores, pero menos problemas de compatibilidad. ¿Por qué? Gracias a jQuery . jQuery satisfizo la necesidad de tener una biblioteca estándar y común que le permitiera escribir código JavaScript que manipula 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 una biblioteca de este tipo ha disminuido considerablemente en los últimos años. jQuery ya no es necesario , pero aún podemos encontrar una serie de complementos extremadamente útiles que dependen de él. En otras palabras, los marcos web pueden no ser necesarios, pero siguen siendo 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, desde React, Angular, Vue y Ember hasta modelos de estilo y formato como Bootstrap.

Por qué la gente usa marcos

En el desarrollo web como en la vida, tener una solución rápida siempre es útil. ¿Alguna vez has hecho un enrutador antes 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 que las cosas se hagan ayer o heredas código de otro desarrollador diseñado para un marco en particular, o si te estás integrando con un equipo que ya usa un marco determinado. Seamos realistas: los marcos existen por una razón. Si no hubiera beneficios para ellos, nadie los estaría usando.

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

El tiempo es dinero. Cuando está desarrollando un proyecto y al cliente no le importa qué marco usa, de hecho, probablemente ni siquiera sepa qué usa, 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 desarrolle, más dinero ganará, ya que el tiempo liberado por el marco se puede redirigir para asumir más proyectos

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 sucederá en algún momento. Llegará a un punto en el que tendrá que hacer algo para lo que el marco no estaba destinado, o para lo que nunca se diseñó el marco para darle acceso, por lo que es esencial contar con una comunidad que lo apoye. El desarrollo, especialmente el trabajo independiente, puede ser difícil, ya que está inmerso en un mundo virtual y, si es el único desarrollador web front-end en un equipo, significa que es el único con la experiencia y los conocimientos necesarios para encontrar un solución. Pero si el marco de front-end que usa tiene un soporte sólido, habrá alguien en el otro lado del mundo que haya enfrentado el mismo problema y podría ayudarlo.

Los estándares son hermosos. ¿Alguna vez ha notado que, cuando observa una pieza antigua de su propio código, puede navegar a través de ella con bastante facilidad? ¿O al menos, más fácilmente que un fragmento de código escrito por otra persona? Piensas de cierta manera y tienes tu propia forma de nombrar las cosas y organizar el código. Eso es un estándar. Todos los seguimos, incluso si son solo para nosotros. Tendemos a comer cosas similares para el desayuno, nos despertamos a una hora determinada y colocamos las llaves en el mismo lugar todos los días. Y, de hecho, si cambiáramos nuestras rutinas todos los días, la vida sería mucho más difícil solo por la sobrecarga de descubrir cómo hacer las cosas. ¿Alguna vez perdiste tus llaves porque las pusiste en un lugar diferente al normal? Las normas hacen la vida más fácil. Cuando se trabaja 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, guiándolo a pensar y codificar de una manera específica. No necesita dedicar tiempo a crear 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 archivo determinado porque está diseñada 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 tiene este nivel de estandarización, porque mientras los codificadores avanzados saben por qué las cosas se hacen de esa manera, incluso los desarrolladores principiantes pueden seguir el estándar mismo.

Cuando los marcos fallan

Hace algunos años, decir algo como “No uso marcos, no veo ningún beneficio real en ellos” atraería a personas con antorchas y horquillas a su puerta. Pero hoy, más y más personas se preguntan: “¿Por qué debería usar un marco? ¿Realmente los necesito? ¿Es tan difícil codificar sin ellos?

Ciertamente soy uno de ellos: nunca he sido fanático de ningún marco específico y he estado programando 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 la gente ya lo consideraba muerto. (Lo sé, lo sé... pero estaba haciendo muchas animaciones, y la animación en HTML simple es difícil). Entonces, si eres uno de los muchos que nunca piensan en codificar sin marcos, déjame mostrarte algunas razones por las que podrías estar luchando

"Una talla sirve 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. Su proyecto tiene necesidades muy específicas, que solemos resolver agregando bibliotecas, complementos o complementos para ampliar el alcance del marco. Ningún marco ofrece el 100 % de lo que necesita, y ningún marco está compuesto al 100 % por cosas que encontrará útiles.

Tener demasiado código que no usa puede provocar un retraso en el tiempo de carga de su sitio, lo 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 código jQuery que, al final, todos sabemos que se traducirá en algo como document.getElementById('sku-product').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 React. Ahora, React pasa por el proceso de crear una representación del DOM y analizar las diferencias en lo que intenta representar. ¿No sería más fácil apuntar al contenido que desea cambiar desde el principio?

Esa maraña de malas hierbas por la que estás caminando está creciendo espinas. ¿Alguna vez ha estado en la situación en la que está usando su marco e intentando agregarle una biblioteca, solo para darse cuenta de que la versión de la biblioteca que necesita no funciona bien con la versión del marco que está usando? A veces se necesita más esfuerzo para hacer que dos piezas de código funcionen juntas que simplemente escribir el código usted mismo. Y dado que los marcos y las bibliotecas que usa a menudo se basan en otros marcos y bibliotecas que pueden tener incompatibilidades ocultas que ni siquiera puede anticipar, el problema puede volverse exponencialmente más complejo, llegando a un punto en el que son imposibles de manejar si usted queremos que el proyecto siga creciendo.

Mantenerse al día con los Joneses 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 solo marco de front-end, cuando ocurre una nueva versión importante, las cosas pueden cambiar tanto que el código en el que trabajó tan duro ni siquiera se ejecutará en la nueva versión. Esto podría resultar en cualquier cosa, desde pequeños cambios molestos que deben realizarse en muchos archivos hasta una reescritura completa de su código.

Mantenerse al día con las últimas compilaciones 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, tanto AngularJS como Backbone se lanzaron por primera vez. Hoy, Angular está en su quinta versión principal y Backbone está completamente fuera del centro de atención. Siete años parece mucho tiempo. Si crea sitios web, es probable que hayan cambiado por completo en cuanto a estética y función. Si está creando una aplicación, apostar por el marco incorrecto podría poner a la empresa en una situación difícil y costosa más adelante, cuando sea necesario reescribir las cosas.

Cuando todo lo que tienes es un martillo, todo parece un clavo. Si ha usado marcos de desarrollo web con frecuencia, probablemente le haya pasado esto, donde una sola base de código define la forma del código que usará en el futuro, incluso si solo está relacionado periféricamente. Digamos que vas a construir una plataforma como YouTube y quieres usar Framework X. Puede haber un punto en el que, aunque suene ridículo en esta época, decidas usar Flash para los videos porque eso es lo que viene. integrado 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 el código que se usa de esa manera en todas partes. ¿Hay alguna alternativa? Si. Pero, ¿quién lo usa? Esto no siempre es algo malo, pero si necesita realizar animaciones complejas, es posible que solo necesite un marco para animar y no la totalidad de React. He visto 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 Vanilla JS 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 intenta agregar algo al DOM, encontrará un montón de HTML inyectado por la propiedad .innerHTML . Todos parecemos estar de acuerdo en que eval es malo para ejecutar código JavaScript, pero quiero poner .innerHTML en el centro de atención aquí. Cuando inyecta código HTML como una cadena simple, pierde cualquier referencia que pudiera haber tenido a cualquiera de los nodos que creó. Es cierto que puede recuperarlos usando getElementsByClassName o asignándoles una id , pero esto es menos que práctico. Cuando intente cambiar el valor de uno de los nodos, se encontrará devolviendo todo el HTML nuevamente.

Esto es bueno cuando empiezas a programar. 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 necesitamos cambiar constantemente los valores de nuestros nodos, lo cual es una operación de alto costo si lo hace volviendo a unir toda la estructura. a través .innerHTML . React resuelve este problema de manera eficiente a través de un DOM en la sombra, y Angular lo aborda mediante el uso de enlaces como una forma fácil de modificar un valor que se muestra en una página. Sin embargo, también se puede resolver con bastante facilidad haciendo un seguimiento de los nodos que crea y guardando los que se reutilizarán o actualizarán en 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. Sí, estoy trayendo este concepto de antes. Muchas personas sienten que si dejan de usar un marco web popular, regresaremos instantáneamente a la Internet de los años 90, cuando <marquee> era la etiqueta favorita de todos, los GIF giratorios en un sitio de Geocities eran modernos y vanguardistas, Alta Vista era el go- para búsquedas en la web, y los contadores de visitas eran omnipresentes.

Con los marcos web, sus primeras líneas de código parecen hacer un gran progreso para ahorrar tiempo, pero en algún momento, las ganancias se convierten en pérdidas. Pasa su tiempo leyendo acerca de cómo hacer que el marco haga cosas para las que no está diseñado, cómo integrar bibliotecas y hacer que funcionen bien con el marco, y descubrir que el código que creó siguiendo los estándares del marco no funciona. para trabajar en absoluto y ahora necesita volver a escribirlo. Cuando haces cosas sin un marco, empiezas más lento, pero haces un progreso constante. Al final, se trata de dónde quieres que esté la parte fácil. No hará mucha diferencia en el tiempo total.

Mi código será más largo que la Gran Muralla. Escribir sin un marco es como comprar una película en lugar de suscribirse a un servicio de transmisión. No obtiene 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 necesites.

¿Es útil el intermediario? Por supuesto. Pero no suele ser necesario . Cada línea de código que escribe 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 requiere líneas para crear un elemento, adjuntarlo al DOM y quizás agregar una clase para diseñar, en lugar de llamar a una sola línea de código en JSX. Pero si compara el código usando una biblioteca como jQuery o React, Vanilla JS puede tener una longitud bastante similar. A veces es más largo, pero a veces también es más corto.

No hay necesidad de reinventar la rueda. El mantra de los profesores de informática en todas partes. Y es cierto, simplemente no tiene que referirse específicamente a los marcos. 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 escribir el código de nuevo 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 100-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 trabajo de terceros.

Solo funcionará para proyectos pequeños. Este es un mito muy común, pero no es cierto 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, sigo pasos muy similares y encuentro problemas muy similares. La diferencia es insignificante. Sin embargo, sin marcos, todo mi código es más pequeño y más fácil de administrar.

QUIERO PRUEBAS

Bueno. Dejemos de hablar de teoría y saltemos a un ejemplo del mundo real. Hace unos días necesitaba mostrar una lista de marcas con logos para una tienda. El código inicial usaba jQuery, pero tenía un problema donde, al cargar en Mozilla, mostraba un ícono de imagen rota para las marcas que aún no tenían los logotipos cargados. No podemos tener la tienda sin terminar solo porque la Compañía X aún no ha terminado su parte del trabajo, pero la característica necesitaba estar activa.

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 demasiado 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 existen soluciones que no implican cambiar el código, aprovechemos 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 original de jQuery tenía seis líneas, mientras que la solución Vanilla JS tomó doce. Para resolver el problema, ocultar cada imagen hasta que se haya cargado requiere el doble de tiempo para codificar. Así que veamos la alternativa. ¿Se puede resolver en jQuery también? Echale un vistazo:

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

Con un par de líneas de código adicionales, ahora solo hay una diferencia de tres líneas entre jQuery y vanilla, pero en jQuery, puede ver que la línea img_out se está volviendo muy compleja rápidamente, hasta el punto en que necesita hacer una pausa. y piensa cuidadosamente en lo que estás haciendo. Codificar el DOM directamente mediante el uso de funciones de nodo para agregar atributos, funciones y similares puede llevar más tiempo, pero cada línea tiene un significado más claro y preciso, lo que facilita su lectura y mantenimiento en el futuro.

Echemos un vistazo a Reaccionar:

 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 Vanilla, y aún no hemos llegado al punto de resolver el problema y ocultar los enlaces hasta que la imagen dentro de ellos se haya cargado.

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 ambos. En cualquier caso, el objetivo aquí no era demostrar que uno era intrínsecamente superior al otro, sino demostrar que no hay una diferencia significativa entre usar Vanilla JS y usar un marco en lo que respecta a la longitud del código.

Conclusión

Al igual que con casi cualquier problema de la vida real, nada es blanco o negro. La codificación sin marcos de desarrollo web puede 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 usarla, sino también cuándo y cuáles pueden ser las ventajas y desventajas de usarla. La codificación en JavaScript puro es como con cualquier marco: dominarlo lleva tiempo antes de que se sienta 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. JavaScript puro será una opción durante mucho más tiempo, hasta que deje de ser relevante por completo y surja algún otro lenguaje. Incluso entonces, habrá más conceptos y estrategias que podrá migrar directamente de un idioma a otro que con un marco dado a otro. El tiempo y el esfuerzo son aproximadamente equivalentes en lo que respecta a un solo proyecto, la reducción en la depreciación del conocimiento y las lecciones que puede llevar consigo al próximo desafío son factores muy importantes a considerar.