¿Reemplazará Eventualmente HTML5 / JS todos los idiomas del lado del cliente? [cerrado]

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

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

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

Javascript es un lenguaje de programación muy pobre. La traducción de lenguajes de programación tipificados estáticamente, como Java con GWT, es cada vez más común. Javascript puede convertirse en el mismo tipo de lenguaje de unificación que el ensamblador; puedes escribirlo directamente, pero rara vez es una buena idea.

Sí.

He aquí por qué. Las aplicaciones están compuestas de código de interfaz de usuario y datos de back-end. 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 las de un iPhone, pero de código abierto y se pueden escribir en Javascript / HTML5 / CSS. jQTouch ha demostrado que si el navegador otorga a los programadores JS acceso a los eventos de IU del dispositivo, los programadores JS emularán el estilo de IU que esté de moda para la misma plataforma.

Los programadores de Javascript estarán más solicitados 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 el código JS para acceder a los datos de back-end, especialmente con el código AJAX pesado.

Las ganancias de productividad irán todas a los lenguajes interpretados dinámicos. A medida que los procesadores se vuelven cada vez más rápidos, la productividad de codificación del programador, la productividad del administrador del sistema y la productividad del administrador de la aplicación son influencias más fuertes en la productividad general. Simplemente no tiene que preocuparse por la rapidez con la que se realiza el compilador o VM de su lenguaje de programación. Debe preocuparse más ahora por cuánto cuesta aprovisionar y respaldar su aplicación.

La mayoría de las aplicaciones independientes no son tan buenas en mi opinión. Al igual que hay pocas aplicaciones de PC grandes e independientes, y las mejores se están transformando en aplicaciones web. En realidad, es mejor regalar la aplicación de cliente HTML / JS / CSS de forma gratuita y cobrar una tarifa mensual por el acceso a los datos de back-end y la lógica empresarial. Los programadores harán suscripciones de mayor venta que las aplicaciones de un solo disparo.

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 ...

Hay una 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
• fuerza laboral más barata
• La conectividad está integrada
• Más fácil de producir algo que se vea bien
• El texto es accesible para los motores de indexación

Sin embargo, tal vez aparezcan otros idiomas, que se utilizarán como sustitutos para JavaScript. Después de todo, ¡es difícil tener un lenguaje que pueda hacer todo bien, mientras se mantiene un lenguaje de alto nivel! Y JavaScript ha existido por un tiempo y ha acumulado algunas deficiencias.

JavaScript podría terminar siendo el idioma principal para el lado del cliente, pero no creo que pueda ser el idioma solo , ya que, JS es un sistema basado en estándares, diseñado Lenguaje 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 de 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 eso es demasiado lejos, hay muchos desarrolladores de Flash y es una tarea abrumadora cambiar sus habilidades a JavaScript. Lo que eventualmente sucede, la habilidad permanece igual pero la salida se vuelve diferente. En este caso, Adobe presenta una herramienta de conversión HTML5.

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

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

No todos, pero probablemente la mayoría. Tal vez javascript puede llegar a ser lo suficientemente rápido como para reemplazar HashCalc pero no hay una alternativa web a VLC (los navegadores no admiten 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 para acceder' cada vez que hago 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 los saltos de código de los navegadores de bc no son compatibles con el html o necesito una variante / leve modificación de 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.