15 grandes alternativas a React, Angular y Vue

«Sonrisas y lágrimas» puede predicar: «Empecemos por el principio, un muy buen lugar para empezar». Pero casi todos los desarrolladores saben que es un plan absurdo. El lugar correcto para empezar es con una base firme construida por un gran equipo de desarrolladores de código abierto. Clona su duro trabajo y luego añade el código suficiente para hacerlo tuyo. No hay necesidad de repetir lo que todo el mundo ha hecho antes.

Es un plan fácil, una vez que se elige. Por desgracia, elegir esa base puede ser casi tan difícil como empezar desde el principio. El mundo de los frameworks web es un área de desarrollo muy activa y puede haber docenas de buenos proyectos de código abierto que serían grandes comienzos para tu proyecto.

Para empeorar las cosas, los diferentes equipos que crearon estos diferentes proyectos emprendieron un camino diferente porque tenían serias diferencias filosóficas con las otras opciones. Observaron los otros frameworks y decidieron que podían hacerlo mejor. En otras palabras, lo hicieron por una razón y usted puede o no estar de acuerdo con su decisión.

La lista de buenos lugares para empezar a continuación deja intencionalmente fuera a los líderes del mercado React, Angular y Vue sólo para hacer las cosas un poco más simples. Eso no significa que los tres grandes sean malos. Todavía pueden ser lo mejor para ti. Es sólo que se habla de ellos constantemente y esas discusiones dejan fuera otras opciones bastante buenas.

Hay un montón de buenas razones para elegir los más populares. Mucha gente en tu lugar buscó y muchos eligieron React, Angular o Vue por una buena razón. Pero eso fue entonces. Mientras tanto, algunas personas inteligentes han creado nuevos frameworks que son más rápidos, más simples, más fuertes, o cualquiera de un gran conjunto de superlativos.

En la mayoría de los casos a continuación, los equipos crearon algo intrigante y poderoso al reimaginar la naturaleza del framework. Eso es una forma elegante de decir que acabaron eliminando una característica, lo que hizo que el marco de trabajo fuera más eficiente y, por tanto, redujera la cantidad de memoria que necesita, acelerara el tiempo de inicio o, en general, lo hiciera más ágil. O, en algunos casos, añadieron nuevas ideas que pueden convertirse en estándar en el futuro.

Si tienes tiempo para invertir, aquí tienes una lista de otras opciones interesantes. No son necesariamente adecuadas para algunas personas y ciertamente no son la mejor opción para todos, pero podrían ser una mejor opción para ti. Tu trabajo, si decides aceptarlo, es crear una descripción sólida de tu aplicación web, escribir una descripción relativamente firme de los diferentes casos de uso, y luego evaluar estas herramientas con esto en mente.

Quizás te gusta un enfoque particular para diseñar el código. Tal vez su aplicación no necesita algunas de las características de los frameworks más gordos y populares. Hay docenas de razones para invertir en uno de estos otros caminos. Puede que descubras que uno de ellos funciona de maravilla para tu aplicación.

Petit DOM

Si te encanta la idea de un DOM virtual, pero no quieres todas las restricciones que conlleva adoptar la mentalidad de la gente de React, Vue o cualquier otro framework de renombre, entonces el Petit DOM es el camino a seguir. Usted obtiene una pequeña cantidad de código que le permitirá manipular una colección virtual de etiquetas y luego migrarlas al DOM real. Todo lo demás sobre la estructura de los componentes y el renderizado depende de ti. Si tus componentes son simples, o si vas a crear alguna jerarquía de renderizado supercompleja que será sólo tuya, esto podría ser tu base porque todo lo que proporciona es una herramienta para virtualizar el DOM.

Sobre

El DOM virtual puede no ser para todos. Ocupa espacio, así que si tus manipulaciones no son demasiado complejas, es mejor que conduzcas tus instrucciones directamente al DOM oficial. La biblioteca Surplus hace precisamente eso. Toma el marcado JSX favorito de todos y lo compila en un código que manipulará el DOM real. Como dicen en el negocio de la publicidad, elimina el intermediario. No hay difusión. No hay capa extra secreta. Sólo la manipulación pura del DOM real. Si su código es lo suficientemente simple y directo como para hacer sólo unas pocas cosas al DOM, ¿por qué molestarse con la distracción virtual?

RE:DOM

Otra opción para aquellos que no quieren invertir ninguna memoria en un Dom virtual es una pequeña biblioteca (2KB) llamada RE:DOM. RE:DOM contiene algunas rutinas básicas que permiten crear todas las etiquetas y componentes con unas simples llamadas a JavaScript. La sintaxis es mucho más cercana a la de CSS, por lo que puedes especificar etiquetas bastante elaboradas con IDs y clases con sólo unas pocas pulsaciones. Tus teclas «menor que» (<) y «mayor que» (>) te lo agradecerán.

Mithril

No todas las alternativas son diminutas y minimalistas. Mithril podría llamarse un framework «mediano» en este contexto, aunque sólo pesa unos 8KB. Todo este código construye un DOM virtual con un mecanismo de actualización eficiente como los demás, pero también viene con un conjunto estandarizado de herramientas para hacer frente a muchos de los desafíos estándar como el enrutamiento y las llamadas XMLHttpRequest. Los diseñadores del proyecto quieren que los proyectos Mithril sean relativamente estandarizados, y creen que añadir este código a la biblioteca principal aumenta la estandarización. Si eso no es suficiente, también impulsan algunos formatos estándar y estructuras idiomáticas.

Bobril

Si te gusta el DOM virtual y los componentes con estado de React y te gusta programar en TypeScript, entonces Bobril o su primo amigable con Angular, ngBobril, puede ser justo el billete. El marco de trabajo es consistentemente mucho más rápido que React o Angular en algunos de los puntos de referencia, tal vez debido a los algoritmos más rápidos de diff y la falta de apoyo a JavaScript isomórfico. También hay funciones abreviadas para la manipulación de CSS y una capa de gestión de estado completa, BobX, si lo necesitas.

Marko

Si has pasado algún tiempo pujando por dispensadores de Pez u otros objetos de colección, has experimentado el poder de Marko, un marco delgado y rápido que eBay está compartiendo a través de una licencia de código abierto. La parte más bonita puede ser una sintaxis de plantillas muy ligera que elimina inteligentemente la mayor parte del exceso de grasa del HTML para que la estructura se defina por la sangría y poco más. Y el motor de renderizado es muy rápido, capaz de conducir elaboradas constelaciones de DIVs danzantes que se actualizan más rápido que 60fps.

Svelte

Su marco web estándar viene con un compilador y una biblioteca descargada que maneja en tiempo de ejecución lo que el compilador produce. El proceso de dos pasos permite un código muy elaborado al precio de esperar a que la biblioteca en tiempo de ejecución se descargue y analice cada vez que se abre la página. El compilador Svelte se deshace de esta complejidad escupiendo un JavaScript casi puro que está casi listo para ejecutarse por sí mismo, aunque sólo en algunos de los navegadores más nuevos (por ejemplo, Chrome, Firefox, Opera e IE10). Es una táctica arquitectónica inteligente que produce sitios web muy ligeros que ocupan poca memoria.

Inferno

Inferno es otro marco creado para hacer mucho de lo que hace React, pero con una descarga más pequeña y un tiempo de ejecución más rápido. Logra gran parte de esto desechando el elaborado mecanismo de eventos sintéticos y concentrándose sólo en los más esenciales como onClick. Muchas otras partes de la API son similares, si no iguales, lo que hace que sea relativamente sencillo trasladar tu código si no necesita la capa de optimización de eventos.

Preact

Uno de los descendientes más pequeños de React es Preact, un homenaje que ofrece la mayoría de las características más valiosas, como un DOM virtual y componentes sofisticados, pero elimina los manejadores de eventos sintéticos y parte de la herencia de accesorios. Mientras que Inferno trata de implementar sólo los eventos más importantes como onClick, Preact no se molesta en tratar de hacer nada con los eventos, dejándote confiar en el addEventListener nativo del navegador. Dejando fuera características que no añaden mucho (en su opinión) es como hacen su descarga aún más pequeña. Esto es un poco de compensación porque los puntos de referencia muestran que Preact es un poco más lento que Inferno. Por supuesto, su aplicación puede ser diferente y su kilometraje puede variar. Si realmente necesitas compatibilidad pura con React, hay incluso una librería (preact-compat) que soluciona la mayoría de los problemas durante la compilación.

Hapi

Muchos frameworks llegan en un solo trozo. Hapi es más bien una colección de plug-ins, una constelación de docenas de trozos de código que puedes mezclar en tu pila como te parezca. La autenticación, la autorización y el registro son tareas que pueden resolverse con cualquier número de opciones. Si estás construyendo una arquitectura de microservicios llena de APIs, el plugin Swagger estandarizado generará automáticamente la documentación Swagger a partir de tu código básico.

Koa

A veces necesitas una colección bastante compleja de rutinas que hagan malabares con las peticiones entrantes y las traduzcan en múltiples cambios, algunos de ellos elaborados. Koa está diseñado para que organizar todo este trabajo sea un poco más sencillo. Su secreto es que convierte las funciones de devolución de llamada que normalmente dominan JavaScript en un conjunto de funciones asíncronas que se disparan cuando es el momento adecuado. Las pilas de callbacks anidadas se convierten en algo más limpio.

Nest

Otra opción para domar la complejidad del servidor viene de la mano del equipo Nest, que ofrece una arquitectura llena de controladores, tuberías y proveedores con algunos guardias, interceptores y filtros de excepción para mantener el orden. El marco de trabajo es moderno y está listo para manejar GraphQL y solicitudes de microservicios desde el principio.

Drupal, WordPress y Rails

Los marcos de trabajo que se construyen en JavaScript y que se ejecutan en la parte superior de Node.js llenan el centro psicológico del mundo del desarrollo web en estos días. Pero puede ser un error ignorar la generación anterior construida en PHP, una base que es más rápida que nunca ahora que también tiene un compilador justo a tiempo como JavaScript. Y Ruby y su framework Rails siguen siendo las piedras angulares de sitios web sólidos como una roca.

La última generación está curtida en mil batallas y bien probada por más de una década de desarrollo y trabajo continuos. Hay diseñadores sofisticados que pueden crear temas y pieles para las aplicaciones. Es muy probable que alguien ya haya construido los módulos con la funcionalidad que necesitas. Así que antes de explorar un marco de trabajo Node.js inteligente, considere si uno de los veteranos ya puede hacer mucho, si no todo, de lo que necesita.

Vanilla JS

Podría verlo como una indirecta mezquina o quizás una sátira al nivel de «El traje nuevo del emperador», pero es difícil discutir su éxito. Vanilla JS es un sitio web que se jacta de que su framework se utiliza en más sitios web que «jQuery, Prototype JS, MooTools, YUI y Google Web Toolkit-combinados». Esto puede ser cierto o no, dada la proliferación de jQuery, pero riámonos de la quema. El sitio también viene con un pequeño y bonito selector que te permite agrupar un archivo personalizado de diferentes componentes como Math, DOM, cierres o expresiones regulares. No importa lo que elijas, el resultado es un alucinante cero bytes de longitud. Trate de superar eso!

El punto de la broma es que a veces tiene sentido sólo para utilizar algunos de los elementos estándar en JavaScript y saltar los extras. Bibliotecas y frameworks como jQuery o React comenzaron, en parte, por las enloquecedoras diferencias entre los navegadores. Muchas de estas diferencias han desaparecido gracias a la estandarización.

Por supuesto, los defensores de Vanilla JS no se enfrentan al hecho de que las funciones abreviadas como $() no sólo son convenientes, sino que también ahorran espacio en nuestro propio código. Pero si sólo vas a utilizar el document.getElementById ocasionalmente, puede que no importe. Si sólo vas a añadir unas pocas funciones a tu página web y esas funciones van a hacer unas pocas cosas básicas, el JavaScript sencillo puede ser el marco más rápido para ti.

Deja un comentario