Cuándo la tesis no compensa

Caso 1 · El equipo no va a aprender Rust

Es el más común y el que más se niega. La señal no es que nadie sepa Rust hoy —eso se arregla—, sino que no hay intención real de aprenderlo: no hay tiempo asignado, nadie lo pide, y el plan tácito es que una persona escriba el core y los demás no lo toquen.

Ese plan falla siempre por el mismo sitio. Esa persona se va, o se satura, o simplemente está de vacaciones el día que hay que arreglar algo en el core, y el proyecto se para. Un core que solo una persona puede tocar no es una arquitectura: es un cuello de botella con nombre y apellidos.

La alternativa concreta: Wails, si el equipo tolera Go; Electron, si el equipo es de JavaScript y no va a moverse de ahí. Las dos producen mejor software que un Rust escrito a regañadientes. Nivel 2.2 y 2.3.

¿Se puede mitigar? Sí, con una decisión de verdad: dos personas aprendiendo, tiempo asignado, y el track de Rust antes de la fase III. Si esa decisión no se toma, el caso es estructural.

Caso 2 · La interfaz es el producto y es exigente

Si tu vista principal es una línea de tiempo, un lienzo de nodos, un editor de vídeo o una tabla con cientos de miles de filas que cambian a la vez, estás pidiéndole a un motor de documentos que haga el trabajo de un motor de dibujo. Se puede, con virtualización y cuidado, y aun así el techo lo pone el motor —y el motor más lento de los tres marca el mínimo—.

La alternativa concreta: el campo del render propio. Nivel 2.4.

¿Se puede mitigar? A veces. Si la vista exigente es una dentro de una aplicación por lo demás normal, se puede resolver con un canvas o WebGL para esa vista y HTML para el resto. Si es la aplicación entera, no.

Caso 3 · Dependes de librerías de Node sin equivalente

Un core que necesita un motor de plantillas concreto, un cliente de un servicio que solo existe en npm, una librería de procesamiento con años de reglas de negocio dentro. Reescribir eso en Rust no es un detalle de migración: es el proyecto.

La alternativa concreta: Electron, donde esas librerías corren en el proceso principal sin envoltura. O, si la dependencia está acotada, un sidecar —un proceso de Node empaquetado junto a tu aplicación— que el nivel 46 explica. El sidecar funciona y tiene un coste: vuelves a enviar un runtime dentro del instalador, que es justo lo que la tesis pretendía evitar.

Caso 4 · Accesibilidad certificada en todas las plataformas

Aquí conviene un matiz, porque la conclusión no es la que parece. La accesibilidad de una webview es buena: se hereda del navegador, con roles, foco y lectores de pantalla. Ese es un argumento a favor del campo, no en contra.

El problema es de uniformidad. Si tu contrato exige un comportamiento certificado con el lector de pantalla de cada sistema, estás dependiendo de tres implementaciones distintas del puente entre el motor y la capa de accesibilidad del sistema operativo, y esas tres implementaciones no están igual de pulidas. Lo que en Windows y macOS funciona bien, en Linux puede necesitar comprobación caso por caso.

La alternativa concreta: un framework que envuelve controles nativos, donde la accesibilidad es la del sistema por construcción. Nivel 2.4.

¿Se puede mitigar? En gran parte, sí: escribiendo HTML semántico y probando con lectores de pantalla reales desde el principio. Lo que no se puede es dar por hecho.

Caso 5 · Necesitas publicar todos los días

Cada versión de una aplicación de escritorio pasa por compilar en tres sistemas, empaquetar, firmar, notarizar y publicar un manifiesto. Automatizado, eso son entre decenas de minutos y horas. Si tu producto vive de iterar varias veces al día con los usuarios, ese ciclo es incompatible con tu forma de trabajar, y no es un problema de Tauri: es del escritorio entero.

La alternativa concreta: una aplicación web. Y si de verdad necesitas capacidades del sistema, el reparto mixto del nivel 1.5: la web es el producto y una app instalada pequeña hace lo que la web no puede.

¿Se puede mitigar? Parcialmente, empujando la lógica que cambia a menudo al frontend y sirviéndolo desde la red en vez de empaquetarlo. Ojo: eso reabre la puerta al contenido remoto, que es el nivel 32 y no es gratis.

Caso 6 · Todavía no sabes qué estás construyendo

Un prototipo que va a cambiar de forma cinco veces en dos meses no se beneficia de nada de lo que Tauri ofrece, y sí paga todo lo que cuesta: la curva de Rust, tres motores que probar, y un empaquetado que aún no lleva a ninguna parte.

La alternativa concreta: constrúyelo como una web. Cuando sepas qué es, empaquetarlo con Tauri es un trabajo de una tarde —el nivel 5 lo hace paso a paso— porque tu frontend ya es tu frontend. Esa es, de hecho, una de las mejores propiedades del framework: llegar tarde a Tauri es barato.