¿HTML5 / JS eventualmente reemplazará todos los idiomas del lado del cliente? [cerrado]

Me pregunto sobre el futuro de todo. En mi humilde opinión, hay 4 fuerzas que definen a dónde va la tecnología: Microsoft, Apple, Google, Adobe.

Parece que en el iPhone / iPad de Apple, los iAD ahora se pueden programar en HTML5. Entonces, ¿eso significa que HTML5 eventualmente reemplazará el objetivo-c?

Además, Microsoft ahora ha cambiado su enfoque de WPF / Silverlight a HTML5 y supongo que Visual Studio 2011 tendrá que ver con el soporte de herramientas para HTML5. Porque eso es lo que hace Microsoft. (Herramientas). En unos pocos meses, IE9, el último navegador importante admitirá HTML5.

De manera similar, Adobe se está subiendo al tren de HTML5 y permite exportar contenido flash a HTML5 en sus últimas herramientas.

Y todos sabemos cuánto cuesta Google con html5. Diablos, su último sistema operativo (Chrome OS) no es más que un gran navegador web gordo.

Las aplicaciones para dispositivos móviles (es decir, iPhone, Android, WM7) son muy difíciles de programar para una empresa, especialmente para muchos dispositivos diferentes (cada uno con su propio idioma), por lo que supongo que esto no durará demasiado. Es decir, HTML5 será el lenguaje unificador. Lo cual es algo triste para los desarrolladores de aplicaciones porque ahora los usuarios podrán jugar las aplicaciones html5 "geniales" de forma gratuita en la web y será difícil cobrar por ellas.

Entonces, ¿los lenguajes fuertemente tipados están realmente condenados, y en el futuro, digamos 5-10 años, la programación del lado del cliente solo estará en HTML5? ¿Todos nos convertiremos en programadores de JavaScript? :) Porque las señales están seguras apuntando de esa manera ...

Creo que es erróneo sugerir que HTML5 / JS reemplazará TODOS los lenguajes del lado del cliente. ¿Muchas aplicaciones irán así en los próximos años? Si probablemente. ¿Todos ellos? No.

El otro punto importante a tener en cuenta es que el paisaje cambia constantemente. HTML5 es una gran tecnología que promete resolver muchos de los problemas que los desarrolladores están teniendo actualmente cuando intentan escribir aplicaciones que funcionan multiplataforma. Claro, HTML5 / JS puede resolver muchos de esos problemas, pero el panorama cambiará y surgirá un nuevo conjunto de problemas. HTML5 eventualmente parecerá anticuado.

En 10 años, pregúntese si HTML5 / JS fue la solución a todos los problemas y puedo garantizarle que la respuesta será no. En 20 años, la pregunta en sí misma probablemente parecerá ridícula.

Javascript es un lenguaje de programación muy pobre. La traducción de lenguajes de programación estáticamente tipados, como Java con GWT, se está volviendo cada vez más común. Javascript puede convertirse en el mismo tipo de lenguaje unificador que ensamblador: puede escribir directamente en él, pero rara vez es una buena idea.

Si.

Este es el por qué. Las aplicaciones se componen de código de interfaz de usuario y datos de fondo. El código de la interfaz de usuario se ejecuta en HTML5 / CSS3 / Javascript. El código de fondo puede ser propietario y ejecutarse en cualquier idioma. Además, jQTouch y bibliotecas similares se pueden usar para emular interfaces de usuario similares a iPhone pero de código abierto y escritas en Javascript / HTML5 / CSS. jQTouch ha demostrado que si el navegador da a los programadores de JS acceso a los eventos de IU del dispositivo, los programadores de JS emularán cualquier estilo de UI que esté de moda para la misma plataforma.

Los programadores de Javascript tendrán más demanda que nunca. En una arquitectura modelo-vista-controlador, el modelo y el controlador están en el back-end, pero el código de vista se escribe mejor en el navegador. es decir, HTML5, Javascript, CSS. Y necesita escribir código JS para acceder a los datos de fondo, especialmente con código AJAX pesado.

Las ganancias de productividad se destinarán a los lenguajes dinámicos interpretados. A medida que los procesadores se vuelven cada vez más rápidos, la productividad de la codificación del programador, la productividad del administrador del sistema y la productividad del administrador de la aplicación influyen más en la productividad general. Simplemente ya no tiene que preocuparse por la rapidez con la que la VM o el compilador de su lenguaje de programación funciona. Ahora debe preocuparse más por cuánto cuesta aprovisionar y admitir su aplicación.

La mayoría de las aplicaciones independientes no son tan buenas en mi opinión. Al igual que hay pocas aplicaciones excelentes para PC independientes, y las mejores se están transformando en aplicaciones web. En realidad, es mejor regalar la aplicación cliente HTML / JS / CSS de forma gratuita y cobrar una tarifa mensual por el acceso a los datos de fondo y la lógica empresarial. Los programadores venderán mejor las suscripciones que las aplicaciones únicas.

Por cierto, eche un vistazo a este video sobre cómo escribir una parte de una aplicación web independiente en un navegador Webkit. Es interesante...

Existe la voluntad de reemplazar los lenguajes de codificación de aplicaciones como C ++, Java ... con HTML / Javascript. Hay muchas razones detrás de eso, algunas de ellas:

• Desarrollo más rápido
• Mano de obra más barata
• La conectividad está integrada
• Es más fácil producir algo que se vea bien
• El texto es accesible para los motores de indexación

Sin embargo, quizás aparezcan otros idiomas para ser utilizados como reemplazos directos para JavaScript. Después de todo, ¡es difícil tener un idioma que pueda hacer todo bien, mientras se mantiene un idioma de alto nivel! Y JavaScript ha existido por un tiempo y acumuló algunas deficiencias.

Es muy posible que JavaScript termine siendo el idioma principal para el lado del cliente, pero no creo que pueda ni deba ser el único idioma, porque, siendo JS un lenguaje basado en estándares, diseñado por comité, esto simplemente matará la innovación a ese nivel (lenguajes de programación).

También depende de la habilidad de la mayoría de los desarrolladores y las herramientas que utilizan. Los gigantes tecnológicos que mencionas pueden impulsar una tecnología basada en las herramientas que proporcionan. Por ejemplo, la gente dice que HTML5 es Flash Killer, pero creo que está demasiado lejos, hay muchos desarrolladores de Flash y es una tarea desalentadora cambiar sus habilidades a JavaScript. Lo que finalmente sucede es que la habilidad sigue siendo la misma pero la salida se vuelve diferente En este caso, Adobe sale con la herramienta de conversión HTML5.

Además, debe pensar en el rendimiento de las aplicaciones cliente. Donde sea necesario, se utilizará una herramienta específica de la plataforma. Toma juegos y aplicaciones de iOS, por ejemplo. Sé que WebGL está saliendo bien, pero creo que la gente todavía usa C para crear juegos. O crearán un lenguaje de juego que cree juegos de alto rendimiento. Apple inicialmente solo quería aplicaciones web, pero cuando los desarrolladores vieron las maravillas de Cocoa, se lanzaron sobre él para crear aplicaciones con clase.

Para resumir, siempre habrá nuevas herramientas / lenguaje / tecnologías que siempre serán más geniales que las actuales.

No todos, pero probablemente la mayoría. Tal vez JavaScript pueda ser lo suficientemente rápido como para reemplazar HashCalc, pero no hay una alternativa web a VLC (los navegadores no admitirán todos esos códecs). Dudo que los navegadores web me permitan acceder a cualquier archivo que desee o almacenar una lista de archivos recientes (sin un 'está bien acceder' cada vez que haga clic en el archivo reciente) y no me gusta la idea de distribuir aplicaciones que son 99% navegadores web (varios mb) con mis 100kb de código cuando se trata de casos en los que el código se rompe porque los navegadores bc no son compatibles con el html o necesito una variante / ligera modificación del webkit.

-editar- también me gustan los lenguajes estáticos en lugar de los dinámicos, pero supongo que puedo usar un buen lenguaje con LLVM que debería ser compatible con el navegador.

Creo que seguiremos en esa dirección hasta que el navegador se convierta en el sistema operativo y luego todo comenzará a reciclarse en el mismo orden, pero con las lecciones aprendidas y las mejoras.