intive Argentina Blog

Elige tu propio framework

Nos estuvimos poniendo un poco al día sobre los frameworks que existen en el mercado, y nos surgía la incógnita: ¿cómo eligen nuestros developers entre tanta variedad? Para despejar nuestras dudas, entrevistamos a nuestros Juan Manuel Álvarez Giménez, Pablo Hiyano y Maximiliano Céspedes. ¡Este es el resultado!


¿Qué son los frameworks y las librerías? (para los rezagados)

Una librería es un conjunto de herramientas que ataca un problema específico, un framework es, en cambio, un conjunto de herramientas o de librerías que atacan un problema de mayores dimensiones. Ambos son capas superiores a un lenguaje, que permiten trabajar de manera más cómoda con otro lenguaje más amigable y herramientas más accesibles.

Veamos un ejemplo:

React es una librería de UI, mientras que Angular es un framework. ¿Cuál es la diferencia?

  • React no tiene ninguna herramienta, ningún comando, nada para manejar una petición a un servidor. Lo tenés que hacer vos mismo, tenés que usar una librería que se encargue puntualmente de resolver eso.
  • Angular tiene herramientas que te permiten manejar esas peticiones al servidor. Con un framework tenés muchas más herramientas, se trata de un espectro más grande que permite resolver más problemas. No siempre uno utiliza todas las soluciones que provee.

Pablo – Todos los frameworks tienen ciertos dominios que atacan -si vos querés hacer una página web, probablemente vas a tener que preocuparte por manejar la ruta, por hacer peticiones a un servidor, por manejar animaciones, por ejemplo- y el framework tiene todos esos dominios que ya son conocidos proveyendo una solución completa como sería Angular, o haciendo librerías específicas como es el caso de algunas librerías orientadas a componentes como React

Entendimos entonces que los frameworks reducen tiempos de trabajo y, en consecuencia, los márgenes de error. También contempla otros beneficios como su previo testeo por otros usuarios, que ya han encontrado y reportado antiguos errores. Suelen contemplar muchos más casos de uso de los que un desarrollador podría proyectar.

Ahora, ¿cómo elegimos el mejor framework?

Maxi – Con un framework o una librería, existe la promesa de algo nuevo, un paradigma, una forma de trabajar que hace más feliz al desarrollador. Las tendencias tecnológicas también determinan. Es difícil saber qué hace a un framework más exitoso que otro. Tal vez tenés dos frameworks que te pueden resolver el mismo problema, pero siempre terminás definiendo en base a tu proyecto: su tiempo, mantenibilidad, extensibilidad. Es decir, que siempre los frameworks se comparan en relación a un proyecto o un problema específico que tenés que resolver.

Pablo – Muchas veces, con los frameworks o las librerías, ves quiénes las implementan. Si te digo que es la librería que usa Facebook, eso tiene un respaldo.

Entonces, ¿qué criterios o factores hay que tener en cuenta?

  • Si es de código libre, si éste está disponible para investigarlo. Cuántos bugs tiene, cuánta gente está pendiente de eso. ¿Por qué es importante hacer estas preguntas? Porque si el framework es de código libre, tiene pocos bugs o todos resueltos, y mucha gente trabajando en él; eso puede suponer que tiene algo atractivo para los programadores, y que resuelve una cantidad de problemas bastante comunes a todos. Muchos de esos datos los tenés muy visibles en plataformas como GitHub.
  • El apoyo de la comunidad es muy importante a la hora de contratar gente para mantener tu proyecto. Si un desarrollador se va del proyecto, y hay una comunidad grande de desarrolladores, se hace más fácil conseguir nuevos integrantes.
  • Las sugerencias de gente popular en Twitter pueden servir de referencia como Jake Archibald (@jaffathecake), Eric Elliot (@_ericelliott) o Dan Abramov (@dan_abramov). Ellos suelen escribir artículos en revistas de Frontend, o en sus blogs. Las grandes compañías también funcionan como referentes, de manera positiva o negativa. Así pasó con Ruby on Rails, cuando Twitter dijo que migraba porque Ruby era lento, y luego tuvo que aclarar: “no se confundan, Ruby es un lenguaje excelente pero estamos procesando mil millones de tweets por segundo y este lenguaje no se banca esto”. Una aplicación promedio no está cerca del 5% de lo que es Twitter y Ruby no es lento para una aplicación promedio, pero la gente ya había empezado a abandonarla por la mala publicidad
  • La respuesta y el soporte: ¿Los puedo llamar a las 2am y decirles “esto no me anda” o “esto no sé hacerlo”, y me van a orientar? ¿Tienen buena documentación? En general, la tecnología open-source tiene más resueltos estos temas. Es probable que utilices un framework pago solamente en casos muy específicos. “El caso de éxito más famoso es el de Linux. Tenés un sistema operativo de la ostia, gratis. Una comunidad enorme. Surge un problema y en dos o tres días está arreglado.” (Pablo Hiyano).
  • La curva de aprendizaje de la tecnología: si cambia o no el paradigma de programación, de manera matemática o conceptual. “Hay gente que quiere salir de su zona de confort y gente que no” (Juan Manuel Álvarez Giménez).
  • Rapidez al programar. “A veces tenés que bajar el nivel de abstracción. Cuando vos elegís un framework, al subir el nivel de abstracción y simplificar la sintaxis, en esa delegación de trabajo estás metiendo un intermediario y eso consume recursos. Entonces, muchas veces si vos lo que necesitás es optimizar recursos, tenés que aguantártela, sacar ese framework y laburar más abajo. Te va a costar más, pero te va a rendir más también.” (Pablo Hiyano). Un ejemplo: JQuery es rápido pero si quiero que sea más rápido, saco JQuery y trabajo con JS1.
  • El tamaño del Framework. Hay frameworks y librerías que están atados a empresas que están entre las más grandes del planeta por cantidad de datos, tráfico de internet o dinero: Facebook, Amazon, Google. La decisión puede ser mala pero tienen todo el empuje para poder hacer un montón de cambios.

Más tarde, la conversación se adentró en la gran pelea de los últimos tiempos: React vs Angular, pero esa es otra historia, que les contaremos en la próxima entrega. ¡Estén conectados!

Paula Becchetti

Paula es la editora del blog de intive – FDV. Licenciada en Comunicación Audiovisual de la Universidad Nacional de San Martín (UNSAM), se destaca como Content Manager especializada en blogs, contenido web, email marketing y social media. Su amplia experiencia en la industria del software la hace muy valiosa a la hora de traducir contenidos técnicos a un lenguaje coloquial. Según sus propias palabras: “Me conecto con el mundo por medio de la tecnología, pero también a través de todo aquello que respira, del deporte, de la música y de mis viajes”.

Deja un comentario