Por qué el fracaso de Firefox OS y Tizen ha sido un gran fracaso para el sector de la programación

Discutiendo en MuyLinux se terminó mencionado el potencial de las webapps como forma de poder crear aplicaciones totalmente multiplataforma, y recordé dos sistemas operativos, Tizen y Firefox OS, cuyos fracasos comerciales han sido en mi opinión todo un fracaso en el sector de la programación.


Yo siempre he tenido una visión muy particular y bastante rebelde en lo que se refiere al rumbo que tendría que seguir el sector de la programación, ya que siempre he sido un férreo defensor de las tecnologías multiplataforma frente a las “nativas”, entre comillas, porque hago referencia a la tecnología propia de cada plataforma y no a una compilación a nivel binario.

Tristemente, buena parte del sector de la programación sigue trabajando con paradigmas más bien propios del Siglo XX. “En nativo rinde mejor”, dicen muchos programadores y desarrolladores hoy en día, una visión que les obliga a tener que rehacer una aplicación desde cero por cada sistema.

Lo de desarrollar con la tecnología propia de la plataforma se podría llevar en caso de programarse para uno o dos sistemas, pero hace tiempo que Windows ya no acapara el noventa y tantos por ciento de la informática doméstica. Sistemas operativos como OS X/macOS, GNU/Linux (sobre todo a través de Ubuntu), iOS y sobre todo Android se han encargado de abrir mucho el mercado de los sistemas operativos. Ante esta situación, lo mejor es abarcarlos todos con el menor gasto de recursos posible.

Aquí entra en juego las tecnologías multiplataforma, pudiéndose mencionar las webapps con HTML5, CSS3 y JavaScript, pero también podemos mencionar Qt, que prácticamente abarca todos los sistemas operativos del mercado, Python, GTK y otros muchos más que abren la puerta a poder crear una aplicación para que pueda ser implementada fácilmente entre distintos sistemas. Sin embargo, el sector de la programación seguirá con Objetive-C/Swift para Mac e iOS, GTK para GNU/Linux y .NET para Windows, forzando a tener que reescribir la aplicación desde cero en cada plataforma porque el código no es reutilizable. Esto dispara los gastos y hace que al final haya sistemas operativos sacrificados, empezando aquí casi siempre por GNU/Linux. El fracaso de Firefox OS y Tizen ha cerrado la puerta a que las webapps y un desarrollo más multiplataforma se pudiese extender.

Java, el origen de todo

La cuestión es: ¿A qué se debe este aparente rechazo de la comunidad programadora hacia las tecnologías multiplataforma? El origen de todo tiene un nombre muy concreto, Java.

La tecnología propiedad actualmente de Oracle ha mostrado su valía en el campo de los servidores, pero no en el escritorio, donde siempre ha tenido (y sigue teniendo) fama de ofrecer un rendimiento muy pobre, algo que es muy cierto. Java podría considerarse como la primera tecnología multiplataforma mediática (no digo que sea la primera, ni en existencia ni en ser relevante), y el hecho de que siempre haya mostrado un rendimiento pobre en el escritorio ha terminado haciendo creer a los programadores que toda tecnología multiplataforma tiene un pésimo rendimiento, cuando eso está lejos de la realidad. De hecho muchos salen corriendo cuando descubren que una tecnología es pseudocompilada (compila bytecodes en vez de en binario), creyendo que eso ofrecerá un pésimo rendimiento.

Lo gracioso es que muchos no saben que .NET, el potente framework de Microsoft, también trabaja con bytecodes. Vulkan también hace uso de bytecodes para los shaders, y por lo que se puede apreciar en este vídeo, no se puede decir que la API gráfica no ofrezca un gran rendimiento, sino que más bien parece sacar de donde no hay.

Conclusión

En resumidas cuentas, la falta de apoyo a las tecnologías multiplataforma viene sobre todo por los prejuicios de buena parte parte de la comunidad programadora, sin embargo, en los últimos tiempos se está viendo un cambio de tendencia, ya que cada vez se ven más desarrollos realizados con tecnologías multiplataforma.

El modelo de “un sistema, una tecnología” está cediendo terreno ante nuevas posibilidades que ayudan a llevar la mayor cantidad de aplicaciones a la mayor cantidad de sistemas, aunque el cambio se está produciendo más porque los programadores se están viendo forzados que por convicción.

Comentarios

  1. Las compañías apostarían por webapps si realmente les compensase. Lo cierto es que el rendimiento es pésimo y mira que me gusta la idea pero muchas apps sencillas se arrastraban en Android. Parece que se han dado cuenta y ahora están trabajando en WebAssembly. Lo cierto es que la propia Mozilla ha dicho que las webapps siempre serán como mínimo 10 veces más lentas que código nativo.

    Otro problema que tiene es la compatiblidad y disponibilidad de APIs.

    Y otro problema tiene que ver con la usabilidad, no directamente con la programación, sino con las directrices de estilo de cada plataforma (https://en.wikipedia.org/wiki/Human_interface_guidelines).

    Luego dices que .NET y Vulkan tienen bytecode pero no se pueden comparar con Java. El bytecode de .NET de hecho puede funcionar solo en algunas plataformas así que en ese modo (que es el por defecto) cuenta con una optimización mayor. El bytecode de Vulkan se ejecuta en la GPU, es otro mundo aparte.

    ResponderEliminar
    Respuestas
    1. ¿Y cuando tendrán los ordenadores potencia suficiente para ejecutar webapps con un buen rendimiento? A día de hoy creo que todo dispositivo de gama media y alta (en incluso baja en PC) puede ejecutar webapps sin grandes problemas. Cierto, el rendimiento nunca será igual que en nativo, pero, ¿qué experiencia da al usuario? Skype por ejemplo dará el salto a una webapp en Chrome OS y GNU/Linux. ¿Es algo tan crítico el consumo de recursos hoy en día? Yo diría que no, salvo que se te vaya totalmente de las manos.

      Yo he sido usuario de FirefoxOS y tengo que decir que su rendimiento era aceptable sobre un dispositivo como el ZTE Open, cuyas características eran de muy gama baja incluso para su época.

      En este artículo trato las webapps, aunque ante esto hay alternativas, como Qt, el cual sí se compila a nivel binario, y Mono, que también es pseudocompilado.

      Las webapps, al menos por ahora, no sirven para todos los contextos, cierto, pero cada vez tenemos más opciones que funcionan con tecnologías web, incluyendo suites ofimáticas enteras.

      Lo de Vulkan y .NET lo menciono porque hay muchos que cuando escuchan la palabra "bytecode" salen corriendo, ya que lo primero que se les pasa por la cabeza es Java y ya se imaginan que el rendimiento es malo. No es una demostración técnica (igual que todo este blog salvo excepciones), sino una crítica contra los prejuicios de algunos.

      Sobre WebAssembly, será lo que hará que por fin la web pueda hacer funcionar aplicaciones complejas sin un gran consumo de CPU, que es para mi el gran inconveniente que tiene la web por culpa de JavaScript, y corrígeme si me equivoco aquí.

      Eliminar

Publicar un comentario

Entradas populares