¿Es HTML5 el sucesor de Java?

Hace ya bastante tiempo, allá por los primeros años noventa, un tal James Gosling, junto a otros ingenieros, crearon una tecnología llamada Java, que estaba principalmente enfocado a la domótica y a electrodomésticos en general. Sin embargo, este lenguaje no tuvo el éxito esperado y dio el salto a los computadores, donde se le vio una característica muy particular. Al ejecutarse los programas sobre una máquina virtual que traducía bytecodes pseudocompilados y no trabajar directamente sobre la máquina, esto le dio la característica de ser multiplataforma, o sea, un programa pseudocompilado en una plataforma valía para todas las demás, solo requiriendo la instalación de la máquina virtual de Java. Este concepto hizo que Java fuese considerado uno de los buenos en la informática durante bastante tiempo.



Sin embargo para Java todo se empezó a torcer tras la compra de Sun por parte de Oracle, ya que esto estancó el desarrollo de Java durante mucho tiempo, aparte que hay que ver la mala imagen que tiene la empresa de Larry Ellison entre los informáticos en general. A partir de ahí la gente empezó a mirar mal a Java y empezaron a sacarle sus defectos. De hecho hace un tiempo en Genbeta Dev el colaborador Juan Quijano se preguntó si Java se estaba convirtiendo en el nuevo COBOL, algo en lo que no es el único.

Tampoco empecemos a demonizar a Java, ya que esta tecnología demostró y sigue demostrando su valía en el entorno de los servidores, donde es muy fuerte, pero en la informática de consumo ha demostrado ser una tecnología con un rendimiento muy pobre y que exige demasiados recursos. Las aplicaciones a nivel de escritorio hechos en Java o que lo usan (como LibreOffice/OpenOffice) tienen fama de ser lentos y con razón, solo hay que ejecutar jDownloader o Wuala para ver como cualquier cosa en Java no hace más que disparar el consumo de recursos, cosa que yo también reconozco a pesar de gustarme Java, pero es que el consumo de recursos es algo que tanto la comunidad de OpenJDK como Oracle deben mejorar en el próximo Java 8 a toda costa.

No todo fue malo para Java desde la compra de Sun por Oracle, ya que Oracle decidió dejar la implementación privativa de Sun y adoptar OpenJDK como implementación base de Java 7 (y futuras versiones), haciendo Java más abierto que nunca y posibilitando a los usuarios de Linux el poder ejecutar sin problemas cualquier programa hecho para Java 7, como por ejemplo la versión oficial de NetBeans, que antes requería la instalación de los DLJ de Sun/Oracle.

En el transcurso de los últimos años a Java, a nivel de lenguaje, le ha salido un competidor, C#, creado por Microsoft para la plataforma .Net. En Internet te puedes encontrar muchos hilos de foros y opiniones en donde comparan ambos lenguajes, pero jamás he hecho mucho caso a este debate, ¿por qué?, porque para mi .Net jamás fue competencia para Java, ya que es una tecnología monoplataforma. La gente ahora me saltará con Mono/Xamarin, pero la verdad es que el invento de Miguel de Icaza no es más que un triste consuelo para programar C# fuera de Microsoft, porque al menos en Mono el implementar una aplicación hecho en Linux sobre Windows de un formulario que lo único que hacía era pasar el texto de un textbox a un label después de pulsar un botón fue un total infierno, con Java todo funciona a la primera. Así que no, C# no es y por lo que se no será rival jamás para Java, este es un debate forzado que no tiene ningún sentido, ya que para mi el fuerte de Java es su condición de multiplataforma, cosa en la que C#/.Net está a años luz, le pese a quien le pese.

Y ojo, que esto no se tome como un ataque a C#, que por lo que poco que he podido tocar me parece un lenguaje muy bueno y muy productivo, hacer aplicaciones con él resulta muy, pero que muy sencillo y todo eso es un gran logro por parte de Microsoft, pero es que la sintaxis del lenguaje no es para mi lo que hace que Java sea Java.

Debido al poco éxito de Java a nivel de escritorio (lo que se ve en los pocas aplicaciones que lo utilizan) la mayoría de los programadores siguen prefiriendo llevar varias versiones con lenguajes nativos antes de usar unos bytecodes que puedan funcionar en cualquier plataforma.

Pese a todo, hace poco ha entrado en juego un nuevo protagonista que pretende copiar la filosofía de Java de programa una vez, ejecuta en cualquier parte, aunque hay que ver si al final lo consigue porque esto solo acaba de empezar, y ese nuevo protagonista no es otro que HTML5 y sus colegas CSS3 y JavaScript. Esta semana estrené un ZTE Open con Firefox OS y aunque el sistema operativo de Mozilla todavía está algo más que verde, la verdad es que me sorprendió la fluidez y la suavidad del sistema.

Durante mucho tiempo no he parado de leer de gente que decía que HTML5 y JavaScript no sirven para hacer aplicaciones, entre ellos el líder de KDE, Aaron Seigo. Aunque todavía es muy pronto para echar las campanas al vuelo, se puede decir que los detractores de HTML5 como lenguaje para interfaces gráficas de usuario (GUI) han perdido el primer round.

No se puede decir ni de lejos que el ZTE Open sea un móvil bueno, todo lo contrario. Pese a todo he podido comprobar que HTML5 puede ofrecer lo que no ha podido Java en toda su historia en la informática de consumo, un rendimiento decente. No digo que HTML5 y JavaScript pueda competir en rendimiento con tecnologías que trabajan a más bajo nivel de la máquina, pero la verdad es que rendimiento este en un más que primitivo Firefox OS ya se patea al Android Froyo que usaba en mi Galaxy Mini I, que la gente ya me dirá que vaya móvil más viejo y lo mismo para Android, pero por lo que se a nivel de características técnicas el ZTE Open es directamente comparable con el Galaxy Mini I, aparte que Android Froyo no era ni por asomo una versión primeriza y oficialmente no estable de Android. Y es que ni Google ha podido demostrar que Java es capaz de ofrecer un buen rendimiento en la informática doméstica a pesar de que Android usa una implementación propia de Java basada en Apache Harmony, una implementación de Java hecha por los mismos de la Apache Foundation.

Y es que después de que el desarrollo multiplataforma se cayera por el pobre rendimiento de Java, la verdad es que por fin volvemos a tener una esperanza con la irrupción de HTML5 en los teléfonos móviles, una idea que empezó teniendo Apple para el iPhone pero que luego desechó debido a que a nivel de rendimiento las cosas no convencían.

Habrá que ver como evoluciona Firefox OS, sin duda la gran punta de lanza de HTML5 lenguaje nativo de un sistema operativo. Ha tenido un arranque prometedor, pero igual le puede pasar que a Gnome-Shell y lo que fue un comienzo prometedor se terminó estancando y derivando hacia algo errático.

Muchas de las cosas que acompañan a HTML5 (como WebGL) y el propio HTML5 están todavía verdes, pero el ver que no es necesario una máquina potente para mover algo fluido con ellos ha sido sin duda algo que me ha emocionado mucho. Yo siempre he sido una gran defensor de las tecnologías multiplataforma, por eso me centré en PHP y un poco en Java, porque pienso que las aplicaciones no deberían depender de la plataforma, pienso que todo el mundo debería poder utilizar una aplicación independientemente que use Windows, Mac o Linux.

Sin embargo, HTML5 va a tener que convencer a un grupo que tradicionalmente ha sido muy inmovilista, el de los programadores, que con el motivo del pobre rendimiento se quedarán anclados en tecnologías que no son multiplataforma con la excusa de siempre, el de que funciona, la misma excusa que usan muchos para seguir programando y usando tecnologías del siglo pasado.

Comentarios

  1. Si el rendimiento de java es tan pobre ¿cómo explicas éstos ejemplos?

    https://blog.twitter.com/2010/twitters-new-search-architecture
    https://en.wikipedia.org/wiki/Apache_Hadoop

    html5+javascript depende totalmente del rendimiento del navegador.

    por cierto este blog funciona gracias a java, al igual que gmail, google docs, etc..

    ResponderEliminar
    Respuestas
    1. A nivel de servidor Java si ha demostrado su valía (cosa que he dicho en el artículo), pero a nivel informática de consumo, usando tu directamente la aplicación, no.

      Parece que tu no has usado muchas aplicaciones en Java, y hablo de aplicaciones para la gente corriente, nada de cosas orientadas a servidores.

      LibreOffice/OpenOffice cada vez mejora su rendimiento porque están quitando partes que están hechas en Java, jDownloader consume una barbaridad, Wuala no tiene que hacer nada revolucionario para comerse más de 300 megas.

      Aparte, y aunque no es la misma implementación, Android está teniendo infinitos problemas de rendimiento.

      Si Java hubiese mostrado un buen rendimiento en la informática de consumo hoy en día casi todo se haría ahí y no tendríamos apenas nada en nativo.

      HTML5+JavaScript depende del motor de renderizado, no del navegador, porque en Firefox OS no usas un navegador web todo el tiempo e igual en Tizen.

      Eliminar
  2. Joder acabo de leer esta entrada y dentro de dos años empiezo a estudiar "Desarrollo de aplicaciones informáticas" y pensaba tirarme a la piscina de Java ahora ya no se...

    ResponderEliminar
    Respuestas
    1. Todavía no he tenido tiempo para hacer algún experimento y ver cómo se programa exactamente una aplicación en HTML5, pero tienes que ver que CSS, JavaScript y HTML5 solo trabajan a nivel de cliente, así que necesitarás otra tecnología como servidor (que es lo que tengo que descubrir con Firefox OS, aunque me temo que mi móvil acaba de morir).

      Yo soy defensor de la multiplataforma, así que me siento "orgulloso" de apostar por Java y la web.

      Java está muy bien y aunque yo lo uso para hacer aplicaciones gráfica multiplataforma, su fuerte está en el servidor, con lo que no tienen por qué chocar.

      Aparte, tienes JSP que es una tecnología para páginas web dinámicas a nivel del servidor y basado en tecnologías Java.

      Yo recomiendo a la gente que se deje ya de programar en nativo, porque la era del Pentium I pasó hace ya mucho tiempo.

      Eliminar
    2. Javascript puede trabajar al nivel servidor con nodejs, tiene cientos de librerías y apoyo de la comunidad, también se usa mucho actualmente como una opción escalable ya que es muy rápido y consume muy pocos recursos. Java también es bueno en muchos aspectos :-)

      Eliminar

Publicar un comentario

Entradas populares