¿Qué es Shiny y cuándo merece la pena?

r
shiny
Shiny como framework web reactivo desde R. Comparación honesta con Quarto Dashboards, Streamlit/Dash y Tableau/Power BI. Cuándo el coste de mantener una app justifica el ROI y cuándo no.

¿Qué es Shiny?

Shiny es un framework de R que te permite escribir aplicaciones web interactivas usando solo R. No necesitas saber HTML, CSS ni JavaScript para tener una app funcional, aunque puedes mezclarlos si te conviene.

Lo que la hace única en el ecosistema R: convierte análisis estáticos en interfaces que un stakeholder no técnico puede usar. Un cliente cambia un selector, mueve un slider, sube un CSV, y los gráficos, tablas y resúmenes se recalculan en vivo.

install.packages("shiny")
library(shiny)

Shiny la desarrolla y mantiene Posit (antes RStudio). Es estable, bien documentado y tiene un ecosistema enorme de paquetes complementarios (bslib, shinyWidgets, DT, plotly, golem, shinytest2…).

Shiny vs Quarto Dashboards

Quarto Dashboards (nuevo, desde Quarto 1.4) genera dashboards estáticos a partir de un documento .qmd. Es importante distinguir:

  • Quarto Dashboards: el documento se renderiza una vez y produce HTML estático. El usuario interactúa con widgets cliente (Observable JS), pero no hay R corriendo en el servidor.
  • Shiny: hay una sesión R viva para cada usuario. Cualquier interacción puede recalcular cualquier cosa con la potencia completa de R.

Cuándo Quarto Dashboards basta:

  • Datos no cambian con frecuencia.
  • La interactividad es limitada (filtros simples, ordenar tablas).
  • No necesitas modelos pesados ni cargas pesadas.
  • Quieres servir el HTML como archivo estático sin servidor R.

Cuándo necesitas Shiny:

  • El usuario puede subir archivos para análisis.
  • Hay modelos que se entrenan o se ejecutan reactivamente.
  • Necesitas escribir en bases de datos.
  • La lógica involucra estado por sesión que cambia con el tiempo.

Resumen: Quarto Dashboards es como un PDF interactivo. Shiny es como una aplicación de verdad.

Shiny vs Streamlit / Dash (Python)

Si vienes de Python o trabajas en un equipo políglota, comparación honesta:

Aspecto Shiny Streamlit Dash
Lenguaje R Python Python
Modelo Reactivo declarativo Reejecución por evento Reactivo declarativo
Curva de aprendizaje Media (reactividad cuesta al principio) Baja (todo se reejecuta) Media (callbacks explícitos)
Performance con apps complejas Buena (solo recalcula lo necesario) Limitada (todo se reejecuta) Buena
Madurez en producción Alta (10+ años) Media (más reciente) Alta
Integración con ecosistema R Nativa N/A N/A

Importante: desde 2022 existe Shiny for Python, la misma filosofía reactiva, en Python. Si tu equipo es mixto, Shiny for Python permite portar conocimiento entre ambos lenguajes. Streamlit es popular pero tiene techo en apps complejas. Dash es la alternativa Python madura.

Shiny vs Tableau / Power BI / Looker

Las herramientas BI tradicionales son distintas en filosofía:

  • Drag-and-drop sin programación.
  • Conexión nativa a almacenes de datos.
  • Compartir y permisos integrados a nivel empresa.
  • Coste por usuario alto en planes corporativos.

Cuándo Tableau/Power BI/Looker ganan:

  • Equipo de análisis sin habilidades de programación.
  • Necesitas integración con SSO empresarial, gobernanza de datos formal.
  • Dashboards relativamente estándar (KPIs, time series, drill-downs).
  • Empresa ya tiene licencias y curva de aprendizaje invertida.

Cuándo Shiny gana:

  • Necesitas lógica de negocio compleja (modelos predictivos, simulaciones).
  • La app NO es solo visualización, incluye flujos de trabajo, entrada de datos, computación.
  • Quieres personalización total sin las limitaciones de un BI tool.
  • Coste de licencias importa (Shiny gratis vs cientos de € por usuario en BI).

Cuándo NO usar Shiny

Esta sección la salta la mayoría. Shiny no es la respuesta correcta cuando:

  1. Tu app es estática (un informe que se actualiza diariamente). Quarto Dashboards o un informe HTML/PDF basta.
  2. Tu audiencia es alta y diversa (miles de usuarios concurrentes, alta latencia esperada). Shiny escala pero requiere arquitectura cuidadosa (Connect, ShinyProxy, balanceadores). Para scale-out masivo, considerar alternativas.
  3. El equipo no domina R. Una app Shiny mantenida por alguien que no sabe R es deuda técnica. Si tu equipo es Python o JavaScript, ve a las herramientas nativas.
  4. El caso de uso requiere offline o desktop. Shiny es servidor, un usuario sin conexión no puede usar la app. Para apps de escritorio offline, alternativas como electron + JS o R Markdown con widgets estáticos.

Coste real de una app Shiny: mantenimiento continuo. Una app que se queda en producción 2 años exige actualizaciones de paquetes, ajustes por cambios de R, gestión de bugs, monitoreo. Si no hay alguien dedicado a mantenerla, es deuda.

Cuándo Shiny SÍ es la respuesta

Casos canónicos donde Shiny brilla:

  1. Dashboards exploratorios con filtros complejos que el equipo de análisis necesita ajustar mensualmente.
  2. Apps de modelado donde el usuario ajusta parámetros y ve impacto inmediato (modelos de pricing, simuladores).
  3. Herramientas internas de gestión que combinan análisis con flujos de trabajo (etiquetar datos, validar resultados, exportar reportes).
  4. Prototipos rápidos para validar una idea antes de invertir en desarrollo full-stack.
  5. Aplicaciones científicas y herramientas de investigación (genómica interactiva, simulaciones epidemiológicas, etc.).

Si tu caso encaja en alguno de los anteriores y tu equipo sabe R, Shiny es probablemente la respuesta correcta.

Trampas habituales

  • Empezar a construir antes de definir audiencia. “Voy a hacer un Shiny” sin saber quién lo va a usar lleva a apps abandonadas. Define usuarios, frecuencia de uso y coste de no tenerlo antes de invertir tiempo.
  • Replicar Tableau con Shiny. Si tu app es 100 % visualización con filtros simples, BI o Quarto Dashboards la harán mejor con menos trabajo.
  • Pasar a producción sin plan de mantenimiento. Apps Shiny en producción degradan con el tiempo: paquetes rompen, R cambia, dependencias se mueven. Si no hay tiempo asignado a mantenimiento, el ROI cae a cero en 6-12 meses.
  • Subestimar el deployment. “Lo desarrollo y luego lo publico”, el “luego” puede ser semanas de complejidad si no has pensado el deployment desde el principio (auth, escalado, monitoreo).

En la siguiente entrega

Tienes el contexto. La siguiente pieza es la anatomía mínima de una app Shiny, las tres piezas que están en todas las apps, desde la más simple hasta una de producción. Es lo siguiente.