Nuestro stack React + Node.js: por qué lo elegimos y cuándo no

Si nos preguntás con qué construimos, la respuesta corta es React en el frontend y Node.js en el backend. Es nuestro default. Unos 70% de nuestros proyectos corren alguna versión de este stack.

Pero “default” no es “siempre.” También manejamos bastantes proyectos en Laravel, Vue y WordPress. La elección depende del proyecto, no de nuestras preferencias. Así pensamos al respecto.

Por qué React

React ganó la guerra de frameworks frontend. Eso no es debatible a esta altura. Tiene la comunidad más grande, el pool de talento más profundo, el tooling más maduro y la variedad más amplia de librerías.

Para nosotros, las ventajas prácticas son:

La arquitectura de componentes escala bien. Una app de 5 pantallas y una de 50 usan los mismos patrones. Cuando la lista de features de un cliente SaaS se duplica en el año dos, no necesitamos reestructurar el frontend.

Contratar es más fácil. Si un cliente necesita aumentar su propio equipo después, encontrar developers de React es más fácil que encontrar developers de Svelte o Solid. No queremos construir algo que el cliente no pueda mantener sin nosotros.

La historia de testing es madura. React Testing Library, Cypress, Playwright. Podemos entregar con confianza.

Donde React es overkill: un sitio de marketing de cinco páginas con un formulario de contacto. Un blog con mucho contenido. Un landing page que solo necesita verse bien y cargar rápido. Para esos, usamos algo más liviano o saltamos el framework JS por completo.

Por qué Node.js en el backend

Cuando el frontend es React (JavaScript), hacer el backend también JavaScript significa un solo lenguaje de arriba a abajo. Suena menor. En la práctica significa:

Nuestros developers se mueven entre frontend y backend sin cambiar contexto. Un developer full-stack en un proyecto Node/React es genuinamente full-stack, no “hago ambos pero uno de ellos mal.”

Lógica de validación compartida. Reglas de validación de formularios, schemas de datos, funciones utilitarias: se escriben una vez, se usan en ambos lados.

El ecosistema npm es masivo. Para la mayoría de problemas, hay un paquete probado en batalla. No reescribimos lo que ya funciona.

El event loop de Node es bueno para workloads heavy en I/O: servidores de API, features en tiempo real (WebSockets, chat, notificaciones) y microservicios que coordinan entre otros servicios. La mayoría de backends SaaS son exactamente este tipo de workload.

Donde Node se queda corto: computación intensiva en CPU. Procesamiento de imágenes, transformación pesada de datos, inferencia de machine learning. Para eso, Python o Go son mejores herramientas. No hacemos trabajo de ML, así que no surge seguido, pero lo diríamos si surgiera.

Cuándo usamos Laravel

Laravel (PHP) es nuestro segundo stack. Lo usamos cuando:

El proyecto tiene mucho contenido. WordPress es PHP. Drupal es PHP. Si el proyecto vive en el mundo WordPress/CMS, Laravel es el backend natural para cualquier funcionalidad custom alrededor. Hemos construido varias plataformas de medios así: WordPress para gestión de contenido, Laravel para APIs custom y procesamiento de datos.

El codebase existente del cliente es PHP. Hemos heredado bastantes proyectos PHP. Reescribir un backend PHP que funciona en Node solo porque preferimos Node sería irresponsable. Mejoramos lo que hay.

El presupuesto es ajustado y el set de features es directo. Las funcionalidades incluidas de Laravel (auth, ORM, sistema de colas, mail, caché) significan menos código custom para funcionalidad estándar. Una aplicación heavy en CRUD con autenticación y panel admin sale más rápido en Laravel que en Express.js, donde estás armando esas piezas vos mismo.

El hosting es un factor. Hosting PHP es barato y disponible en todos lados. Una app Laravel en hosting compartido cuesta $10/mes. Una app Node necesita al menos un VPS o un container. Para negocios chicos que cuidan cada dólar, esto importa.

Cuándo usamos Vue en vez de React

Vue es nuestra elección para:

Proyectos más chicos donde el overhead de setup de React no se justifica. Los componentes single-file de Vue y su modelo mental más simple significan menos boilerplate para una app de 10 páginas.

Mejora progresiva. Tenés un sitio renderizado en el servidor y querés agregar interactividad a componentes específicos sin convertir todo en un SPA. Vue encaja bien para esto.

Proyectos donde el equipo del cliente ya usa Vue. Nos ajustamos a lo que tenés, no a lo que preferimos.

Lo que no hacemos

Go y Rust. No hemos invertido en estos para trabajo de clientes. Son lenguajes geniales con casos de uso claros (APIs de alto rendimiento, programación de sistemas), pero no es donde está la profundidad de nuestro equipo.

Backends Python (Django, Flask). Hemos heredado un par y los mantuvimos, pero no arrancamos proyectos nuevos en Python. Nuestra fortaleza está en los mundos JavaScript y PHP.

Machine learning y data science. Construimos las aplicaciones que consumen outputs de ML, pero no entrenamos modelos ni construimos pipelines. Si tu proyecto necesita eso, podemos trabajar junto a tu equipo de ML o recomendar partners.

Móvil con Flutter o React Native. Hacemos iOS nativo (Swift) y Android nativo (Kotlin). Los frameworks cross-platform ahorran tiempo en papel pero introducen restricciones que preferimos no manejar. Para apps donde el rendimiento y la sensación nativa importan, que es la mayoría de las apps que construimos, nativo es la apuesta correcta.

Cómo elegimos para tu proyecto

Cuando entra un proyecto nuevo, la conversación de stack va más o menos así:

¿Hay un codebase existente? Si sí, trabajamos con él. Sin rewrites por el gusto de reescribir.

¿Es heavy en contenido o heavy en aplicación? Contenido se inclina hacia WordPress/Laravel. Aplicación se inclina hacia React/Node.

¿El equipo tiene preferencias existentes? Si tus developers saben Vue, construimos en Vue. Tu equipo tiene que mantener esto después de que nos vayamos (o junto a nosotros).

¿Cuál es el presupuesto? Proyectos React/Node pueden ser más caros de hostear y deployar. Proyectos Laravel/PHP son más baratos de correr. Para un negocio chico, esa diferencia vale considerarla.

No vendemos un stack. Resolvemos un problema. El stack es lo que sea que lo resuelva mejor.