WebGPU ahora disponible para pruebas en Safari Technology Preview

Artículo original ↗ Discusión en Hacker News ↗

La decisión de Apple de habilitar WebGPU en Safari Technology Preview se interpreta como una señal de que está acelerando el desarrollo de WebKit y preparándose para competir más seriamente con los navegadores basados en Chromium, especialmente porque las normas de la UE podrían obligarla a permitir motores alternativos en iOS. Los comentaristas esperan que WebGPU desbloquee gráficos 3D en el navegador, juegos e incluso cargas de trabajo de IA en el propio dispositivo, al tiempo que debaten si esto fortalece o debilita el modelo de Apple centrado en la App Store y el papel a largo plazo de las apps nativas frente a las PWA. También hay escrutinio sobre las implicaciones de seguridad y rendimiento de WebGPU, y sobre la fuerte influencia de Apple en el diseño del estándar, que se parece mucho a su API Metal y favorece un lenguaje de shaders textual (WGSL) frente al bytecode SPIR-V.

La estrategia de Apple con WebKit y la competencia entre navegadores

  • Varios comentaristas sienten que Apple está invirtiendo más en WebKit, cerrando la brecha de funcionalidades con Chromium y, a menudo, liderando en algunas capacidades de JS/CSS.
  • Muchos vinculan esto con la regulación inminente (por ejemplo, verse obligada a permitir otros motores en iOS) y con el deseo de Apple de evitar un monocultivo de Blink y la dependencia de Google.
  • Algunos sostienen que las mejoras de Safari son evolutivas más que una aceleración repentina; quizá la conciencia sobre ello es simplemente mayor ahora.

PWAs vs aplicaciones nativas y la dinámica de la App Store

  • Debate sobre si las aplicaciones web desplazarán de forma significativa a las apps nativas:
    • Postura a favor de las PWA: las PWA igualan cada vez más las capacidades nativas (service workers, push, sensores, ubicación), y muchas apps convencionales podrían ser “solo sitios web”.
    • Postura escéptica: el rendimiento, los controles de UI complejos, las animaciones y las APIs que faltan siguen haciendo que las PWA sean inferiores; iOS es donde está el dinero, así que los desarrolladores seguirán creando apps nativas.
  • Preocupaciones de monetización: las PWA dificultan las apps de pago único, empujando hacia suscripciones o anuncios; algunos lamentan la pérdida de herramientas simples, de pago y capaces de funcionar sin conexión.
  • Algunos ven un soporte más sólido para PWA/WebGPU como una cobertura estratégica para Apple en los debates antimonopolio y sobre la regulación de la App Store.

Diseño de WebGPU, influencia de Metal e implementaciones

  • Se señala ampliamente que la API de WebGPU es muy similar al Metal de Apple; algunos lo ven como una influencia deliberada a través de los organismos de estandarización.
  • Hubo soporte temprano, luego eliminado, en Safari para una propuesta anterior al estilo de Apple antes del estándar actual.
  • Desacuerdo sobre la historia del diseño de shaders:
    • Un lado enfatiza la oposición de Apple a SPIR-V/IR binario y su preferencia por lenguajes de texto, influyendo en la adopción de WGSL.
    • Otros señalan preocupaciones más amplias (portabilidad, seguridad, el dolor de compilar shaders) y argumentan que no fue “Apple contra todos los demás”.

Calidad de Safari, errores y cadencia de lanzamientos

  • Experiencias mixtas: algunos dicen que Safari funciona bien y que los sitios suelen fallar por APIs exclusivas de Chrome; otros informan de errores específicos de Safari (especialmente SVG, PWA, wake lock, modo oscuro, renderizado de z-index).
  • Safari está parcialmente desacoplado de las grandes versiones del sistema operativo, con actualizaciones significativas de la plataforma web en versiones menores del SO; aun así, se describe que las PWA en iOS son frágiles y a veces sufren regresiones.

Seguridad, permisos y uso de recursos

  • Algunos temen que WebGPU amplíe la superficie de ataque y socave mitigaciones previas basadas en temporización; otros piden pruebas concretas y lo ven como un riesgo incremental.
  • Propuestas para poner WebGPU detrás de un cuadro de permisos (como cámara/ubicación), principalmente para proteger contra el drenaje de batería y sitios sospechosos; otros señalan que es difícil explicar “acceso a la GPU” de forma clara a los usuarios.

Ecosistema y casos de uso

  • Interés en:
    • Ejecutar LLMs y modelos como Whisper en el navegador con WebGPU.
    • WebGPU como sucesor multiplataforma de OpenGL a través de bibliotecas como Dawn/wgpu, y posiblemente como un framework del sistema en plataformas de Apple.
    • Navegadores mejores basados en WebKit en Linux (se habló de Epiphany/GNOME Web, con lagunas en sandboxing/memoria y WebRTC).
    • Soporte de WebXR, incluso en iPhone y Vision Pro, aunque no está claro su disponibilidad futura en teléfonos.
  • Algunos esperan que WebGPU ayude a trasladar al web apps de escritorio al estilo Electron y juegos; otros no están convencidos de que la web llegue a igualar por completo a lo nativo.