¿HTML5 solo reemplaza los aspectos de video de Flash/Silverlight?
flex (8)
Creo que JS ya ha matado a Flash / SL / JavaFX. JS es el idioma más utilizado en la web, así que solo agregue algunas características, mejore algunas cositas y listo. Flash está vivo debido a los videos y juegos, ningún sitio web serio usa Flash ni ningún otro RIA. Solo espera, va a ser un infierno en los próximos años.
Veo mucho hablar de cómo la etiqueta de video HTML5 matará a Flash. Pero aunque el video es la parte más utilizada de Flash / SL, es solo una pequeña parte de sus habilidades técnicas. Por ejemplo, puede escribir un juego utilizando gráficos 3D completos y conexiones de socket en Flex, y aplicaciones comerciales serias, etc.
¿Es el pensamiento de que Javascript matará esas partes de Flash / Flex / SL? Porque si bien parece factible ahora incluso para aplicaciones web bastante ricas, ¿qué pasa con cualquier tipo de aplicación de alto rendimiento, como gráficos en tiempo real?
Hay muchas aplicaciones de alto rendimiento con transmisión de datos en tiempo real y gráficos en producción en la actualidad que se han creado con Flex. Puede ver algunos ejemplos de estos en el escaparate de flex.org . Como siempre, decidir sobre una tecnología se reduce a lo que se está construyendo, para quién se está construyendo y quién lo está construyendo. Flash, Flex, Silverlight, HTML5, etc., todos coexistirán.
Las discusiones de las que he sido parte en este tema, casi siempre parecen llegar a la conclusión de que, aunque el estándar HTML 5 será una gran cosa, una vez que esté en su lugar. Por definición, será un estándar, los estándares tardan mucho tiempo en cambiar, por lo tanto, la innovación estará impulsada en gran medida por complementos como Flash y SL.
Y sí, puede hacer mucho de lo que Flash y SL pueden hacer con Javascript, sin embargo, Flash / Flex tiene el punto fuerte de ser utilizado para aplicaciones Air instaladas en el escritorio, y Silverlight tiene algo similar con su funcionalidad "Out Of Browser". Estas son cosas en las que claramente tienen ventaja sobre Javascript.
A fin de cuentas, no se trata de quién matará a quién, sino de qué herramienta es la adecuada para el trabajo y qué habilidades tiene usted o su equipo de desarrollo.
Ese es mi 2c de todos modos ...
Puedes hacer cosas geniales con HTML5, Canvas y similares. Eche un vistazo a la http://www.chromeexperiments.com/ alojada por Google (que, en realidad , debería llamarse experimentos HTML5, ya que la mayoría funciona bien en los navegadores HTML5). Puede hacerse una idea de lo que es posible, incluida la representación 3D, juegos complejos y algunas animaciones bastante sorprendentes.
Para "aplicaciones de alto rendimiento como gráficos en tiempo real", consulte WebGL. Mozilla y WebKit ya tienen soporte experimental para WebGL, que se basa en el elemento <canvas> .
Para los sockets, existen WebSockets, que también son experimentales en algunos navegadores.
Para el procesamiento en segundo plano, que puede mejorar la experiencia del usuario, hay trabajadores web (experimentales de nuevo).
Un montón de cosas experimentales, pero las están mejorando constantemente, por lo que en algún momento, incluso sin un estándar HTML5 que las defina, podríamos ver juegos específicamente dirigidos a un determinado navegador (en realidad, hay alguna prueba de concepto, pero no puedo encuentra el enlace ahora mismo).
¿Flex reemplazó los formularios HTML? ¿Han matado a los formularios HTML Flex? ¿C ++ ha reemplazado a C? ¿Ruby, Lua o Python han matado a Haskell o Scheme o ensamblado?
En serio, ¿cuál es la obsesión últimamente sobre si HTML5 matará los complementos? ¿Es tan difícil imaginar a las personas que usan Flash para el contenido que debe destacarse y maximizar la expresividad, y el uso de HTML5 para el contenido que necesita utilizar metáforas estándar y maximizar la accesibilidad?
En otras palabras, no, el pensamiento entre las personas que piensan no es que la pila HTML5 mate a Flash / Flex / SL. Si las cosas funcionan como deberían, los complementos seguirán innovando en lo que se puede hacer con técnicas exclusivas, y HTML seguirá tomando las innovaciones más exitosas y estandarizándolas. Y si las cosas no funcionan bien, si un complemento no innova o una versión nueva de HTML se hace mal, se desvanecerá en la oscuridad a medida que los desarrolladores se apeguen a lo que resuelva sus problemas.
Creo que depende de las herramientas de autoría y de la eficiencia de los navegadores. Se informa que el próximo Flash CS5 exportará contenido directamente como un lienzo de HTML5. Entonces, el lienzo puede ser una sustitución instantánea bastante razonable.
Básicamente, esta pregunta ya ha existido.
La respuesta en resumen: no, HTML5 no reemplazará nada. Sin embargo, HTML5 ofrecerá un estándar para las funciones que actualmente solo están disponibles a través de complementos. Una vez que se publique HTML5, que está programado para 2022, será una gran cosa . Aún así, incluso para entonces, si IE sobrevive, dudo que su soporte sea sobresaliente.
Hubo una pregunta muy similar a la que proporcioné una respuesta bastante larga pero detallada: ¿ deberían los desarrolladores web aprender flash?
Mi opinión personal sobre cualquiera que piense que HTML5 reemplazará los complementos de terceros es que carecen de una comprensión básica del rol de HTML5 o de un conocimiento suficiente sobre cualquier complemento y tienen poca o ninguna comprensión sobre cómo evoluciona la web.
Sí, el día en que HTML5 se propague lo suficiente como para que las grandes empresas puedan confiar en él, muchos de ellos podrán reemplazar los complementos de terceros dentro de sus aplicaciones web. Sin embargo, como señalé en mi otra publicación, la web está en constante evolución. HTML5 no proporciona nuevas características, que no estaban disponibles mediante complementos. Y HTML5 no proporciona todas las características disponibles actualmente mediante el uso de complementos. Aparecerán nuevos tipos de aplicaciones, servicios y mecanismos de distribución de contenido. Además, siempre que JavaScript se mantenga totalmente dinámico, los tiempos de ejecución de JS nunca podrán proporcionar la misma velocidad que los tiempos de ejecución diseñados para ejecutarse mediante códigos de bytes generados a partir de lenguajes tipados estáticamente.
Personalmente, para el lado del cliente, básicamente solo me refiero a Flash Player, porque para mí es la plataforma más conveniente. No tengo miedo de que HTML5 mate el flash, por una simple razón:
Hasta que HTML5 sea realmente utilizable y cuente con el respaldo de una suficiente adaptación del usuario, llevará varios años. Al mismo tiempo, todos los complementos principales seguirán evolucionando, así como su ecosistema, incluidas las herramientas de desarrollo, los compiladores cruzados y las capas de compatibilidad.
Hoy en día, ya no necesita conocimiento de HTML, CSS y, a veces, incluso JavaScript para crear aplicaciones web, usando GWT, qooxdoo u otras herramientas.
HTML + CSS + JS no es más que una plataforma a la que pueden acceder cada vez más idiomas. Usando cantidades razonables de abstracción, uno tarde o temprano podrá desarrollar aplicaciones de una manera completamente independiente de la plataforma, causando prácticamente ningún costo adicional para la mayor parte de todas las aplicaciones: GUI (incluida la localización, validación, etc.) y lógica de la aplicación.
Al final, no hay razón para emocionarse. Actualmente, tanto Flash como Silverlight superan las implementaciones de HTML + JavaScript en cuanto a velocidad y características expuestas a través de la API disponible. Es decir, por qué la gente lo usa. Aunque poco probable, algún día pueden quedar obsoletos. En este brillante y brillante futuro, muy, muy lejano, estaré encantado de compilar mis fuentes para ejecutar en un intérprete de JavaScript en lugar de en AVM2.
En una nota vagamente relacionada: echa un vistazo a haXe .