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

13

Me pregunto sobre el futuro de todo esto. 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 iADs de Apple ahora se pueden programar en HTML5. Entonces, ¿eso significa que HTML5 eventualmente reemplazará object-c?

Además, Microsoft ahora ha cambiado su enfoque de WPF / Silverlight a HTML5 y asumo que Visual Studio 2011 será todo sobre el soporte de herramientas para HTML5. Porque eso es lo que hace Microsoft. (Herramientas). En unos pocos meses, IE9, el último navegador principal será compatible con HTML5.

Del mismo modo, Adobe se está subiendo al carro de HTML5 y permite exportar contenido flash a HTML5 en sus últimas herramientas.

Y todos sabemos cuánto hay en la cama Google con html5. Heck, su último sistema operativo (Chrome OS) no es más que un gran navegador web.

Las aplicaciones para dispositivos móviles (es decir, iPhone, Android, WM7) son muy difíciles de programar para una compañía, especialmente para muchos dispositivos diferentes (cada uno con su propio idioma), así 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 cobrarlas.

¿Así que los lenguajes fuertemente tipados están realmente condenados, y en el futuro, digamos entre 5 y 10 años, la programación del lado del cliente solo estará en HTML5? ¿Todos nosotros nos convertiremos en programadores de javascript? :) Porque los letreros están seguros apuntando de esa manera ...

    
pregunta 23.12.2010 - 03:58

7 respuestas

14

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.

    
respondido por el Damovisa 23.12.2010 - 05:08
6

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.

    
respondido por el Don Reba 23.12.2010 - 06:29
1

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

    
respondido por el Jay Godse 23.12.2010 - 04:34
1

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

    
respondido por el Rolf 31.05.2012 - 01:41
0

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.

    
respondido por el Manish 23.12.2010 - 07:29
0

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.

    
respondido por el user2528 23.12.2010 - 08:06
-1

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.

    
respondido por el Aaron Anodide 05.08.2011 - 22:34

Lea otras preguntas en las etiquetas