Portada
mis comunidades
otras secciones
#8:
#2 #3 No van por ahí los tiros.
Las máquinas virtuales de Javascript, como V8 o Chakra están diseñadas para intentar ser lo mas rápidas posibles bajo ciertas condiciones, incluso a costa de esas otras condiciones. Los algoritmos que utilizan a menudo intercambian espacio por tiempo, y a menudo intercambian cantidades fijas de tiempo a cambio de optimizaciones que piensan que tendrán un retorno en tiempo.
En las plataformas embebidas, donde los recursos son muy limitados, esas optimizaciones no son viables por que simplemente no hay suficiente espacio, o el tiempo necesario para llevarlas a cabo es tan grande que hace inviable la experiencia o aplicación. En ese tipo de entornos ha estado trabajado recientemente v8, en un esfuerzo que llaman JIT less.
QuickJS es una implementación espartana y eficiente de una máquina virtual de Javascript. En entornos como tu ordenador personal o tu teléfono inteligente con ARM y 3 gigas de ram, probablemente sea mucho, mucho mas lento que v8.
Además, la complejidad de v8 viene dada también por las funcionalidades de seguridad que QuickJS no tiene, por que es para otro caso de uso.
Si vas a usar una VM de javascript para ejecutar todo tipo de código javascript que viene de terceros no confiables, la seguridad se impone por encima del rendimiento o la eficiencia.
En resumen, que esto es una muy buena noticia para proyectos de hardware embebido donde se quiera hacer javascript por alguna razón, pero no cambia nada el panorama de las máquinas virtuales de javascript para la web.
Las máquinas virtuales de Javascript, como V8 o Chakra están diseñadas para intentar ser lo mas rápidas posibles bajo ciertas condiciones, incluso a costa de esas otras condiciones. Los algoritmos que utilizan a menudo intercambian espacio por tiempo, y a menudo intercambian cantidades fijas de tiempo a cambio de optimizaciones que piensan que tendrán un retorno en tiempo.
En las plataformas embebidas, donde los recursos son muy limitados, esas optimizaciones no son viables por que simplemente no hay suficiente espacio, o el tiempo necesario para llevarlas a cabo es tan grande que hace inviable la experiencia o aplicación. En ese tipo de entornos ha estado trabajado recientemente v8, en un esfuerzo que llaman JIT less.
QuickJS es una implementación espartana y eficiente de una máquina virtual de Javascript. En entornos como tu ordenador personal o tu teléfono inteligente con ARM y 3 gigas de ram, probablemente sea mucho, mucho mas lento que v8.
Además, la complejidad de v8 viene dada también por las funcionalidades de seguridad que QuickJS no tiene, por que es para otro caso de uso.
Si vas a usar una VM de javascript para ejecutar todo tipo de código javascript que viene de terceros no confiables, la seguridad se impone por encima del rendimiento o la eficiencia.
En resumen, que esto es una muy buena noticia para proyectos de hardware embebido donde se quiera hacer javascript por alguna razón, pero no cambia nada el panorama de las máquinas virtuales de javascript para la web.
Comentarios
Mientras se respete el estándard de JavaScript dónde 0,3/0,1=2,99999... Por mi perfecto.
#4 No solo JS. https://0.30000000000000004.com/
#4 #6 IEEE-754 es el origen de todo eso.
#4 Te veo muy verde en esto de la programación
#16: Podría ser peor: la culebra esa donde organizas el código... usando espacios.
#19 Hay que decirlo más esto.
No es por nada pero BigInt se encuentra en Stage 3... y es, ya hoy en dia, soportado por los principalmente navegadores.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt
Supongo que será muy útil en sistemas embebidos, donde su pequeño tamaño y velocidad permitirán ejecutar pequeñas aplica en JavaScript
#5 Tan sólo que se plantee usar JS en entornos embebidos es un claro síntoma de los problemas que tenemos en el mundillo.
Vaya....
OTRA libreria de JS q va a ser el fin de todos los males...
Deprecadas otras 12 librerias.
En serio. Tengo yogures en la necera q tardan mas en caducar q los frameworks de js
#7 No es otra libreria JS, es un motor de JS para sistemas embebidos. No hay otros 12 y tampoco de haberlos serían llamados librerías, generalmente.
No se que tienen que ver los yogures o los frameworks con este envío.
#11 #14 vuestro odio me hace mas grande
#7 .....
#7 ¿Por qué te arriesgas a acabar como un ignorante por no leerte la noticia? Es que solo leyendo la entradilla te das cuenta de que no es una biblioteca (que no librería), si no un motor que interpreta JavaScript, escrito en C, para embeberlo en otras aplicaciones desarrolladas con C o C++ y usar JS como lenguaje de scripting.
Este fue el que montó el follón con los desarrolladores de FFmpeg y de ahí surgió Libav ......
No sé como podéis subir a portada una noticia tan pésimamente redactada, posiblemente con la ayuda de Google Translate.
A tomar por culo Node
#2 Node.js no es un motor de javascript. En todo caso, sería a tomar por culo Google V8 o MS Chakra.
#2 #3 No van por ahí los tiros.
Las máquinas virtuales de Javascript, como V8 o Chakra están diseñadas para intentar ser lo mas rápidas posibles bajo ciertas condiciones, incluso a costa de esas otras condiciones. Los algoritmos que utilizan a menudo intercambian espacio por tiempo, y a menudo intercambian cantidades fijas de tiempo a cambio de optimizaciones que piensan que tendrán un retorno en tiempo.
En las plataformas embebidas, donde los recursos son muy limitados, esas optimizaciones no son viables por que simplemente no hay suficiente espacio, o el tiempo necesario para llevarlas a cabo es tan grande que hace inviable la experiencia o aplicación. En ese tipo de entornos ha estado trabajado recientemente v8, en un esfuerzo que llaman JIT less.
QuickJS es una implementación espartana y eficiente de una máquina virtual de Javascript. En entornos como tu ordenador personal o tu teléfono inteligente con ARM y 3 gigas de ram, probablemente sea mucho, mucho mas lento que v8.
Además, la complejidad de v8 viene dada también por las funcionalidades de seguridad que QuickJS no tiene, por que es para otro caso de uso.
Si vas a usar una VM de javascript para ejecutar todo tipo de código javascript que viene de terceros no confiables, la seguridad se impone por encima del rendimiento o la eficiencia.
En resumen, que esto es una muy buena noticia para proyectos de hardware embebido donde se quiera hacer javascript por alguna razón, pero no cambia nada el panorama de las máquinas virtuales de javascript para la web.
#3 Toda la razón. Patinazo por mi parte