Por qué React ganó en el frontend, pero el backend siguió siendo poliglota.

React se ha impuesto de manera decisiva en el frontend. El backend nunca ha producido un competidor comparable, y cualquiera que pase de un curso basado en MERN-stack a una empresa con tráfico real suele darse cuenta rápidamente de ello.

Los bootcamps suelen presentar Mongo, Express, React y Node como una solución completa: un único lenguaje para toda la pila tecnológica, lo que permite desarrollar aplicaciones full-stack con facilidad. Los proyectos personales y las implementaciones pequeñas de tipo CRUD parecen confirmar esto. Sin embargo, un primer empleo en una empresa con millones de usuarios muestra una imagen diferente. La interfaz de usuario es React, como era de esperar. Los servicios principales están escritos en Java, los microservicios de alto rendimiento en Go, y el pipeline de aprendizaje automático en Python. Node.js aparece principalmente en una capa ligera que agrega APIs para el frontend. A gran escala, funciona como un asistente útil para los backends complejos, y las razones son específicas.

Razón número uno: un hilo, muchas tareas

Node.js ejecuta JavaScript en un único hilo. Maneja las operaciones de entrada/salida de manera excelente, pero solo realiza una tarea que requiera mucho procesamiento del CPU a la vez. Imagina un restaurante con un camarero extremadamente rápido: tomar pedidos, que equivale a manejar bases de datos y redes, no representa ningún problema. Sin embargo, si un cliente pide un menú de cinco platos que requiere treinta minutos en la cocina, lo cual simboliza el trabajo del CPU, ese camarero se queda atascado mientras todos los demás esperan.

Una plataforma de videos muestra lo que esto significa en entornos reales. Un usuario sube un archivo en 4K, y el servidor debe:

1. Recibir el archivo.
2. Transcodificarlo a varias resoluciones, como 1080p, 720p y 480p.
3. Generar miniaturas.
4. Extraer metadatos.
5. Almacenar los resultados en los lugares adecuados.

Ejecutar todo eso dentro del proceso de Node bloquea su bucle de eventos. Otras subidas esperan, otras llamadas a la API se ponen en cola y la aplicación deja de responder. Java y Go utilizan múltiples hilos, por lo que uno puede procesar el video mientras otros atienden el tráfico de la API y la autenticación. Node es excelente para tareas dependientes de E/S como APIs, chat en tiempo real y transmisión de datos. Las tareas dependientes de la CPU son su punto débil, y las aplicaciones grandes contienen muchas de ellas.

Segundo motivo: los microservicios permiten que cada equipo elija

Las grandes empresas en su mayoría dejaron de crear monolitos. Un monolito reúne la autenticación, los pagos, las notificaciones y las recomendaciones en una única base de código. Una arquitectura de microservicios las divide en servicios independientes que se comunican a través de la red.

Esa división permite que cada equipo elija un lenguaje. Un equipo de pagos puede optar por Java porque está probado en transacciones financieras. Un equipo de chat en tiempo real puede elegir Go por su capacidad para mantener miles de conexiones simultáneas. Un equipo de recomendaciones puede elegir Python por sus bibliotecas de aprendizaje automático. Node termina siendo una de las opciones entre varias y rara vez la predeterminada.

Por qué Go y Java dominan

Go surgió en Google, diseñado para solucionar los problemas de los lenguajes anteriores. Sus fortalezas:

• Concurrencia. Las gorutinas pueden mantener un enorme número de conexiones simultáneas con muy poca memoria.
• Arranque. Los programas se compilan a código máquina nativo y se ejecutan casi al instante.
• Despliegue. Solo se envía un único binario sin dependencias en tiempo de ejecución.

Uber depende de él para algunos de sus servicios más concurridos, Twitch para el chat en tiempo real, y Dropbox informó grandes mejoras en el rendimiento tras trasladar partes de su infraestructura desde Python.

Java ha sido la opción estándar en el ámbito empresarial durante más de 25 años. Aunque ya no está de moda, es fiable:

• Está probado en el sector bancario, las aerolíneas y el comercio electrónico a gran escala.
• Su ecosistema incluye Spring Boot, Hibernate y miles de bibliotecas.
• El tipado estático detecta muchos errores en tiempo de compilación, antes de la puesta en producción.
• Las herramientas de perfilado, monitoreo y depuración se han perfeccionado durante décadas.

Netflix, Amazon y Airbnb ejecutan partes importantes de su backend con este lenguaje. Estas organizaciones necesitan fiabilidad a una escala enorme y no siguen tendencias.

Tercera razón: legado e inercia

Las grandes empresas tienen una larga historia. Amazon fue fundada en 1994, Netflix en 1997 y Google en 1998. Cuentan con millones de líneas de código en Java, C++ y Python, infraestructura desarrollada a lo largo de décadas, y ingenieros expertos en esos lenguajes. Una reescritura en Node solo por ser lo último en moda no está en consideración. Un CTO de una gran corporación no arriesgará el sistema de pagos, la parte que genera ingresos directamente, con un lenguaje nuevo solo porque es popular entre los desarrolladores en línea.

Por qué React es la excepción

Esas mismas empresas adoptaron React porque resolvió un problema real. Antes de él, las interfaces de usuario complejas eran problemáticas: jQuery complicado, patrones de Backbone confusos y el ciclo de procesamiento de Angular 1.x. React introdujo la arquitectura de componentes, un DOM virtual para mejorar el rendimiento, una interfaz de usuario declarativa y un enorme ecosistema que incluye Next.js y React Native. Ganó porque era mejor que las alternativas.

Node nunca ha tenido un momento equivalente de necesidad imperiosa en el servidor. Es una buena opción sólida para usos específicos, pero para la mayoría de las tareas serias de backend no es claramente mejor que Java, Go o Python, por lo que no es la elección automática.

Cómo se estructura una aplicación grande

Un diagrama típico muestra al frontend de React llamando a una pasarela de API, una ruta que envía cada solicitud al servicio backend adecuado. Detrás de esto:

• Un backend-for-frontend de Node.js se encarga de la lógica específica del frontend, la agregación de APIs y los eventos en tiempo real. Aquí es donde Node destaca.
• Los servicios principales de Java gestionan los pagos, los pedidos, la autenticación de usuarios y el inventario, las partes que no pueden fallar.
• Los servicios de Go se ocupan del chat en tiempo real, la transmisión en streaming y cualquier tarea que requiera una alta concurrencia.
• Los servicios de Python se encargan de las recomendaciones, el procesamiento de imágenes y el análisis de datos.

Cada servicio posee sus propias bases de datos, y los servicios se comunican mediante gRPC, WebSockets o colas de mensajes como Kafka. El frontend tiene un ganador claro. El backend es poliglota, y la herramienta adecuada se encarga del trabajo.

Una comparación rápida de los lenguajes

• Node.js es ideal para startups, MVPs y capas BFF. El desarrollo es rápido, el ecosistema npm es enorme y hay desarrolladores de JavaScript por todas partes. No es adecuado para el procesamiento de video o transacciones financieras.
• Java es el trabajo duro fiable. Tiene una curva de aprendizaje pronunciada y un inicio lento, pero es la opción a elegir cuando un fallo a las 3 de la mañana en Black Friday es inaceptable.
• Go es como podría ser un lenguaje de backend si se diseñara desde cero hoy en día: rápido, simple y concurrente. Su desventaja es que su ecosistema es más joven que el de Java.
• Python domina la ciencia de datos y el aprendizaje automático. Sin embargo, para APIs de alta concurrencia, el Global Interpreter Lock representa un verdadero cuello de botella.
• C++ es adecuado para casos que requieren una velocidad extrema, como motores de juegos, sistemas embebidos y operaciones de trading de alta frecuencia. No está diseñado para APIs web.

Qué significa esto para los desarrolladores junior

Nada de esto hace que Node sea malo. Sigue siendo una excelente opción para startups y MVPs donde es crucial la rapidez de lanzamiento al mercado, para capas backend para frontend, para funciones en tiempo real como chats y actualizaciones en vivo, para funciones sin servidor en AWS Lambda o Vercel Edge, y para prototipos destinados a probar ideas antes de optar por una solución más compleja.

Quien pretenda trabajar en una gran empresa no debe confiar únicamente en MERN. La costumbre más útil es aprender cómo funcionan los sistemas, para así poder elegir la herramienta adecuada para cada tarea. La mentalidad errónea es pensar que conocer JavaScript significa poder hacerlo todo.

Los desarrolladores más competentes no se aferran a un solo lenguaje. Una misma persona puede escribir código en JavaScript para la interfaz, utilizar servicios en Java al revisarlos, comprender por qué un equipo eligió Go para un microservicio y reconocer cuándo Python es la opción más adecuada. Son políglotas porque entienden que diferentes problemas requieren soluciones distintas, no porque quieran presumir.

La herramienta adecuada para cada tarea

React se ha impuesto en la capa de interfaz y todas las empresas importantes lo utilizan por buenas razones. El backend se describe mejor como un ecosistema que como una competencia. Java, Go, Python, C++, Rust y Node tienen su lugar, y las empresas que desarrollan aplicaciones cotidianas no obligan a usar solo un idioma.

El objetivo de un desarrollador es resolver problemas, no utilizar el idioma con el que ya está familiarizado; a veces eso significa aprender algo nuevo. Un desarrollador junior que posee un certificado MERN no debe entrar en pánico. Node es un buen punto de partida. Sigue avanzando desde allí: examina un proyecto Java Spring Boot, escribe un pequeño microservicio en Go, y averigua por qué el servicio de pagos de la empresa está escrito en Java y no en JavaScript. Los mejores ingenieros no son aquellos que conocen más idiomas, sino aquellos que saben por qué existe cada uno y cuándo usarlo.

Leer más

• Configurar un frontend de React con Node, npm y Vite — Asociar herramientas de estilo Python a una pila de React y Vite: instalar Node, ignorar node_modules, crear la estructura básica con Vite y ejecutar el servidor de desarrollo local.
• Más allá de CRUD: Diez hábitos arquitectónicos que mantienen las aplicaciones MERN mantenibles — Conocer los hábitos a nivel de sistema que mantienen una aplicación MERN saludable a medida que crece: propiedad de los datos, contratos de API, estado derivado, código en capas, cargas ligeras y errores consistentes.

¿Cuántas solicitudes puede manejar realmente un servidor Node.js? — Pruebas de carga de una API Express en Heroku y AWS en comparación con Django, una estimación de capacidad de 40K rps, y los factores que ralentizan a las APIs reales.