La red es el eslabón más débil
La mayor parte del tiempo móvil se pasa en redes que funcionan hasta que no: un vagón de metro, un estadio, una carretera rural, una frontera con roaming. Para un corredor que revisa una posición, un repartidor que acepta un pedido o un empleado que escanea un boleto, el momento en que se cae la señal es exactamente cuando la pantalla debe seguir funcionando. Dos modelos en el mismo teléfono manejan ese momento de forma muy distinta.
H5 puede esperar sobrevivir offline. Un mini-programa está construido para ello.
La versión offline de H5 es negociar con el navegador
Una página H5 depende de la red por defecto. Para funcionar offline debe registrar un service worker —y ahí está la trampa—. Los service workers solo corren sobre HTTPS (o localhost), tienen un ciclo de vida de varios pasos (registrar, instalar, activar, obtener) y exigen que el desarrollador escriba a mano la estrategia de caché con la Cache API y los datos persistentes con IndexedDB. Si el registro falla, el scope es incorrecto, la actualización se atasca o el navegador no lo soporta, la página simplemente muere en cuanto se cae la conexión. Muchas páginas H5 nunca lo implementan, así que están muertas offline por omisión.
Incluso cuando hay un service worker, es un hilo de fondo separado con su propio estado y modos de fallo. Una activación atascada o una caché que nunca se actualiza es invisible hasta que el usuario ya mira una pantalla en blanco.
Los mini-programas tratan lo offline como un primitivo
Un mini-programa no añade offline como una ocurrencia tardía. El paquete del programa —framework, shell y primera pantalla— ya está en el dispositivo desde un lanzamiento anterior, y el almacenamiento local le da al programa un lugar duradero y casi síncrono para guardar datos del usuario y contenido frecuente. Cuando se cae la señal, el shell de la app se renderiza desde la caché, los datos en caché aparecen al instante y solo las peticiones en vivo esperan y reintentan. El flujo degrada con gracia en lugar de colapsar.
Por eso el mismo flujo transaccional se comporta tan distinto: H5 busca primero la red y la caché después (si se molestó en crearla); un mini-programa pinta con lo que ya está en el dispositivo y trata a la red como la parte opcional.
De dónde viene realmente la resiliencia
- Paquete precargado. El shell y la primera pantalla son locales; la UI abre sin una vuelta a la red.
- Almacén de datos local. El estado del usuario, las cotizaciones recientes y los borradores de formularios sobreviven a la caída y reaparecen al reabrir.
- Degradación integrada. El runtime pinta la vista en caché y pone en cola las llamadas en vivo; H5 debe codificar todo esto a mano en un hilo de fondo frágil.
- Predecible en redes débiles. Como los activos pesados ya son locales, solo pequeñas peticiones de datos quedan expuestas al enlace inestable.
Cara a cara
| Dimensión | H5 / PWA | Mini-Programa |
|---|---|---|
| Mecanismo offline | Service worker + Cache API + IndexedDB | Paquete precargado + almacenamiento local |
| Activación | Hilo separado, ciclo de vida multi-paso, puede fallar en silencio | Integrado en el runtime, activado por defecto |
| ¿Funciona sin HTTPS? | No — el SW exige HTTPS | Sí — los activos locales no necesitan transporte |
| Comportamiento al caer | En blanco si el SW falta/rompe; en caché si existe | Shell + datos en caché se renderizan; llamadas en vivo reintentan |
| Carga del desarrollador | Estrategia de caché a mano + manejo de actualización | Paquete declarativo + APIs de almacenamiento |
| Exposición en red débil | Página entera re-obtenida | Solo pequeñas peticiones de datos en vivo |
Qué significa para tu flujo
Para cualquier flujo que ocurre en el mundo real —no solo junto al Wi-Fi de un escritorio— la resiliencia offline es una función, no un extra. Una cotización que abre desde la caché, un formulario que guarda el borrador, un boleto que sigue escaneando, son la diferencia entre una acción completada y una pantalla muerta. H5 puede llegar al mismo lugar, pero solo construyendo y manteniendo a mano un trabajador de fondo con estado que la mayoría de las páginas nunca envía.
Dónde encaja Cross Mini App
Cross Mini App es el runtime y el catálogo abierto del modelo offline-por-diseño. Un mini-programa construido una vez contra la superficie de API estándar corre dentro de cualquier host con su paquete precargado y su almacén local intacto, así la pantalla abre y los datos están ahí aunque el enlace no lo esté. La red se vuelve la capa opcional, no la base. H5 sigue siendo la puerta; el mini-programa es la habitación que no se apaga cuando la luz parpadea.
