No creo que nadie tenga una respuesta difícil para esta pregunta, pero he visto algunas advertencias interesantes:
El argumento principal PARA html / javascript / css es la portabilidad: el antiguo “escribe una vez, despliega en cualquier lugar” moto. HTML (aquí visto como la trinidad, junto con js / css) trató de llenar ese vacío, al menos en la interfaz. Al igual que Java, una sola página HTML proporcionará las instrucciones que una aplicación escrita de forma nativa (el navegador) traducirá al lenguaje específico de la máquina / SO real.
Eso está muy bien hasta que comienzas a ver algunos navegadores muy diferentes, escritos para sistemas con capacidades muy diferentes, como los teléfonos móviles. Es posible que puedas instalar complementos en tu escritorio de Chrome, pero no tanto en el “mismo” navegador (chrome), sino en tu Android.
Teniendo esto en cuenta, los desarrolladores web (y las grandes empresas) se dividen en dos “equipos”: permiten una página portátil de talla única para todos los entornos o usan complementos.
El equipo de plugin puede requerir que el usuario instale (y habilite el uso de) un paquete, que puede ser engorroso / no disponible, y que aún tenga que escribir código que sea compatible con la plataforma y que pueda o no usar completamente la potencia del hardware (aceleración 3D , acceso a la cámara, etc).
Por otro lado, el equipo de HTML limpio no solo no tiene acceso a muchas características de SO / hardware (a favor de la portabilidad), sino que también está escribiendo más de una aplicación: una para el escritorio y otra para móviles (a veces más de una vez) , ya que el uso de tabletas puede ser diferente del uso de teléfonos inteligentes).
Pero eso no es todo: los navegadores admiten diferentes especificaciones HTML (IE, te estoy mirando), el usuario puede o no tener js habilitado, y los usuarios de iOS tienen diferentes requisitos de interfaz como sus contrapartes de Android (comenzando sin el botón “atrás”) en dispositivos iOS), y ambos son diferentes a un escritorio.
Los complementos pueden proporcionarnos capacidades de aplicación nativas porque, de muchas maneras, eso es lo que son. ¿Es eso algo malo? Cuando intento abrir alguna página web o seguir un enlace en mi navegador móvil, a veces lo que se abre es una aplicación que descargué, no la página HTML, y mi experiencia se enriquece con eso.
Ningún complemento, en mi opinión, equivale a una interacción y capacidades limitadas. Claro que podemos agregar cámara, 3D (como en webgl), toque o lo que sea a HTML, pero ¿por qué no usar (o, al menos, permitir el uso) de las herramientas nativas que el sistema ya nos brinda?
En mi humilde opinión, los complementos no han ido lo suficientemente lejos. Muchos simplemente se implementan porque el desarrollador quiere proteger su código fuente (y con razón, dado que js solo puede ser codificado, pero no fácil de proteger), o porque tienen más confianza al escribir en otro idioma. Deberíamos poder jugar nuestro juego o aplicación favorita lo más cerca posible del nativo, DIRECTAMENTE desde el navegador. Si eso significa que tenemos que modificar o reescribir grandes partes de nuestro código para adaptarnos a diferentes plataformas, supongo que deberíamos poder tener al menos esa opción, como ocurre en el mundo móvil.
Creo que en la próxima década o dos vamos a experimentar nuevas interfaces que pueden ser completamente originales en comparación con un navegador tradicional. Nos sentimos tan cómodos con nuestras páginas HTML que olvidamos que a un usuario NO se le debe exigir que sepa qué es una URL, y solo nos centramos en la experiencia de obtener la información que desea.
¿Eso desencadenará la “caída” de HTML? No lo sé. Pero tengo esperanzas.