JavaScript lleva años siendo el código estándar utilizados por los navegadores, y aunque algunas de las grandes empresas, siendo conscientes de sus limitaciones, han intentado buscar sus propios sustitutois, la falta de acuerdo entre ellas ha hecho que al final siempre hayan acabado limitándose a mejorar lo que ya existe en vez de a buscar un nuevo camino en común.
Pero esto podría estar a punto de cambiar, porque los ingenieros de gigantes como Google, Apple, Microsoft y Mozilla han decidido unirse para crear WebAssembly, un nuevo formato binario unificado que utilizará el bytecode para conseguir que los navegadores del futuro puedan ser hasta veinte veces más rápidos.
Los usuarios más avanzados llevan mucho tiempo esperando la implementación del bytecode en Internet. Se trata de un código intermedio entre el código fuente y el código máquina que es tratado a menudo como un archivo binario, y que sería ejecutado de una manera mucho más eficiente que el actual JavaScript por los navegadores web.
De esta manera WebAssembly conseguirá que las aplicaciones web y el contenido de todas las páginas compiladas con este formato puedan ser ejecutadas en los navegadores móviles y de sobremesa como si fueran unas aplicaciones nativas que hemos instalado. También ayudará a mejorar la velocidad de las compresiones, animaciones y visualizaciones.
Aun quedan años para que esta nueva tecnología se convierta en un estándar, y de momento ni siquiera se han finalizado ni sus especificaciones ni su diseño. Pero teniendo en cuenta que con WebAssembly las empresas responsables de los principales navegadores web por fin se han puesto de acuerdo para trabajar juntas, el comienzo no podría haber sido más esperanzador.
Vía | The Next Web
Imagen | Dmitry Baranovskiy
Enlace | Github de WebAssembly
En Genbeta | Cómo (no) te protege el modo incógnito de los navegadores
Ver 33 comentarios
33 comentarios
JuanAR
El bytecode lo más seguro que se pueda decompilar fácilmente. Y seguro que los navegadores incluirán visores que lo harán al vuelo. Contad que Mozilla también está metida, y siempre vigila las libertades.
driverop
Un bytecode se puede desensamblar. No vas a obtener exactamente el mismo código fuente que lo originó (olvídate de los identificadores, por ejemplo), pero sí un código crudo.
Yo la verdad, celebro la medida, porque esto abre la puerta a que se pueda programar con otros lenguajes que no sean JavaScript.
cristiánarenas ullo
Para todos los que están pensando en lo que van a perder por no poder leer el código directamente, sepan que esto es una mejora para asm.js, que de por sí ya no es legible.
Aquí hay un ejemplo de asm.js: gist githubusercontent com/jeresig/5293608/raw/bananabread-asm.js (pónganle los puntos que no tengo karma suficiente para poner el enlace bien)
Así que efectivamente, esto sí es un win-win.
pikilon
Ahí va la libertad de ver el código para ver como funciona, con la excusa de que sea más eficiente. En fin
molleradura
Un tema delicado ya que no es un win-win, si comparamos el código fuente visible-legible vs bytecode no-compilado:
- El bytecode ocupa menos. Esto es bueno para el usuario ya que la página carga antes y para páginas de juegos/apps complejas online que tienen mucho código.
- El código visible es más facil de auditar y saber que hace, lo que es interesante en el espacio más inseguro posible: "internet".
- El código visible es una gran ayuda para aprender de otros copiando, personalizando, modificando, etc.
- El código visible es más facil de depurar en distintos navegadores.
- Siempre hay un coste de cambio.
- Lo que más ocupa son las imágenes/videos/etc, no el código. Las webs normales no van a ganar tanto.
ovrang
¡No! ¡Y yo que pensaba aprender Angular!
seitoku
Bueno, respecto a los que tienen miedo de que no se va a poder leer el codigo, tranquilos tanto .net como java se pueden decompilar mas o menos bien (los comentarios y los identificadores de variables desaparecen, pero si lees un minified de cualquier javascript te encontraras con el mismo problema).
Ahora con respecto a la compatibilidad, es verdad, puede que de problemas con versiones antiguas de navegadores (puede que muchos de android, iOS(antiguos) tengan problemas). Pero esto ocurre siempre cuando hay una ruptura.
Para mi, lo unico que significa es la muy posiblemente muerte de Dart. El resto son ventajas (rendimiento y peso de los js).
genitalico
UU tendremos bytecode en los navegadores dios salve a los applets haha..
dejando un lado el sarcamos, se me hace muy interesante la propuesta.. por un lado se ganara rendimiento que es lo que siempre se busca y por otro tal vez permitira desarrollar aplicaciones incluso juegos mas complejos que de una manera tradicional de desarrollo se pueda pero den problemas de rendimiento.
si esto se logra de una manera correcta. podriamos estar ante el fin de las apps para escritorio nativas..y tal vez para las app moviles.
hoy en dia una app en cordova se ejecuta muy bien y parece nativa en android, ahora si se desarrolla con estas nuevas bases probablemente se vea igual pero este al tu por tu en performance que si se hiciera en Java, al fin de cuentas Java se pasa a bycode en dalvik o dart
webmaster3
Todo lo que haga la navegación mas rápida bienvenido sea