Choosing the “Right” JavaScript Library/Framework for Your Application

Listen to This Post

Elegir la Biblioteca/Marco de JavaScript “correcto” para su aplicación. “¿Cuál es el marco/biblioteca JavaScript 'correcto' para que lo usemos? “. Esa es una pregunta que surge mucho hoy en día dada la multitud de opciones disponibles y una que no tiene una respuesta “correcta”, por supuesto. Me gusta decir, “Utiliza la herramienta adecuada para el trabajo correcto” cuando estoy en una empresa enseñando una clase de formación o proporcionando servicios de arquitectura/consultoría. Aunque ciertamente tengo mis preferencias tecnológicas, forzarlas a alguien o a una de las empresas con las que trabajo sería honestamente ingenuo y miope. Si hay algo que he aprendido trabajando en tecnología desde hace 20 años, es que “una talla para todos” nunca es una visión válida de la tecnología (o de la vida en general). El mundo es demasiado diverso para “una talla para todos”. A todos nos gusta pensar que nuestro camino es el “camino correcto” (me incluyo en esa declaración), pero esa opinión es muy subjetiva y limitada a lo que nos gusta y no nos gusta, lo que sabemos y estamos cómodos usando, nuestras experiencias personales, los tipos de aplicaciones estamos construyendo, así como muchos otros factores. Cuando se trata de bibliotecas/marcos JavaScript, no es ningún secreto que soy un fan de Angular y he estado durante muchos años volviendo a los días AngularJS. He visto ambas versiones usadas con mucho éxito en pequeñas y grandes empresas. Habiendo dicho que este post no se centrará en Angular en absoluto. De hecho, también me gustan otras opciones (Vue.js es una que me gusta mucho, por ejemplo) y utilizarlas en las aplicaciones de mi empresa y de nuestros clientes según corresponda. No creo en “una talla para todos” como se mencionó anteriormente y en su lugar siempre tratar de centrarse en la “herramienta adecuada para el trabajo correcto”, o podría decir “herramienta adecuada para la aplicación correcta”. Por ejemplo, hace aproximadamente un año necesitábamos crear una pequeña aplicación centrada en datos que procesara dinámicamente controles basados en datos jerárquicos sin SQL y enviara los datos editados al servidor para su procesamiento. Empezamos a usar un marco y pronto nos dimos cuenta de que era exagerado para el problema de negocios que estábamos tratando de resolver. Necesitábamos una biblioteca de enlace de datos JavaScript para hacer el trabajo, nada más. Aunque podríamos haber ido con React, Angular, Vue.js u otra opción similar, terminamos con Knockout.js (algo con lo que estábamos muy familiarizados) porque proporcionaba la funcionalidad exacta que necesitábamos. Eso vuelve a mi “herramienta correcta para el trabajo correcto” comentario anterior. Actualmente estamos trabajando con varias empresas que están construyendo aplicaciones a gran escala que tienen muchas características. Algo como Knockout.js probablemente no es la herramienta adecuada para esos tipos de aplicaciones porque necesitan enlace de datos más varias características adicionales que otras bibliotecas/marcos de trabajo pueden proporcionar de forma inmediata. ¿Debe elegir Angular, Vue.js, React u otra biblioteca/marco? Muchos equipos se sienten abrumados por el gran número de opciones que hay y tienen miedo de tomar la “decisión equivocada”. Aquí están mis pensamientos generales sobre tomar una decisión. No recomendaré una biblioteca o marco específico, sino que en su lugar pasaré por algunas preguntas clave que creo que debería hacer durante el proceso de selección. ¿Presta atención a nuestros usuarios? Cuando surge un debate sobre una biblioteca/marco siempre me gusta decir, “¡A mi mamá no le importa lo que uses (y tampoco a tus usuarios)! “. Eso podría decirse de la mayoría de los clientes usando cualquier aplicación que usted o yo hayamos escrito. Quieren algo que funcione, resuelva un problema de negocio y sea rápido y fácil de usar. Muy pocos usuarios de aplicaciones se preguntan y preguntan: “Hmmm... me pregunto qué biblioteca/marco están usando? “. Al tomar una decisión sobre una biblioteca/marco de trabajo, recuerde que la aplicación que está escribiendo se supone que está resolviendo un problema empresarial para los clientes, no para usted (en la mayoría de los casos de todos modos). Elimine los prejuicios personales acerca de las bibliotecas/marcos y, en última instancia, tomará una mejor decisión a largo plazo. Tendemos a gravitar conceptos que ya conocemos y nos sentimos cómodos usando. Es importante que estemos dispuestos a salir de nuestros “límites de comodidad” aunque cuando tomemos una decisión. Cada biblioteca o marco con el que he trabajado a lo largo de los años tiene ventajas y contras. Tendemos a ignorar los contras para bibliotecas/marcos que estamos cómodos usando, lo reconozcamos o no. Como desarrolladores, tendemos a quedar atrapados en nuestro pequeño mundo y a meternos en batallas que pierden tiempo por “¿quién tiene razón? “. A menudo olvidamos que mientras la aplicación haga lo que se supone que debe hacer, nuestros clientes probablemente estarán contentos de usarla. Si reducimos nuestro trabajo, ¿no es agregar valor empresarial y mantener a los usuarios contentos de qué se trata el trabajo? Siempre y cuando una biblioteca o marco de trabajo determinado se pueda utilizar para crear una aplicación exitosa, la biblioteca o el marco de trabajo que elija realmente no importa suponiendo que cumpla los objetivos de su negocio, rendimiento y mantenimiento. No importa, a mi madre y a tus clientes no les importa. Por supuesto, hay más en la historia de desarrollo de aplicaciones además de mantener a los usuarios contentos y agregar valor empresarial. ¿Qué te hará el más productivo? ¿Qué idioma, biblioteca y/o marco hará que su equipo sea el más productivo? Esa es la siguiente pregunta que me gusta abordar. Si se trata de JavaScript (ya que ese es el enfoque de este post), ¿los miembros de su equipo son competentes en ES5, ES2015, TypeScript, CoffeeScript, Elm o algo más? ¿Funcionan ya con marcos de trabajo o tienen más experiencia en scripting? No soy un fan de saltar a una biblioteca/marco “popular” sin las habilidades necesarias para ser productivo utilizándolo. Hacer eso conduce en última instancia a más problemas que soluciones en mi experiencia, sin importar cuán grande sea una biblioteca/marco. He visto que sucede una y otra vez cuando un gerente cree que puede enviar a un desarrollador a una clase y que volverá sabiendo todo lo que necesitan saber. El desconocimiento de los aspectos clave de una biblioteca/marco de trabajo puede llevar a la creación de aplicaciones que no se basan en las mejores prácticas y están plagadas de problemas de mantenimiento como resultado (más en un momento). Si bien es cierto que un equipo puede recibir capacitación en un nuevo idioma o biblioteca o marco, se necesita tiempo para que sea eficiente y productivo utilizarlo. Seleccione una pequeña aplicación prototipo para crear si desea probar una biblioteca/marco. Una vez creada la aplicación prototipo, tenemos una discusión en equipo sobre lo productivo que todos se sintieron, pros y contras, y opiniones generales de los miembros del equipo. No me importa si es Angular, Vue.js, React o algo más, empezar con algo pequeño si estás en el proceso de elegir una biblioteca/marco. Tómate el tiempo para hacer una prueba de concepto. ¿Cuál es la historia del mantenimiento? He hecho un montón de soporte de producción/mantenimiento en aplicaciones durante mi carrera y me he dado cuenta de lo importante que es crear aplicaciones que son fáciles de mantener. El cambio es inevitable en el mundo de la tecnología (sí - estoy diciendo lo obvio aquí) por lo que ir con una biblioteca/marco que su equipo se siente cómodo mantener es importante. Esto incluye evaluar lo fácil que será contratar a nuevas personas que puedan ponerse en marcha con la biblioteca o el marco elegido, teniendo en cuenta el trabajo del contratista (si su empresa utiliza contratistas) y más. Algunas preguntas relacionadas con el mantenimiento: ¿Están los desarrolladores y/o los equipos de soporte de producción acostumbrados a trabajar con un compilador o un lenguaje con scripts? A menudo no es tan simple como elegir una biblioteca/marco - usted necesita para elegir el idioma también. Esto puede parecer obvio (JavaScript), pero hay otras opciones que considerar. Es importante tener cuidado de elegir el idioma subyacente que se utilizará junto con la biblioteca/marco. A los desarrolladores acostumbrados a un compilador les puede gustar algo como TypeScript, por ejemplo, mientras que los desarrolladores de JavaScript sin experiencia utilizando un compilador pueden sentirse más productivos y cómodos usando ES5 o ES 2015. ¿Su equipo escribe pruebas unitarias, pruebas end-to-end, etc.? ¿La biblioteca/marco proporciona un buen apoyo para ello? ¿Cómo es el proceso de implementación para la biblioteca/marco de trabajo? ¿Es tan simple como mover algunos archivos o hay un proceso de compilación involucrado? ¿La biblioteca/marco proporciona una forma de organizar el código y las características? ¿La biblioteca/marco proporciona una guía de estilo ampliamente aceptada o una lista de mejores prácticas que los desarrolladores de un equipo pueden seguir para facilitar el mantenimiento en el camino? La historia del mantenimiento es una de los factores más importantes para mí personalmente al elegir una biblioteca/marco. ¿Cuál es la longevidad de la Biblioteca/Marco? Antes de tomar una decisión sobre cualquier biblioteca o marco de trabajo, recomiendo dedicar tiempo a examinar el repositorio de código fuente. Estas son algunas preguntas que hacer: ¿Cuándo fue la última vez que se actualizó la biblioteca/marco? ¿Está obsoleto o está avanzando activamente? ¿Cómo gestiona el equipo de la biblioteca/framework el control de versiones y se adapta a la forma en que trabaja su equipo/empresa? ¿Cuán robusta es la comunidad general de código abierto para la biblioteca/marco (esta es una pregunta clave que siempre hago antes de saltar a una biblioteca/marco)? ¿Qué tan rápido se resuelven los problemas? Como nota secundaria, no juzgue una biblioteca/marco por el número total de problemas no resueltos. Algunas personas tienden a utilizar el área “Problemas” de un repositorio para publicar preguntas y hacer sugerencias de características que no son problemas. Me gusta ver con qué frecuencia se resuelven los problemas para tener una idea de la salud de una biblioteca o marco determinado. ¿Cuántos contribuyentes tiene la biblioteca/marco? Es la biblioteca/marco soportado por un equipo a tiempo completo o administrado por una comunidad de código abierto. Hay pros y contras en ambos. Me gustaría tener un dólar por cada vez que me han preguntado, “¿Cuánto tiempo crees que la biblioteca/marco X estará alrededor? “. Es una gran pregunta y algo de lo que todos nos preocupamos. Algunas empresas no tienen el lujo de actualizar constantemente sus aplicaciones, por lo que los equipos tienen miedo de elegir una biblioteca/marco que puede desaparecer un día. Si tan sólo tuviera una bola de cristal para ayudar a predecir el futuro.: -) Los proyectos JavaScript se mueven rápidamente y tienden a tener un montón de churn. Recomendaría elegir una biblioteca/marco que ha sido estable durante al menos un año, tiene una comunidad sólida detrás de ella, y que se actualiza con frecuencia. ¿Elegir una biblioteca o un marco? ¿Está buscando una funcionalidad de biblioteca específica (como la representación de la interfaz de usuario y/o el enlace de datos) o desea un marco con todas las funciones que tenga una gran cantidad de funcionalidad incluida de forma inmediata? Por lo general, las bibliotecas se dirigen a algunas características muy específicas, mientras que los marcos abarcan una gama de características de marca. Si su equipo ya está usando un framework (en el lado del servidor, por ejemplo), entonces mover a un framework JavaScript puede tener sentido para mantener las cosas lo más consistente posible entre el cliente y el servidor. Por otro lado, si prefiere armar diferentes bibliotecas (similares a la elección de lo que desea comer en un buffet) para que tenga la flexibilidad de intercambiar diferentes características según sea necesario, entonces una o más bibliotecas pueden ser lo que busca. Al igual que con todo, hay pros y contras en ambos enfoques. Inicialmente me atrajo AngularJS (y ahora Angular) debido a la funcionalidad de marco que proporcionan. Tengo un fondo de Java y.NET y he lanzado muchas aplicaciones web exitosas a lo largo de los años utilizando marcos. Me gusta la consistencia que los marcos típicamente traen a la mesa para los desarrolladores en un equipo. Funciones como la representación de la interfaz de usuario, el enlace de datos, el enrutamiento, la validación de formularios, las pruebas y mucho más están disponibles en entornos como Angular. Bibliotecas como React y otras pueden proporcionar una gran cantidad de funcionalidad sin la sobrecarga de un “marco”. Ellos pueden hacer que sea más rápido y fácil de empezar (una declaración muy subjetiva que comprendo) y generalmente son más ligeros dependiendo de la funcionalidad que su aplicación necesita. Entonces, ¿qué es mejor - una biblioteca o un marco? Hable con 100 desarrolladores y obtendrá 100 respuestas diferentes. Aquí está mi visión de algunas de las bibliotecas y marcos populares de ahí fuera. Estas ciertamente no son las únicas opciones, pero son los grandes jugadores a partir de hoy (en mi opinión de todos modos). He aquí 3 que he investigado personalmente, trabajado directamente o visto usadas con éxito en empresas con las que trabajo. Vue.js - Vue.js es un “marco JavaScript progresivo” (aunque siempre he pensado en él como una biblioteca). Con scripts adicionales, puedes crear aplicaciones grandes y pequeñas usando Vue. Además de ser ligero, también es muy rápido y es muy fácil de empezar a usar. Si usted está familiarizado con AngularJS (la versión 1.x) que recogerá en Vue muy rápidamente. - Sí, lo es un proyecto de código abierto que está creciendo rápidamente. Tiene una CLI para ayudarle a comenzar con su primer proyecto: npm install -g vue-cli React - React es una biblioteca de interfaz de usuario que tiene muchas características adicionales (y bibliotecas de terceros) que se pueden agregar. Proporciona un gran rendimiento, es fácil de empezar a utilizar y es bastante popular. Un equipo de tiempo completo en Facebook, así como una sólida comunidad de código abierto, ayudan a ejecutar el proyecto. También está disponible una variante más pequeña de React llamada Preact. Es utilizado por Facebook, que es un bono cuando se trata de longevidad. React proporciona una CLI para ayudar a empezar: npm install -g create-react-app Angular - Si prefieres un framework, prueba Angular. Proporciona un robusto conjunto de características fuera de la caja que están todas integradas. También proporciona compilación AOT (Ahead-of-Time) para compilaciones de producción y cuenta con una sólida CLI. Está dirigido por un equipo de tiempo completo en Google y también cuenta con una sólida comunidad de código abierto. Es utilizado por una gran cantidad de aplicaciones clave dentro de Google, lo que es un bonus en lo que se refiere a la longevidad. Tenga en cuenta que si es nuevo en él, “AngularJS” se refiere a la versión 1.x mientras que “Angular” se refiere a la versión 2 +. Comience a utilizar la CLI con el siguiente comando: npm install -g @angular /cli Sin duda hay varias bibliotecas/marcos de trabajo más que podrían aparecer en la lista y la lista cambiará definitivamente con el tiempo. He tomado la decisión de enumerar sólo aquellos con los que he tenido experiencia directa, ya sea a través del desarrollo o trabajando con una empresa. ¿Estás segmentación móvil? Si sus aplicaciones se ejecutarán en dispositivos móviles (web o “nativos”), ¿en qué medida la biblioteca/marco que está buscando admite el desarrollo móvil? ¿Tiene que crear todos los controles móviles optimizados para el tacto a mano? Estas y muchas preguntas adicionales se pueden hacer al elegir una biblioteca/marco. ¿Qué opciones de terceros están disponibles? Otro factor a tener en cuenta son las opciones de terceros que están disponibles para la biblioteca/marco que está considerando. ¿Realmente quieres construir ese selector de fecha o calendario desde cero (habiendo hecho eso (una vez), yo diría “NO!”). Tener un sólido conjunto de funcionalidades de terceros que puede incluir en una biblioteca/marco de trabajo es importante especialmente cuando se trata de productividad. ¿Realmente necesita una biblioteca/marco? Algunas personas argumentarán que “vanilla” JavaScript es el camino a seguir para las aplicaciones centradas en JavaScript, por lo que quería mencionar esa opción. Aunque estoy completamente en desacuerdo con el enfoque de JavaScript “vanilla” (especialmente para aplicaciones empresariales más grandes) por una variedad de razones, es sin duda una opción válida para considerar dependiendo del tipo de aplicación que esté creando. ¿Por qué no me gusta este enfoque? Si la aplicación que se está construyendo es bastante pequeña, el enfoque JavaScript de “vainilla” puede funcionar bien. Sin embargo, para aplicaciones más robustas, todo tiene que construirse desde cero, lo que significa reinventar la rueda para enrutamiento, enlace de datos, validación de formularios, historial, etc. Significa conocer todas las peculiaridades del navegador, los estándares de seguridad, las tecnologías nuevas y futuras, y mucho más. ¿Quién tiene tiempo para estar siempre al tanto de todo eso mientras se construyen aplicaciones empresariales? ¿Qué sucede si la persona clave/personas que construyeron la base de código JavaScript “vainilla” deciden irse para otro trabajo? Ahora no sólo le preocupa mantener las aplicaciones empresariales, sino también las utilidades o el marco de JavaScript personalizado que alguien creó internamente. Conclusion Libraries/frameworks get very personal and it 's important to take our personal biases out of the picture when making a library/framework decision. He tratado de alejarme del buceo en pros y contras para bibliotecas/marcos específicos (aparte de mencionar algunos arriba) ya que siento firmemente que cada persona/equipo necesita experimentar por su cuenta antes de tomar una decisión. Hable con alguien en quien confíe que haya utilizado una biblioteca o marco que esté considerando para obtener sus comentarios. Construye un prototipo sencillo y ve cómo te sientes después. Encontre respostas para algumas das perguntas mencionadas neste post. Hay muchas preguntas y directrices adicionales que se podrían enumerar para ayudar a elegir la biblioteca/marco “adecuado” para su equipo. Todas las bibliotecas/marcos tienen su propio conjunto de pros y contras y todos ellos se pueden utilizar para construir aplicaciones pequeñas, medianas y grandes. ¿Es uno mejor que el otro o el “correcto” uno para elegir? No hay forma de responder a eso ya que es muy subjetivo. Aquí hay un post que menciona las fortalezas y debilidades de la biblioteca/marco JavaScript y, aunque es muy opinionada, proporciona un punto de partida. Muchos otros puestos que comparan bibliotecas/marcos también están ahí fuera, sólo tenga en cuenta que cada uno es típicamente bastante subjetivo. Espero que algunas de las directrices y conceptos que se enumeran aquí ayuden al proceso de decisión para usted y su equipo.

Choosing the “Right” JavaScript Library/Framework for Your Application 2

Subscribe to Our Free FlipBoard Magazines: