El mundo del desarrollo Front-end está experimentando actualmente una notable metamorfosis, con los límites entre los roles de Front-end, Back-end y DevOps volviéndose cada vez más borrosos. Esta fascinante transformación ha sido impulsada por la aparición de frameworks como Angular, Vue y SolidJS, que actúan como conductos hacia el ámbito de los datos de las bases de datos.

La Revolución de los React Server Components ⚙️

Con la próxima versión de React a la vuelta de la esquina, la distinción entre el trabajo de Front-end y Back-end está a punto de volverse aún más difusa. Los React Server Components están de moda en estos días, en parte debido a la relación simbiótica entre el proyecto Next.js y el equipo de React. A medida que los React Server Components surgen como una característica muy esperada en la próxima iteración de React, la necesidad de APIs separadas podría evaporarse, facilitando a los desarrolladores Front-end involucrarse en las operaciones de Back-end.

La Colaboración Entre Equipos Front-end y Back-end 👥

Esta mayor sinergia podría llevar a una colaboración más armoniosa, donde los equipos de Front-end y Back-end trabajen juntos en el mismo repositorio o código base. Si bien este enfoque de pila completa no es nuevo para aquellos familiarizados con la forma de pensar de Ruby on Rails o PHP, puede ser un verdadero descubrimiento para los desarrolladores que se han formado en frameworks tradicionales como AngularJS o BackboneJS. 

Adoptando el Cambio y el Futuro sin APIs 🚀

Debemos recibir estos cambios con los brazos abiertos, ya que no solo fomentan una mejor comunicación entre los miembros del equipo, sino que también agilizan todo el proceso de desarrollo. El futuro está lleno de emocionantes oportunidades para que los ingenieros Front-end y Back-end trabajen en conjunto dentro de un panorama en constante evolución. La idea de que las API se conviertan en un anacronismo puede parecer descabellada, pero con el lanzamiento inminente de la nueva versión de React y sus React Server Components, esta idea comienza a parecer cada vez menos como ciencia ficción.

React Server Components: Flujos de Datos Unidireccionales y Más 🔄

A medida que profundizamos en el mundo de los React Server Components, comenzamos a comprender sus ventajas, incluso cuando luchamos con su complejidad. Un aspecto particularmente intrigante de los React Server Components es su capacidad para integrar el servidor en el flujo de datos unidireccional de React. Aunque proyectos como Remix y Next.js han intentado este enfoque, sus esfuerzos a veces han sido insuficientes, lo que lleva a un flujo inconexo cuando las rutas no coinciden con los requisitos de datos. Los React Server Components, sin embargo, permiten un flujo sin interrupciones al permitir que los componentes soliciten y reciban los datos que necesitan con un mínimo de problemas.

Imagina un mundo en el que podrías obtener datos para una interfaz sin tener que implementar código del lado del cliente para lograrlo, solo HTML transmitido desde el servidor al cliente. Esto no solo simplifica las conexiones de bases de datos, sino que también elimina preocupaciones sobre la serialización y los tipos de datos.

Desafíos y Ventajas en el Uso de React Server Components como APIs 💡

Por supuesto, aún quedan desafíos, como encontrar el equilibrio adecuado entre la administración del estado y la separación de archivos para archivos exclusivos del cliente y aquellos que requieren un marcador useClient para fines de compatibilidad. Sin embargo, las innumerables ventajas de usar React Server Components como APIs, envolviendo otro componente con datos, no pueden ser exageradas.

El soporte nativo de React para actualizar contenido a través de iteradores incluso podría utilizarse dentro de los componentes. A medida que indagamos más en estas posibilidades, la perspectiva de un mundo sin API se vuelve cada vez más tentadora.

Conclusión: Adoptando React Server Components y Explorando Nuevas Posibilidades 🏁

En conclusión, aunque todavía hay aspectos por pulir, como encontrar el patrón perfecto de separación de archivos, la incorporación de React Server Components en nuestro proceso de desarrollo seguramente generará una gran cantidad de características invaluables. ¡Así que estén atentos a más innovaciones que profundizan esta revolución que esta pasando frente a nosotros!

La Inminente Revolución de las API: Cómo los React Server Components Están Cambiando el Juego

La manera en cómo React se ha apropiado del mundo del web development ha sido impresionante. Esto se le puede atribuir a muchos factores. El primero de ellos es que, React tuvo mucha ayuda y respaldo de varios lugares, empezando por la gente de Facebook (sus creadores) quienes colaboraron férreamente y propiciaron que muchos developers decidieran dar el salto inicial hacia React.

En este mundo de rápida evolución y avance, en ocasiones, es sencillo el perder la noción del tiempo. Tan es así, que, no hace mucho que Angular era el rey indiscutido del mundo del web development, sin embargo, ocurrió algo inesperado, Google, la compañía detrás de Angular, decidió que, para conmemorar el lanzamiento de su segunda versión, Angular 2, iban a reescribir todo el framework desde cero, básicamente haciendo instantáneamente obsoleta la primera versión de Angular.

El decir que esa fue una decisión controversial seria quedarse corto.

Mucha gente -y me sumo a la multitud- quedamos estupefactos ante tal hecho, se dijeron y pensaron mil cosas ante tal acontecimiento, pero por mucho, la duda más grande era si el equipo de Angular haría lo mismo para la versión 3 de su framework, el cual, convenientemente, ahora cambiaria de versión cada 6 meses. Es decir que, basado en lo que habían hecho, existía la posibilidad de tener que aprender un framework nuevo cada 6 meses.

A todas estas, y un poco más astutos, la gente de Facebook vio una oportunidad enorme: ¿Por qué no atraer a los desilusionados de Angular y tratar de hacerlos parte permanente de nuestra base de usuarios?

Hay que admitirlo, fue una estrategia brillante y los resultados hablan por sí solos:

Esta gráfica muestra las estrellas en Github respectivas a cada proyecto y si bien no son un marcador definitivo, dan una idea bastante acertada del interés en cada uno en particular. De igual manera, podemos observar la destitución del trono que sufrió Angular. A todo esto, cabe aclarar que esta gráfica toma en cuenta la versión 2+ de Angular.

Un dato curioso, relativo a Angular, es que la gente de Google se irrita un poco cuando la gente llama a su framework por cada número de versión que lleva. Actualmente, estamos viviendo en la era de Angular 6 y mucha gente así se refiere al framework, sin embargo, si quieres seguir la convención lingüística que quiere Google, a la versión 1 le llamaras AngularJS y a la versión 2 en adelante, simplemente le llamaras Angular.

Esos y otros errores de gran significado, muchos en la presentación y marketing de Angular, contribuyeron de manera definitiva a la popularización de React.

Si bien es cierto que React es una librería y no un framework de cabo a rabo, el ecosistema ha facilitado que pueda contender con Angular y Vue prácticamente como si fuera un framework completo.

Al ver la gráfica, seguramente notaste que se encuentra incluido el proyecto Vue, un framework que muy recientemente supero a React en cuanto a las estrellas en Github. Vue combina lo que muchos consideran las mejores partes de React & Angular para crear un framework integro con constantes innovaciones como su interfaz grafica que fue recientemente presentada al mundo, la cual, nos permitirá manejar y crear aplicaciones de Vue desde una interfaz intuitiva y amigable.

Este tipo de innovaciones en Vue, son algo que constantemente nos ofrece a los entusiastas de este framework y no cabe duda que el equipo de React ya debe de haber tomado nota, por lo que es muy probable que pronto tengamos noticias importantes con respecto a si React seguirá siendo el rey o si tal vez habrá una nueva coronación en el mundo del web development.

Porque React Seguira Siendo El Rey Del Front-End 👑

A veces el mundo del desarrollo web se mueve tan rápido que es fácil perderse detalles importantes, especialmente en el mundo del front-end. Por ejemplo, únicamente tomo un par de años para que React se volviera el rey de nuestro espacio, en parte por sus propios esfuerzos y en parte gracias a Google y los errores que cometió al pasar su framework, AngularJS, a su segunda versión.

Pero mientras los personajes mas importantes de nuestro espacio trataban como pudieran de acaparar la atención de nosotros los desarrolladores, algo muy especial estaba pasando por debajo.

VueJS es un proyecto que comenzó por parte de Evan You, un desarrollador que estaba trabajando en Google para AngularJS (ouch) antes de decidir que quería tomar todas sus partes favoritas de AngularJS sin todos los conceptos adicionales que no eran fundamentalmente necesarios. Un framework mejor, mas ligero y simplemente, mas amigable para la comunidad de desarrolladores como él.

Desde ese entonces, VueJS ha crecido de un pequeño proyecto a un titan en su propio derecho dentro del ecosistema de desarrollo web. Y no estoy haciendo mofa ni mucho menos, tan solo hace unas semanas fue que VueJS supero a React en estrellas en Github.

Ahora, podemos debatir de aquí al Domingo si esa es una medida justa en cuanto al uso que le dan o no los desarrolladores a una tecnología sobre otra, pero los hechos son claros – VueJS es tremendamente popular.

VueJS se encuentra actualmente en su segunda versión, lo cual es muy interesante ya que la primera versión fue tan popular -como en su momento lo fue AngularJS- pero sin tener las complicaciones y tropiezos que este ultimo tuvo al pasar a la segunda versión.

De hecho, prácticamente fue el opuesto geométrico de la situación de AngularJS.

Todos los desarrolladores queríamos ver a donde iba a ir el framework y trajo consigo muchas innovaciones muy interesantes. Una innovación que ha causado mucho revuelo es la muy reciente Vue CLI UI, que no es otra cosa que una interface grafica para que los desarrolladores creen y manejen sus aplicaciones de VueJS.

Esto podrá sonar simple, pero hizo a muchos voltear la cabeza y darse cuenta de que VueJS va muy enserio por el trono de los frameworks.

Tan es así que miembros de las comunidades de React y Angular están tratando de desarrollar algo sensiblemente similar para dichas tecnologías. Por lo pronto, VueJS no se ve en tantos proyectos en producción como React o Angular, pero que no te sorprenda si eso cambia en el no muy distante futuro.

Si eres parte del mundo del web development, seguramente sabrás la velocidad tan rápida a la cual se mueven las cosas. Paradigmas enteros, mejores prácticas y tecnologías que ayer parecían estar al borde de la modernidad son habitualmente reemplazados.

A lo mejor perteneces a esa camada -o conoces a alguien- que piensa que la era cuando PHP/MySQL eran omnipresentes fue la época dorada de nuestra industria. Tan buenas y probadas son estas tecnologías, que muchos stacks todavía las incluyen en conjunción con otras un poco más modernas.

Honor a quien honor merece: esas tecnologías junto con algunas otras contemporáneas de las mismas marcaron todo lo que vendría después y nos han dejado una legacía permanente. Y hablando de legacías, existen muchos puntos de contención donde mentes de la vieja escuela están tratando de traer los beneficios de todos esos años usando dichas tecnologías a la escena moderna de desarrollo web.

Uno de los beneficios mas notorios de PHP, al menos en cuanto a el ambiente de desarrollo se refiere, era la forma tan simple como podías desplegar aplicaciones. Simplemente creabas una serie de archivos, escribías el código de las aplicaciones, hacías las pruebas que fueran necesarias y mandabas todo a producción.

No existían ciertas consideraciones esenciales del mundo actual de desarrollo. El routing se manejaba prácticamente por sí solo, no tenías preocupación por manejar SSR y la configuración era trivial en muchos casos, comparado a como tienes que estar pendiente de que tus task-runners estén perfectamente calibrados hoy en día.

Las preocupaciones que menciono no se veían limitadas al ambiente de desarrollo, había también implicaciones en cuanto al lado corporativo. Por ejemplo, hacer SEO (Search Engine Optimization) era un proceso mucho mas manejable y que en realidad no impactaba el mundo de los desarrolladores demasiado. Asegurarse de que el SEO de tu aplicación este correctamente en su lugar es prácticamente un trabajo de tiempo completo por sí mismo.

Y si bien es cierto que Google y los otros motores de búsqueda están constantemente mejorando sus algoritmos para poder entender las aplicaciones modernas, ese fue definitivamente un punto de daño colateral al momento de la modernización y la tendencia actual de que todas las tecnologías del stack sean de JavaScript.

Pues como suele ocurrir, algunas de las mentes de la vieja escuela de las cuales hable anteriormente decidieron que estos problemas podrían ser solucionados usando los paradigmas del pasado. Es así como nace NextJS, un framework en tope de React que ofrece soluciones practicas a las preocupaciones que mencione y muchas más.

Usando NextJS es posible crear páginas y componentes en React con el routing automáticamente hecho por nosotros, la cuestión del SEO se facilita bastante por medio del SSR y el posible de aprovechar todo ese enorme ecosistema moderno de módulos y paquetes de NPM siguiendo un workflow extremadamente similar al que utilizas al hacer apps de React.

Hace unos pocos meses salió la versión 10 de NextJS y es difícil no estar emocionado por ver a donde llevan los creadores y contribuyentes de esta increíble nueva tecnología en los meses y años venideros.

NextJS Marca Un Nuevo (Y Genial) Paradigma Para React 🤩

Una vez más parece que Facebook quiere conquistar un sector adicional del desarrollo web. No ha sido suficiente para el gigante de Sillicon Valley apoderarse de la oportunidad que les puso Google de frente al crear y popularizar React, así como crear su propia alternativa al Node Package Manager con Yarn, sino que al parecer quieren tomar parte en todos los aspectos del stack de las aplicaciones web modernas.

Como bien sabes, una de las partes mas importantes de cualquier proyecto es la base de datos y el cómo tu aplicación interactúa con ella. Ya desde hace varios años, si decides crear y usar una API, la respuesta era obvia: tiene que ser una REST API. La mayoría de los developers nos sentimos cómodos utilizando APIs tipo REST ya que sirven y seguirán sirviendo eficientemente nuestras necesidades, de hecho, seria correcto el decir que las APIs tipo REST son el estándar de oro en el mundo del desarrollo web moderno.

Pero lo que seguramente diremos en el futuro, es que hay un nuevo contendiente dentro del ecosistema. Estoy hablando, como podrás adivinar, de GraphQL.

GraphQL no es otra cosa mas que un lenguaje de consulta relacional que es agnóstico al tipo de base de datos o método de almacenamiento que utilices.

La segunda parte de mi definición es lo que ha atraído la atención de muchos developers y es el motivo por el cual GraphQL esta rápidamente ganando adeptos dentro de la comunidad del desarrollo web. También cabe mencionar el hecho de que GraphQL es relativamente fácil de usar y los servicios que puedes crear con el prácticamente se leen como Inglés común y corriente.

En otras palabras, GraphQL es altamente intuitivo.

La otra cara de esta moneda tiene que ver con algo bastante nuevo dentro de la industria y es el hecho de que no todo mundo se siente cómodo utilizando mas y mas herramientas creadas y respaldadas por una misma compañía. No se diga considerando que estamos hablando de Facebook.

Ha habido controversias con otras tecnologías provenientes de Facebook. Si bien Yarn se ha convertido en un serio competidor a NPM a escasos 5 años de que fue anunciado en Octubre del 2016, hay ciertos developers que encontraron que las primeras versiones de esta tecnología enviaba información de las aplicaciones que la utilizaban a los servidores de Facebook sin el consentimiento previo del developer.

Ese problema fue arreglado al poco tiempo de ser descubierto, pero no es la primera ni la última controversia que una tecnología proveniente de Facebook va a levantar.

Si no tienes una opinión del todo favorable en cuanto a Facebook y sus prácticas con la información de sus usuarios -como yo, por ejemplo- nadie te va a culpar si te reúsas a utilizar React, Jest, GraphQL, Yarn o cualquier otra tecnología proveniente de dicha compañía.

Pero los hechos están claros, Facebook quiere seguir avanzando su aventura dentro del mundo open source y quiere estar envuelto

GraphQL & Porque Facebook Quiere Ser El Pilar Central De Tu Próximo Proyecto 📘

Después de aprender a operar React, es completamente normal -quizás hasta predecible- que vas a comenzar a leer acerca de Redux, y que, como consecuencia, luego de echar un vistazo a todo lo relativo a esta biblioteca de código abierto, probablemente tengas más dudas que certezas. No te culpo, es algo completamente habitual.

Déjame ayudarte a esclarecer un poco tus dudas; según la página oficial, podríamos usar la siguiente definición:

¿Complicado?, no tanto. Déjame explicarte.

Al saber React, seguramente estarás familiarizado con el concepto de state, pero el resto de esas palabras parecen no pertenecer a una misma oración coherente. Bueno, al menos al principio. Afortunadamente, el siguiente párrafo contiene información un poco más clara:

Si revisas la documentación de Redux un poco mas a fondo, vas a ver esta frase una y otra vez:

Redux será la fuente de verdad para tus datos

Al estar los componentes tan fragmentados -y esto es apropósito- es muy fácil que el comunicar el state entre ellos se vuelva una tarea innecesariamente complicada. En otras palabras, Redux nos puede ayudar a mejorar y optimizar la comunicación del state entre nuestros componentes al ser la única fuente de state y sus mutaciones. Una fuente única de verdad.

Y no hace falta argumentar demasiado para ver y saber que Redux es un absoluto monstruo del mundo de web development y ciertamente dentro del ecosistema de React. Tan es así el caso, que mas del 60% de las apps de React en producción utilizan Redux. ¡Eso es muchísimo!

La cifra anterior es de acuerdo a Mark Ericsson, quien es uno de los mantenedores de Redux. La figura anterior se vuelve incluso más impresionante al notar que no se están tomando en cuenta alternativas a Redux como lo son la popular MobX.

En cuanto a mi opinión, soy de los que piensan que manejar el state de tu app (incluso si no es de React) con una librería como Redux es inteligente, porque provee un sistema bastante explicito para manejar el state de tus apps, eso sin tomar en cuenta lo bien que tus apps irán escalando y lo organizado de tu código al usar Redux exclusivamente.

¿Es Redux absolutamente necesario para tus apps de React? No, pero usarlo termina casi siempre siendo una muy buena idea. Al principio es probable -tal vez hasta preferible- que puedas manejar todo con setState(), pero si tu app es de tamaño mediano a grande, vas a llegar a la conclusión de que utilizar Redux es una buena inversión de tu tiempo.

Debo de mencionar el hecho de que hay susurros de que la nueva Context API presente en React a partir de la version 16.5 va a causar que muchos pongan a Redux y a otras librerías similares de lado. Pero como cualquier tecnología nueva, va a tomar un tiempo en volverse el nuevo estándar, incluso si es el reemplazo definitivo de Redux, lo cual en mi modesta opinión, no estoy convencido que vaya a ser así.

¿Es Redux Absolutamente Necesario Para Tus Apps de React? 🤔

📝 Ultimos Posts

La Inminente Revolución de las API: Cómo los React Server Components Están Cambiando el Juego

Porque React Seguira Siendo El Rey Del Front-End 👑

VueJS: ¿Revolución o Hype?🎉

NextJS Marca Un Nuevo (Y Genial) Paradigma Para React 🤩

GraphQL & Porque Facebook Quiere Ser El Pilar Central De Tu Próximo Proyecto 📘

¿Es Redux Absolutamente Necesario Para Tus Apps de React? 🤔