Qué pila tecnológica para qué proyecto

Los clientes preguntan qué tecnología vamos a usar sorprendentemente pronto, casi siempre en la primera conversación. Es una pregunta razonable y casi siempre es la equivocada para empezar, porque en la mayoría de los proyectos varias respuestas son correctas y la elección la deciden cosas que no tienen nada que ver con la tecnología.

Esto es lo que la decide de verdad.

Dónde tiene que funcionar

Esta es la restricción que nadie ve venir, y la que elimina opciones más rápido.

Una aplicación en PHP funciona en alojamiento compartido corriente. Lo admite cualquier proveedor económico del planeta, cuesta muy poco y no necesita ninguna configuración especial. Una aplicación moderna en JavaScript necesita un proceso Node corriendo de forma continua, que es un tipo de alojamiento distinto y menos disponible. Muchos planes baratos no lo ofrecen en absoluto, y los que lo ofrecen lo ponen detrás de más configuración.

Así que si el alojamiento está fijado, o si el presupuesto de alojamiento es pequeño y permanente, eso decide muchísimo antes de que nadie hable de frameworks. No es una preocupación teórica. Es el motivo más frecuente por el que una elección técnicamente sensata resulta ser la equivocada.

Quién lo mantiene cuando nos vayamos

La segunda pregunta, y pesa más que cualquier comparativa de rendimiento.

Si tu propio equipo va a hacerse cargo del proyecto, constrúyelo con lo que tu equipo ya conoce. Un framework marginalmente mejor que nadie en tu edificio sabe leer vale menos que uno corriente que sí saben leer. Si nadie va a hacerse cargo, la pregunta pasa a ser con qué facilidad podrías sustituirnos, lo que juega a favor de tecnología aburrida y muy extendida frente a cualquier cosa ingeniosa.

En ambos casos la respuesta va de personas, no de rendimiento.

Qué tiene que hacer realmente

Solo en tercer lugar empieza el trabajo en sí a estrechar las opciones, y menos de lo que cabría esperar. La mayoría del software de gestión son formularios, registros, permisos e informes. Prácticamente todo hace eso con solvencia. La tecnología solo se vuelve determinante en los extremos: comportamiento en tiempo real exigente, requisitos de rendimiento inusuales, acceso al hardware, volúmenes de datos muy grandes.

Si tu proyecto no está en uno de esos extremos, y la mayoría no lo está, discutir qué framework es más rápido es discutir sobre una diferencia que tus usuarios no van a percibir nunca.

A qué recurrimos, y cuándo

Nuestro trabajo web va por dos vías, y la separación sigue la pregunta del alojamiento de más arriba.

Laravel y PHP se llevan todo lo que tiene que vivir en alojamiento estándar, todo lo que lleva una parte de administración importante y todo aquello para lo que el cliente quiere un sitio barato, aburrido y permanente. PHP arrastra una mala fama ganada hace dos décadas y hoy en buena medida inmerecida. Laravel en concreto te da autenticación, permisos, una capa de administración y migraciones de base de datos sin tener que montarlas tú, que es exactamente donde una aplicación de gestión gasta la mayor parte de su presupuesto.

Next.js con React va donde la interfaz es el producto. Todo lo muy interactivo, todo lo que tiene estado real que gestionar en el navegador, todo aquello en lo que importan a la vez la velocidad de carga y la visibilidad en buscadores. Esta web funciona sobre eso, y también nuestra demostración de panel, porque una gráfica con retícula y navegación por teclado es precisamente para lo que existe esta pila y precisamente lo que se vuelve doloroso sin ella.

Escribimos TypeScript en lugar de JavaScript a secas en todo lo que esperamos seguir editando el año que viene. El valor no está en tener menos errores el primer día. Está en que un cambio seis meses después te dice de inmediato qué acaba de romper.

Los estilos pasan por Tailwind por un motivo poco lucido: mantiene las decisiones de diseño en el marcado, donde las ves, en lugar de en una hoja de estilos que gana otra capa de excepciones cada vez que alguien va con prisa.

El móvil va a Flutter cuando una app está realmente justificada. Una sola base de código produce iOS y Android, lo que reduce el desarrollo aproximadamente a la mitad y, más importante, reduce a la mitad cada cambio durante el resto de la vida de la app. Lo nativo se gana su coste cuando necesitas integración profunda con la plataforma o el último grado de acabado. Para la mayoría de las apps de gestión es una forma de pagar dos veces.

Para los datos, PostgreSQL o MySQL, y a la escala en la que funciona la mayoría de los proyectos esto de verdad da igual. Coge lo que te dé tu alojamiento. PostgreSQL es la mejor base de datos cuando la elección está abierta y los datos tienen estructura real.

C++ aparece donde el trabajo es software de escritorio o lleva requisitos de rendimiento que una pila web no puede cumplir. Es una respuesta especializada a una pregunta especializada y no debería ser nunca la respuesta a una corriente.

Docker aparece cuando un proyecto tiene más de una pieza en movimiento, o cuando la diferencia entre nuestra máquina y el servidor ha empezado a costar tiempo real.

La pregunta que sí conviene hacer

En lugar de qué tecnología, pregunta qué pasa dentro de tres años.

Si podrás seguir contratando a alguien que sepa esto. Si el framework sigue manteniéndose. Si quieres cambiar de proveedor de alojamiento, si podrás. Si quieres cambiar de desarrollador, cuánto de lo que construimos es estándar y cuánto es nuestro. Esas respuestas te dicen mucho más sobre lo que estás comprando que el nombre de un framework.

Cualquier estudio que responda a "qué pila" con la misma palabra siempre, describas lo que describas, te está hablando de su plantilla y no de tu proyecto.