You are here

Mozilla Hispano

Tablas de importación de WebAssembly … ¿Qué son?

Noticias de Mozilla Hispano - 2 horas 20 mins ago

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

En un artículo anterior, te introducimos a las cuatro formas de importación que puede poseer una instancia de WebAssembly:

  • Valores (values)
  • Funciones de cierre (function imports)
  • Memoria (memory)
  • Tablas (tables)

La última probablemente era un poco desconocida. ¿Qué es una tabla de importación y para qué se usa?

A veces en un programa te gustaría tener una variable que apunta a una función, por ejemplo para que se ejecute luego de una acción, como los callbacks. Entonces puedes así pasarla a otra función.

En C, esto se llama punteros de funciones. La función reside en memoria. La variable, el puntero a la función, solo apunta a esa dirección de memoria.

Y si lo necesitas, puedes apuntar a la variable a otra función. Este concepto debería ser familiar.

En las páginas web, todas las funciones son solo objetos de JavaScript. Y por ello, residen en direcciones de memoria que están fuera de la memoria de WebAssembly.

Si quieres tener una variable que apunte a una de estas funciones, necesitamos tomar su dirección y ponerla en nuestra memoria.

Pero parte de mantener las páginas web seguras es asegurarse de esconder esas direcciones. No quieres que el código de la página tenga posibilidad de ver o manipular las direcciones de memoria. Si hay código malicioso, se puede usar para conocer cosas que estén en memoria y crearía una vulnerabilidad.

Por ejemplo, se podría cambiar la dirección que tienes de una función y apuntarla a otro lugar. Entonces cuando intentes llamar a esa función, en vez de cargarla ejecutaría la dirección que tu atacante te modificó.

Esto podría permitir que código malicioso se inserte en memoria, tal vez dentro de una cadena de texto. Las tablas hacen posible tener punteros de función, pero de una forma que no sean vulnerables a este tipo de ataques.

Una tabla es un arreglo que vive fuera de la memoria de WebAssembly, donde los valores son referencias a funciones.

Internamente, estas referencias contienen direcciones de memoria, pero como no están dentro de la memoria de WebAssembly, WebAssembly no puede ver esas direcciones. Solo tiene acceso a los índices del arreglo.

Si el módulo de WebAssembly desea llamar a una de estas funciones, pasa el índice a una operación llamada call_indirect. Ésta llamará a la función.

Actualmente el uso para las tablas es un poco limitado. Fueron añadidas a la especificación para soportar los punteros de funciones, porque normalmente C y C++ suelen usar este tipo de cosas. Por ello, los únicos tipos de referencias que puedes colocar en una tabla son referencias a funciones. Pero conforme las posibilidades de WebAssembly se expandan, por ejemplo, cuando se añada el acceso directo al DOM, podrás ver otro tipo de referencias almacenadas en las tablas y otras operaciones en las tablas, adicionalmente a call_indirect.

Categorías: Mozilla Hispano

Ve más allá de console.log con el depurador de Firefox

Noticias de Mozilla Hispano - Sáb, 10/02/2018 - 18:04

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Sergio Carlavilla Delgado.

console.log no es un depurador. Es genial para averiguar qué está haciendo tu aplicación JavaScript, pero se limita a escupir una cantidad mínima de información. Si tu código es complejo, necesitarás un depurador adecuado. Es por eso que hemos agregado una nueva sección a el Firefox DevTools Playground, que trata sobre la depuración. Hemos creado cuatro lecciones básicas que usan el depurador de Firefox para examinar y arreglar una aplicación de tareas (to-do) en JavaScript.

Presentamos el Debugger Playground

Las lecciones son completamente gratuitas y el código de la aplicación de tareas está disponible para descargar desde GitHub.

Estas lecciones son un nuevo formato para nosotros y estamos muy emocionados de brindártelas. Siempre estamos buscando nuevas formas para ayudar a los desarrolladores a aprender cosas y mejorar el flujo de trabajo diario. Si tienes una idea, avísanos. Ampliaremos el Playground en los próximos meses y estamos encantados en escuchar de desarrolladores como tú.

Si no estas familiarizado con el depurador de Firefox, echa un vistazo a los documentos de depuración en MDN y mira este corto de introducción:

Ahora echemos un vistazo a una lección del nuevo Debugger Playground. ¿Alguna vez usaste console.log para saber el valor de una variable? Hay una manera más fácil y más precisa de hacerlo con el depurador.

Usa el depurador para saber el valor de una variable

Es mucho más fácil encontrar una variable con el depurador de Firefox que con console.log. Así es cómo funciona:

Echemos un vistazo a una aplicación sencilla de tareas. Abre la aplicación de tareas en una nueva pestaña.

Esta aplicación tiene una función llamada addTodo que tomará el valor del formulario de entrada, creará un objeto y luego lo insertará en un array de tareas. Probémoslo agregando una nueva tarea. Esperarás tener esta nueva tarea agregada a la lista, pero en su lugar verás “[object HTMLInputElement]”.

Algo está roto, y tenemos que depurar el código. La tentación es comenzar a agregar console.log por toda la función, para identificar dónde está el problema. El enfoque podría ser algo como esto:

const addTodo = e => { e.preventDefault(); const title = document.querySelector(".todo__input"); console.log('title is: ', title); const todo = { title }; console.log('todo is: ', todo'); items.push(todo); saveList(); console.log(‘The updated to-do list is: ‘, items); document.querySelector(".todo__add").reset(); };

Esto puede funcionar, pero es engorroso e incómodo. También debemos recordar eliminar estas líneas después de corregir el código. Hay una forma mucho mejor de hacerlo con el depurador utilizando lo que se llama un punto de interrupción…

Aprende más en el Debugger Playground

El Debugger Playground cubre los aspectos básicos del uso del depurador de Firefox, examinar la pila de llamadas, establecer puntos de interrupción condicionales y más. Sabemos que hay una curva de aprendizaje abrupta para usar el depurador (y para depurar JavaScript), por lo que hemos creado una aplicación de tareas fácil de entender y decodificar. También es útil ejecutarlo en tu navegador web para mantener las cosas en orden durante tu día de trabajo. La aplicación está disponible aquí para descargar en GitHub. Tómalo y luego dirígete a el Playground para ver las lecciones.

Haznos saber qué te gustaría ver a continuación. Estamos trabajando en nuevas lecciones sobre las últimas tecnologías web y nos gustaría saber de ti. Publica en los comentarios que hay a continuación.

Categorías: Mozilla Hispano

Creando un módulo de WebAssembly con JavaScript

Noticias de Mozilla Hispano - Sáb, 20/01/2018 - 11:45

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

WebAssembly es una nueva forma de ejecutar código en la web. Con ello, puedes escribir módulos en lenguajes como C o C++ y ejecutarlos desde el navegador.

Actualmente los módulos no pueden ejecutarse por si mismos. Esto va a cambiar apenas llegue a los navegadores el soporte a módulos ES. Una vez que ocurra, los módulos de WebAssembly serán cargados tal como cualquier módulo de ES usando <script type="module">.

Pero por ahora, necesitas usar JavaScript para iniciar el módulo de WebAssembly. Esto crea una instancia del módulo. Entonces tu código JavaScript puede llamar a funciones de la instancia del módulo WebAssembly.

Por ejemplo, miremos como React iniciaría un módulo de WebAssembly. (Puedes aprender más sobre ello en este artículo en inglés sobre cómo React puede usar WebAssembly.)

Cuando el usuario carga la página, esta iniciaría de la misma forma.

El navegador descargará todos los archivos JS. Adicionalmente, un archivo .wasm se descargará. Esto contendrá el código WebAssembly que será binario.

Necesitaremos cargar el código en estos archivos para ejecutarlo. Primero se usa el archivo .js que cargará la parte de JavaScript de React. Luego este código instanciará un módulo de WebAssembly… el reconciliador.

Para hacerlo, se llama a WebAssembly.instantiate.


Ahora veamos más de cerca. Lo primero que le pasamos a WebAssembly.instantiate será el código binario contenido en un archivo .wasm. Ese es el código del  módulo. Así que extraemos el binario a un buffer y lo pasamos dentro de él:

El motor empezará a compilar el código del módulo al código que la máquina entiende.

Pero no queremos que esto suceda en el hilo principal. En artículos anteriores se ha hecho la comparación de que el hilo principal es como un desarrollador full stack, porque maneja JavaScript, el DOM y la apariencia. No queremos que bloquee el hilo principal de ejecución cuando se compile el módulo, por eso es que WebAssembly.instantiate retorna una promesa (promise).

Esto permite al hilo principal trabajar en otras cosas y una vez que el compilador finalice la compilación del módulo, será notificado a través de la promesa. La promesa dará la instancia.

Pero el módulo compilado no es la única cosa que se necesita para crear la instancia. Yo veo el módulo como un libro de instrucciones.

La instancia es como una persona que está intentando hacer algo con el libro de instrucciones, pero para ello necesita materiales, cosas con las cuales trabajar.

Aquí es donde el segundo parámetro de WebAssembly.instantiate toma sentido. Es el objeto a importar:


Imagina los objetos importados como una caja de ingredientes o piezas. La instancia usa estos materiales para construir cosas, siguiendo el conjunto de instrucciones. Al igual que un manual requiere un conjunto de materiales, cada módulo espera un conjunto de importaciones

Así que cuando instancias un módulo, le pasas un objeto importado que tiene todas las dependencias. Cada objeto puede tener uno de los siguiente 4 tipos de importación:

  • Valores
  • Funciones de cierre (function closures)
  • Memoria
  • Tablas
Valores

Puede tener valores, los cuales básicamente son variables globales. Los únicos tipos que WASM soporta por los momentos son enteros y flotantes, así que los valores tienen que ser de uno de esos dos tipos. Esto cambiará a medida que se agreguen más tipos a las especificaciones de WebAssembly.

Funciones de cierre

También puede tener funciones de cierre. Esto significa que puedes pasar funciones de JavaScript las cuales pueden ser llamadas desde WebAssembly.

Esto es particularmente muy útil porque en la versión actual de WebAssembly no puedes llamar directamente a métodos del DOM. El acceso directo al DOM está planificado pero por ahora no es parte de la especificación.

Lo que puedes hacer mientras tanto es pasar una función de JavaScript que interactúe con el DOM de la forma que desees. Entonces WebAssembly solo llamará la función de JS.

Memoria

Otra tipo de importación es el objeto de memoria. Este objeto permite a WebAssembly emular la gestión de memoria. El concepto del objeto de memoria suele confundir a las personas, por eso te recomendamos leer este artículo para comprenderlo.

Tablas

El tipo final de importación también está relacionado con la seguridad. Se llama tabla. Es posible para ti usar algo llamado funciones de puntero, lo cual se explicará mas adelante.

Estas son las diferentes formas de importación que puedes utilizar en tu instancia.

Para retornar la instancia, la promesa retornada desde WebAssembly.instantiate se resuelve. Ésta contiene dos cosas: la instancia y el módulo compilado por separado.

Lo bueno es que teniendo compilado el módulo puedes generar rápidamente otras instancias del mismo módulo. Solo debes pasar el módulo en el parámetro source. El módulo como tal no tiene ningún estado. Esto significa que la instancias pueden compartir el código del módulo compilado.

Tu instancia ahora esta equipada y lista para ejecutarse. Tiene un manual de instrucciones que es el código compilado, y eso es todo sobre las importaciones. Puedes ahora llamar a sus respectivos métodos.

Categorías: Mozilla Hispano

Nuevo en Firefox 58: Developer Edition

Noticias de Mozilla Hispano - Lun, 15/01/2018 - 01:35

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Sergio Carlavilla Delgado.

Firefox Quantum ha vuelvo a hacer rápido a Firefox, pero la velocidad es solo una parte de la historia. Se ha trabajado muchísimo para que Firefox sea una herramienta excepcional para crear en la Web. Sumérgete en los cambios que vienen en Firefox 58, actualmente disponibles para una vista previa en Firefox Developer Edition.

Más control para los autores de CSS

Tras el éxito del poderoso CSS Grid Inspector de Firefox, nos complace presentar Shape Path Editor para los elementos con la propiedad clip-path.

Pruébalo tú mismo con este CodePen de Chris Coyier.

También implementamos la propiedad CSS font-display, permitiendo a los autores especificar cuanto tiempo debe esperar el navegador para obtener una fuente, y cuando debería considerar el intercambio de una fuente una vez esté cargada.

Firefox Quantum también introdujo un nuevo motor de CSS (“Quantum CSS”) que solucionó numerosos errores e inconsistencias con CSS en Firefox. Por ejemplo, calc() ahora funciona en todas las partes que la especificación dice que debería.

Un depurador aún mejor

Pieza a pieza, hemos estado reescribiendo nuestras herramientas de desarrollador en tecnologías Web estándar. En Developer Edition, la Consola, el Depurador, el Monitor de Red y el modo de diseño adaptable han sido implementadas en HTML plano, JavaScript y CSS sobre bibliotecas comunes como React y Redux. Esto significa que puedes utilizar tus conocimientos sobre desarrollo web para hackear en las herramientas de desarrollador. El código fuente para el debugger.html está en GitHub, y hacemos nuestro mejor esfuerzo para etiquetar bugs para principiantes y asesorar a nuevos contribuyentes.

Hemos implementado toneladas de nuevas características durante la reescritura, pero el depurador merece una mención especial. En primer lugar, los mapas de fuente (source maps) finalmente funcionan en todas partes, e incluso incluyen resaltado de sintaxis para el marcado como JSX:

También puedes observar que el depurador reconoce Webpack y lo etiqueta adecuadamente en el árbol de códigos fuente.

De forma similar, el depurador puede reconocer dos docenas de bibliotecas de JavaScript y agrupar sus stack frames en la pila de llamadas. Esto hace que sea fácil separar el código que has escrito del código proporcionado por un framework cuando estás rastreando un error:

Stacks de biblioteca, antes y ahora

Incluso implementamos puntos de ruptura “pegajosos” que se mueven de manera inteligente con tu código cuando lo refactorizas o reorganizas las declaraciones en un archivo.

Las otras herramientas también han mejorado: los grupos de consola ahora pueden colapsarse, el monitor de red puede pausarse, etc.

La mejor forma de descubrir las nuevas herramientas de desarrollo es descargar Developer Edition y probarlas tú mismo.

WebVR, FLAC y otras cositas

Firefox está impulsando capacidades nuevas y fundamentales de la Web. Firefox 55 introdujo el soporte para WebVR en Windows e incluyó soporte experimental en macOS. Con Firefox 58, WebVR está soportado por defecto tanto en Windows como en macOS.

Si estás interesado en crear experiencias de realidad virtual en la Web, revisa la librería A-Frame, o lee nuestro artículo en cómo Firefox Quantum ofrece un rendimiento uniforme a 90 fps en WebVR.

En otras primicias, Firefox 51 fue el primer navegador web en soportar FLAC,un formado de audio sin pérdida, en la Web. Hasta ahora, el soporte estaba limitado a Firefox en plataformas de escritorio (Windows, macOS y GNU/Linux), pero Firefox 58 añade soporte FLAC a Android. Esto significa que Firefox, Chrome y Edge soportan FLAC en todas las plataformas, a excepción de iOS.

También introdujimos algunos cambios para ayudar a medir y mejorar el rendimiento de Firefox:

  • El API PerformanceNavigationTiming proporciona acceso a las métricas de rendimiento relacionadas con la carga de la página.
  • Off Main Thread Painting (“OMTP”) se ha habilitado de forma predeterminada en Windows, lo que mejora la capacidad de respuesta de Firefox al reducir la carga de trabajo en el hilo principal.
  • Hemos habilitado limitación de temporizadores de fondo basada en presupuesto, lo cual reduce la velocidad de los scripts que están corriendo en pestañas inactivas, para economizar los recursos del CPU.

Por último, Content Security Policies (CSPs) ahora son compatibles con la directiva worker-src .

Adiciones al API de WebExtensions

Firefox Quantum eliminó el soporte para complementos legados (legacy) y agregó docenas de nuevas APIs de WebExtensions. Firefox 58 añade aún mas APIs, incluidas algunas para:

Por ejemplo, Tree Style Tab ahora puede adoptar colores del tema a partir de WebExtensions como VivaldiFox:

Actualmente estamos planificando capacidades adicionales en WebExtensions para 2018, incluyendo la posibilidad para ocultar pestañas de forma individual o la barra de pestañas completa.

Terminando

Estos son solo los aspectos más destacados. Para obtener más información acerca de qué esperar en Firefox 58, actualmente disponible en Beta y Developer Edition, consulta las notas de la versión y Firefox 58 para Desarrolladores en MDN.

Categorías: Mozilla Hispano

La vida después de Flash: multimedia para la Web abierta

Noticias de Mozilla Hispano - Jue, 11/01/2018 - 03:46

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por juliabis.

Flash hizo llegar vídeo, animación, sitios interactivos y, sí, anuncios a miles de millones de usuarios durante más de una década, pero ahora se se está marchando. Adobe dejará de soportar Flash para el año 2020. Firefox ya no lo soporta “fuera de la caja”, y Chrome tampoco. ¿Qué es lo siguiente? Hay toneladas de estándares abiertos que pueden hacer lo que Flash hace, y aun más.

Multimedia verdaderamente abierta

Flash prometió ofrecer una plataforma unificadora para construir y distribuir sitios web multimedia interactivos. Y, en su mayor parte, lo hizo. Pero la tecnología nunca fue realmente abierta y accesible, y Flash Player era demasiado voraz para los recursos de los dispositivos móviles. Ahora las alternativas de código abierto pueden hacer todo lo que Flash hace, y más. Éstas son las tecnologías que debes aprender si realmente quieres construir la web interactiva de mañana, ya sea que se haciendo animaciones web, juegos o vídeos.

Animación web CSS

La animación CSS es relativamente nueva, pero es la forma más fácil de comenzar con la animación web. CSS está hecho para diseñar sitios web con reglas básicas que dictan diseño, tipografía, colores y más. Con el lanzamiento de CSS3, las animaciones ahora son parte del estándar, y como desarrollador, depende de ti indicarle al navegador cómo debe hacer la animación. CSS es legible por humanos, lo que significa que básicamente hace lo que dice el comando. Por ejemplo, la propiedad “animation-direction” hace exactamente eso: especifica la dirección de la animación.

Ahora mismo puedes crear animaciones sin problemas con CSS. Es simple crear keyframes (cuadros clave), ajustar el tiempo, animar la opacidad y más. Y todas las animaciones funcionan con cualquier objeto que haz diseñado normalmente con CSS: texto, imágenes, contenedores, etc.

Se pueden hacer animaciones con CSS, incluso no estando familiarizado con los lenguajes de programación. Al igual que muchos proyectos de código abierto, el código está disponible en la web para que juegues con él. Mozilla también ha creado (y mantiene) exhaustiva documentación sobre animación CSS. La mayoría de los desarrolladores recomiendan usar animación CSS para proyectos simples y JavaScript para sitios más complejos.

JavaScript

Los desarrolladores han estado animando con JavaScript desde los primeros días. Scripts básicos de mouseover (eventos de puntero) han existido por más de dos décadas. Hoy, JavaScript junto con elementos <canvas> de HTML5 pueden hacer cosas sorprendentes. Incluso scripts sencillos pueden producir grandes resultados. Con JavaScript, puedes dibujar figuras, cambiar colores, mover y cambiar imágenes, y animar transparencia. La animación JavaScript usa el formato SVG (gráficos de vector escalables) para las animaciones, lo cual significa que el arte se dibuja en vivo basado en reglas matemáticas en vez de ser cargada y pintada. Esto significa que se mantiene bien definido en cualquier escala (a esto se debe el nombre) y puede ser controlado completamente. SVG ofrece pintado sin aliasing, rellenos de patrón y gradientes, efectos de filtro sofisticados, recorte basado en líneas arbitrarias, texto y animaciones. Y, por supuesto, es una recomendación de estándar abierto de la W3c en vez de un binario cerrado. Utilizando SVG, JavaScript, y CSS3, los desarrolladores pueden crear animaciones interactivas impresionantes que no requieren formatos o reproductores especializados.

La animación JavaScript puede ser muy refinada, incluyendo rebotes, detención, pausa, rebobinación, or cambio de velocidad. También es interactiva y puede ser programada para responder a clicks o movimientos del puntero. La nueva API Web Animations, construida con JavaScript, te permite refinar animaciones con más control sobre los keyframes y elementos, pero todavía está en una fase experimental temprana y algunas características pueden no tener soporte en todos los navegadores.

Adicionalmente, las animaciones JavaScript pueden ser programadas para responder a campos de formulario, envío de formularios, y pulsaciones de teclas. Y eso lo hace perfecto para la creación de juegos web.

Juegos web

Por un tiempo, Flash dominaba los juegos web. Era fácil de aprender, usar y distribuir. También era robusto, capaz de ofrecer juegos masivos multijugador en línea a millones. Pero hoy es posible ofrecer la misma experiencia – si no incluso mejor – utilizando JavaScript, HTML5, WebGL y WebAssembly. Con los navegadores modernos y los marcos (frameworks) de código abierto, es posible crear juegos de disparos en 3D, juegos de rol (RPG), juegos de aventura y mucho más. De hecho, ahora incluso se pueden crear experiencias de realidad virtual totalmente inmersivas para la web con tecnologías como WebVR y A-Frame.

Los juegos web dependen de un ecosistema de frameworks y plataformas de código abierto para funcionar. Cada uno juega un papel importante: de visuales hasta controles, desde el audio a las redes. Mozilla Developer Network tiene una lista completa de las tecnologías que están actualmente en uso. Estas son solo algunas de ellas y para qué se usan:

WebGL

Permite crear gráficos 3D (y 2D) acelerados por hardware y de alto rendimiento a partir del contenido web. Esta es una implementación soportada por la web de OpenGL ES 2.0. WebGL 2 va incluso más allá, posibilitando el nivel de soporte de OpenGL ES 3.0 en los navegadores.

JavaScript

JavaScript, el lenguaje de programación de la Web, funciona bien en los navegadores y continuamente se está haciendo cada vez más rápido. Se ha usado ya para crear miles de juegos, y constantemente se están desarrollando nuevos frameworks.

Audio HTML

El elemento <audio> permite reproducir fácilmente efectos de sonido simples y música. Si lo que necesitas es más complicado, ¡consulta la API de Web Audio para conocer el procesamiento de audio real!

API Web Audio

Esta API diseñada para controlar la reproducción, síntesis y manipulación de audio a partir de código JavaScript, permite crear efectos de sonido impresionantes, tanto como reproducir y manipular música en tiempo real.

WebSockets

La API de WebSockets te permite conectar tu aplicación o sitio a un servidor para transmitir datos en tiempo real. Lo que la hace perfecta para juegos multijugador, ya sean basados ​​en turnos o en eventos, servicios de chat y más.

WebRTC

WebRTC es una API ultrarrápida que puede ser utilizada en video-chat, llamadas de voz y aplicaciones web para compartir archivos en modo P2P. Se puede usar también para juegos multijugador en tiempo real que requieran baja latencia.

WebAssembly

Los motores de juego HTML5/JavaScript son ahora mejores que nunca, pero aún así todavía no pueden igualar el rendimiento de las aplicaciones nativas. WebAssembly promete ofrecer un rendimiento casi nativo a las aplicaciones web. La tecnología permite a los navegadores ejecutar código compilado C/C++, incluyendo a juegos creados con motores como Unity y Unreal.

Con WebAssembly, los juegos web podrán aprovechar la ejecución multihilo (multithreading). Los desarrolladores podrán producir juegos 3D avanzados para la web que se ejecuten casi a la misma velocidad que el código nativo, y sin comprometer la seguridad. Es un enorme avance para los juegos, y para la web abierta. Significa que los desarrolladores podrán construir juegos para cualquier computadora o sistema que pueda acceder a la web. Y debido a que se ejecutarán en navegadores, será fácil integrar los modos multijugador en línea.

Además, hay muchos motores de juegos HTML5/JavaScript. Estos motores se encargan de los aspectos básicos, tales como física y controles, y les brindan a los desarrolladores un marco / mundo sobre el que construir. Van desde ligeros y rápidos, como los motores 2D Atom y Quick, hasta motores 3D completos como WhitestormJS y Gladius. Hay docenas para elegir, cada uno con sus propias ventajas y desventajas para los desarrolladores. Pero al final, todos ellos producen juegos que se pueden jugar en navegadores web modernos sin plug-ins. Y la mayoría de esos juegos pueden ejecutarse en un hardware no tan potente, lo que significa que puede llegar a más usuarios. De hecho, los juegos escritos para la web pueden ejecutarse en tabletas, teléfonos inteligentes e incluso televisores inteligentes.

MDN tiene una amplia documentación sobre construcción de juegos web y varios tutoriales sobre construcción de juegos utilizando JavaScript puro y el framework de juego Phaser. Es un excelente lugar para comenzar el desarrollo de juegos web.

Vídeo

La mayoría de los servicios de vídeo ya han cambiado a la transmisión basada en HTML5 utilizando tecnologías web y codecs abiertos; pero otros se han apegado a los codecs FLV o FV4 basados ​​en Flash. Como se dijo anteriormente, los formatos de vídeo Flash se basan en una forma de operar a través del software que puede recargar los recursos de los navegadores web y las plataformas móviles. Los codecs de video modernos pueden usar el procesamiento de hardware para la reproducción de vídeo, aumentando enormemente la capacidad de respuesta y la eficiencia. Lamentablemente, solo hay una forma de cambiar de Flash a HTML5: volviendo a codificar el vídeo. Eso significa convertir el material de origen en formatos compatibles con HTML5 a través de un convertidor gratuito como FFmpeg y Handbrake.

Mozilla está ayudando activamente a construir y mejorar el formato de vídeo HTML5 de código abierto WebM. Este desarrollo se basa en el contenedor Matroska y utiliza los codecs de video VP8 y VP9 y los codecs Vorbis u Opus.

Una vez que el contenido se haya convertido a un formato compatible con HTML5, se podrán volver a publicar los vídeos. HTML5 tiene controles de medios incorporados, por lo que no es necesario instalar ningún reproductor. Es extremadamente fácil; sólo es necesario usar una sola línea de HTML:

<video src="videofile.webm" controls></video>

Es preciso tener en cuenta que los controles nativos pueden ser inconsistentes entre los navegadores. Sin embargo, como están hechos con HTML5, es posible personalizarlos con CSS y vincularlos a su vídeo con JavaScript. Eso significa que puede crear accesibilidad, agregar tu marca y mantener el aspecto y la coherencia entre los navegadores.

HTML5 también puede manejar transmisión (streaming) adaptable, mediante Media Source Extensions (MSEs). Aunque pueden ser difíciles de configurar por sí solos, puedes usar reproductores preempaquetados como Shaka Player y JW Player, los cuales pueden manejar los detalles.

Los desarrolladores de MDN han creado una guía en profundidad sobre como convertir vídeo Flash a vídeo HTML5, que da muchos más detalles acerca de este proceso. Afortunadamente, no es tan difícil como parece.

Flash: lo que viene

El futuro de la web está abierto (eso esperamos) y Flash, a pesar de ser una gran herramienta para la creatividad, no ha sido lo suficientemente abierto. Afortunadamente, muchas herramientas de código abierto pueden hacer lo que Flash hace, y aun más. Pero estamos todavía en las primeras etapas, y la creación de animaciones, sitios web interactivos y juegos web requiere cierto conocimiento de codificación. Todo lo que necesitas saber ya está ahí, sólo esperando que lo aprendas.

Las tecnologías web abiertas prometen ser mejores de lo Flash ha sido, y serán accesibles para toda persona que tenga una conexión a Internet.

Categorías: Mozilla Hispano

Presentando FilterBubbler: Una WebExtension construida con React/Redux

Noticias de Mozilla Hispano - Dom, 10/12/2017 - 20:26

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

Hace unos pocos meses mi compañero en software libre durante mucho tiempo, Don Marti, me llamó sobre una idea para una WebExtension. WebExtensions es el nuevo genial estándar para extensiones del navegador en que los equipos Mozilla como también Opera, Edge y unos cuantos otros navegadores principales están colaborando (nota del editor: el artículo original indica incorrectamente que Chrome y Mozilla están colaborando en WebExtensions). El API de WebExtensions te permite escribir complementos usando la misma metodología JavaScript y HTML que usas para implementar cualquier otro sitio web.

La idea de Don era básicamente escribir una herramienta de análisis de texto con la nueva API de WebExtensions. Esta herramienta te permitiría seguir varias actividades de navegador y recursos (historia, marcadores, etc.) y después te permite usar módulos de análisis de texto para descubrir patrones en tu propio historial de navegación. La idea era revolucionar sobre tipos de sofisticados análisis que los anunciantes hacen con las actividades cotidianas de navegación que damos por hecho. Las grandes compañías están usando técnicas avanzadas para modelar el comportamiento del usuario y controlar el contenido que recibimos, para manipular los resultados como el tiempo que un usuario gasta en el sistema o los anuncios que ven. Si proporcionamos herramientas para los usuarios para hacer esto con sus propios datos de navegación, ellos tendrían una mejor oportunidad de comprender sus propios comportamientos y una mayor conciencia de cuando los sistemas externos están intentando manipularles.

El otro objetivo principal sería proporcionar un ejemplo bien documentado de usar el nuevo API WebExtensions. Cuanto más leo sobre WebExtensions más me doy cuenta de que representa un cambio de estrategia por mover la inteligencia de la navegación web “fuera del límite”. Todas las clases de análisis y automatización pueden ser hechas con WebExtensions en una manera que potencialmente permita a las herramientas ser usadas en cualquiera de los navegadores web modernos. La única cosa que vi que faltaba era una manera de colaborar fácilmente sobre estas “recetas” para analizar contenido web. Yo sugerí que creáramos un plugin WordPress que proporcionaría una interfaz RESTful para compartir clasificaciones y el plan básico para “FilterBubbler” nació.

Nuestro prototipo inicial fue una prueba de concepto que usaba un pop-up extremadamente básico de HTML y un clasificador Bayesiano. Esta versión probó que podríamos obtener una clasificación útil de contenido web basado en cuerpos cargados a mano, pero estaba claro que necesitamos herramientas adicionales para tener el toque de un “consumidor”. Antes de que pudiéramos comenzar a añadir características importantes como servidores remotos de recetas, visualizaciones de clasificaciones y configuración, teníamos que tomar algunas decisiones sobre nuestra infraestructura. En este artículo, cubriré nuestros esfuerzos para  proveer un entorno UI moderno y el reto que planteó cuando se trabaja con WebExtensions.

React/Redux

El framework React y su implementación asociada Flux tomaron el mundo UI HTML cuando Facebook publicó la herramienta como software libre en 2013. React fue originalmente desplegado en 2011 como parte de la infraestructura de visualización de noticias en el mismo Facebook. Desde entonces la librería ha encontrado uso en Instagram, Netflix, AirBnB y muchos otros servicios populares. La herramienta gira en torno de una estrategia llamada Flux, la cual estrechamente define la manera en que el estado es actualizado en la aplicación.

Flux es una estrategia, no una implementación en sí, y hay muchas librerías que proporcionan su funcionalidad. Una de las librerías más populares hoy es Redux. El valor central de Redux es una vista universal simplificada del estado de la aplicación. Porque hay un único estado para la aplicación, el comportamiento que resulta desde una series de acciones de eventos es completamente determinística y predecible. Esto hace tu aplicación más fácil de comprender, probar y depurar. Un debate completo sobre los conceptos detrás de React y Redux está más allá del alcance de este artículo así que si estás comenzando, te recomendaría que leas el material introductorio de Redux o revisar el excelente curso introductorio de Dan Ambramov en Egghead.

Integración con WebExtensions

Entrando en detalle en el framework WebExtensions, una de los primeros obstáculos es que el contexto del UI del pop-up y la página de configuración están separados del contexto en el background (fondo). El estado del contexto del UI es regenerado cada vez que abres y cierras el UI. La comunicación entre el contexto UI y el contexto del script en el background se consigue mediante una arquitectura de paso de mensajes.

El estado de la extensión FilterBubbler será almacenado en el contexto de background, pero nosotros necesitamos enlazar ese estado con los elementos en el contexto de pop-up y la página de configuración. El proyecto Redux-WebExt de Alexander Ivantsov ofrece una solución para este problema. Su herramienta proporciona una  capa de abstracción entre el UI y las páginas en el background con un proxy. El proxy te da una apariencia de acceso directo para el almacenamiento Redux en el UI, pero en realidad dirige acciones al contexto background, y entonces envía las modificaciones de estado resultantes generadas por los reductores de vuelta al contexto UI.

Mapeo de acciones

Me llevo algo de esfuerzo tener las cosas funcionando a través del puente Redux-WebExt. Los componentes React que se ejecutan en los contextos UI piensan que están hablando con un almacenamiento Redux; de hecho, es una fachada que está intercambiando mensajes con tu contexto background. Los objetos acción que piensas que están dirigidos hacia tus reductores están en realidad serializados en mensajes, enviados al contexto de fondo y después desempaquetados y entregados al almacenamiento. Una vez los reductores terminan sus modificaciones de estado, el estado resultante es empaquetado y enviado de vuelta al proxy así que puede actualizar el estado del equivalente UI.

Redux-WebExt pone una tabla de mapping en el medio de sus procesos que permite modificar como los eventos de acción desde el front-end son entregados al almacenamiento. En algunos casos (i.e., operaciones asíncronas) realmente necesitas este mapeo para separar acciones que no pueden serializadas en objetos mensaje (como funciones callback).

En algunos casos esto puede ser un mapeo directo que solo copia datos desde un evento de acción UI, como este desde el mapeo FilterBubbler en store.js:

actions[formActionTypes.TOUCH] = (data) => { return { type: formActionTypes.TOUCH, ...data }; }

O, puedes necesitar mapear la acción UI para algo totalmente diferente, como este mapeo que llama una función asíncrona solo disponible en el almacenamiento de fondo:

actions[UI_REQUEST_ACTIVE_URL] = requestActiveUrl;

En definitiva, ten en cuenta el mapeo! Me llevo unas horas comprender su propósito. Comprender esto es crítico si quieres usar React/Reduct en tu extensión como nosotros.

Este arreglo hace posible usar herramientas React/Redux con mínimos cambios y configuración. Existen sofisticadas librerías para manejar formularios y otras tareas importantes de UI que se pueden conectar con el entorno WebExtensions sin tener ningún conocimiento de la conectividad basada en mensajes subyacentes. Una herramienta ejemplo que hemos ya integrado es Redux Form, que proporciona un sistema completo de manejo de formularios de entrada con validación y de otros servicios que tú esperarías en un desarrollo moderno.

Habiendo establecido que podemos usar una gran herramienta UI sin comenzar desde cero, nuestra siguiente preocupación es hacer que las cosas se vean bien. El material de diseño de Google es un estándar en interfaces popular, y la plataforma React tiene el popular Material UI, el cual implementa el estándar Google como un conjunto de componentes React/Redux. Esto nos da la habilidad de producir UI pop-ups y pantallas de configuración con gran apariencia sin tener que desarrollar una nueva herramienta.

Ponte ‘thunky’

Algunas de las operaciones que necesitamos realizar son basadas en callbacks, lo cual las hace asíncronas. En el modelo React/Redux esto presenta algunos problemas. Las funciones generadoras de acciones y reductores son diseñados para hacer su trabajo inmediatamente cuando son llamados. Las soluciones como dar acceso al almacenamiento dentro de un generador de acciones y llamar dispatch en un callback es considerado un antipatrón. Una solución popular es el puente Redux-Thunk. Agregar Redux-Thunk a tu aplicación es sencillo, solo tienes que pasarlo cuando creas el almacenamiento.

import thunk from 'redux-thunk' const store = createStore( reducers, applyMiddleware(thunk))

Tener Redux-Thunk instalado te proporciona un nuevo estilo de generadores de acciones en los cuales devuelves una función para el almacenamiento, el cual será pasado más tarde mediante una función dispatch. Esta inversión de control permite a Redux permanecer en control para secuenciar tus operaciones asíncronas con otras acciones en la cola. Como ejemplo, aquí tenemos una función que pide una URL de la pestaña actual y después sirve la petición para establecer el resultado en el UI:

export function requestActiveUrl() { return dispatch => { return browser.tabs.query({active: true}, tabs => { return dispatch(activeUrl(tabs[0].url)); }) } }

La función activeURL() se ve más típica:

export function activeUrl(url) { return { type: ACTIVE_URL, url } }

Debido que WebExtensions se extiende sobre diferentes contextos y se comunica con mensajería asíncrona, una herramienta como Redux-Thunk es indispensable.

Depurando WebExtensions

Depurar WebExtensions presenta algunos retos que funcionan un poco diferente dependiendo del navegador que estés usando. Independientemente del navegador que uses, la primera diferencia más importante es que el contexto de fondo de la extensión no tiene página visible y debe ser específicamente seleccionado para depurar. Comencemos con ese proceso para Firefox y Chrome.

Firefox

En Firefox, puedes acceder a tu extensión escribiendo about:debugging en el campo URL del navegador. Esta página te permite añadir y desempaquetar extensiones con el botón “Cargar complemento temporal” (o puedes usar la útil herramienta web-ext que permite comenzar el proceso desde la línea de comandos). Presionando el botón “Depurar” traerá un depurador de código para tu extensión. Con FilterBubbler, estamos usando la flexible herramienta webpack para aprovecharnos de las últimas características de JavaScript. Webpack usa el transpilador Babel para convertir nuevas características del lenguaje JavaScript en código que es compatible con los navegadores actuales. Esto significa que las fuentes ejecutadas por el navegador están significativamente modificadas respecto al original. Asegúrate de seleccionar la opción  “Mostrar fuentes originales” del menú de preferencias en el depurador o tu código parecerá muy diferente!

Una vez que lo has seleccionado deberías ver algo más parecido a lo que esperas:

Desde aquí puedes establecer puntos de ruptura y hacer todo lo demás.

Chrome

En Chrome es todo básicamente la misma idea, solo con unas pocas diferencias en el UI. Primero vas al menú principal, navegar abajo en “Más herramientas” y después seleccionar “Extensiones”:

Esto te lleva a la página de listado de extensiones.

La sección “Vistas de inspección” te permitirá iniciar un depurador para tus scripts de fondo.

Donde el depurador Firefox muestra todo tu actividad de segundo y primer plano en un solo lugar, el entorno Chrome hace las cosas un poco diferente. La vista UI es activada mediante click con botón derecho en el ícono de tu extensión y seleccionando la opción “Inspeccionar popup”.

Desde aquí las cosas son bastante como esperarías. Si has escrito aplicaciones JavaScript y usado la funcionalidad integrada en el navegador entonces esto te resultará bastante familiar.

Materiales de clasificación

Con toda nuestra nueva infraestructura y un depurador en funcionamiento, regresamos a añadir atributos a FilterBubbler. Uno de nuestros objetivos para el prototipo es proveer el API en la cual las recetas se ejecutarán. Los principales ingredientes para las recetas FilterBubbler son:

Uno o más orígenes: un origen proporciona una corriente de clasificación de eventos en las URLs dadas. El prototipo provee un simple origen el cual emitirá una petición de clasificación cualquier momento que el navegador se dirige a una página en concreto. Otros posibles orígenes podrían incluir una fuente que analiza una red social, una corriente de mensajes de correo electrónico o un segmento del historial del navegador.

Un clasificador: el clasificador toma contenido de un origen y retorna al menos una etiqueta de clasificación con un valor de peso. El clasificador podría devolver un array de parejas de etiquetas y pesos. Si el array está vacío entonces el sistema asume que el clasificador no fue capaz de encontrar una coincidencia.

Uno o más cuerpos: los cuerpos de FilterBubbler proporcionan una lista de URLs con etiqueta y pesos. Las etiquetas y los valores son usados para entrenar la clasificación.

Uno o más sumideros (sink): es el destino para la clasificación de eventos. El prototipo incluye un simple sumidero que conecta con el clasificador dado para un elemento UI, el cual muestra las clasificaciones en el pop-up de la extensión. Otros posibles sumideros podrían generar correos salientes para ciertas coincidencias de etiqueta de clasificación o un sumidero que escribe URL en una carpeta de marcador nombrada con la etiqueta de clasificación

Puede que un diagrama ayude. La siguiente configuración podría decirte si la página que estás actualmente mirando es “increíble o “estúpida” !

Transmitir el conocimiento

Las configuraciones para estos arreglos son llamados “recetas” y pueden ser cargados en tu configuración local. Una receta es definida con un simple formato JSON como el siguiente:

{ “recipe-version”: “0.1”, “name”: “My Recipe”, “classifier”: “naive-bayes”, “corpora”: [ “http://mywpblog.com/filterbubbler/v1/corpora/fake-news”, “http://mywpblog.com/filterbubbler/v1/corpora/ufos”, “http://mywpblog.com/filterbubbler/v1/corpora/food-blog” ], “source”: [ “default” ], “sink”: [ “default” ] }

El simple extracto de código de muestra arriba puede ayudar al usuario a diferenciar entre noticias falsas, avistamientos OVNIS y blogs de comida (un problema más grande de lo que puedes esperar en algunas ciudades). Actualmente las clasificaciones, fuentes y sumideros deben ser unas de las implementaciones proporcionadas y no pueden ser cargadas dinámicamente en el prototipo inicial. En otros artículos, ampliaremos esta funcionalidad y describiremos los retos que estas actividades presentan en el entorno WebExtensions.

Referencias

FilterBubbler en GitHub: https://github.com/filterbubbler/filterbubbler-web-ext

Material UI basado en React: http://www.material-ui.com/

Redux WebExt: https://github.com/ivantsov/redux-webext

Redux Form: http://redux-form.com/6.7.0/

Mozilla polyfill: https://github.com/mozilla/webextension-polyfill

Artículos relacionados:

Categorías: Mozilla Hispano

Introducción a sphinx-js, una mejor forma de documentar proyectos JavaScript grandes

Noticias de Mozilla Hispano - Jue, 30/11/2017 - 02:50

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

Hasta ahora, no ha habido una buena herramienta para documentar proyectos JavaScript grandes. JSDoc, durante mucho tiempo el único contendiente, tiene algunas características interesantes:

  • Un bien definido conjunto de etiquetas para describir estructuras comunes.
  • Herramientas como Closure Compiler que se engancha en estas etiquetas.

Pero el resultado siempre es una mera lista alfabética de todo en tu proyecto. JSDoc aplana y revuelve tus funciones, dejando a los nuevos usuarios a inferir sus relaciones y ordenarlas mentalmente en grupos comprensibles. Si bien puedes salirte con la tuya con librerías pequeñas, esto falla tristemente con otras más grandes como Fathom, que tiene nuevos conceptos complejos que explicar. Lo que he buscado en el manual de Fathom fue la capacidad de organizarlo lógicamente, intercalar prosa explicativa con documentos extraídos, y agregar secciones completas que no son más que una descripción conceptual y, sin embargo, enlazan con el resto del trabajo1.

El mundo de Python ha favorecido Sphinx por mucho tiempo, una herramienta de documentación con soporte para muchos formatos de lenguages y formatos de resultados, junto con indexación de primera clase, generación de glosarios, búsqueda, y referencia cruzada. Las personas han escrito libros enteros sobre ella. A través de complementos soporta de todo, desde diagramas Graphviz hasta videos de YouTube. Sin embargo, su soporte de JavaScript siempre ha carecido de la capacidad de extraer documentos desde código.

Ahora sphinx-js agrega esa capacidad, dando a los desarrolladores JavaScript lo mejor de ambos mundos.

sphinx-js consume comentarios y etiquetas JSDoc estándares – no tienes que hacer nada raro a tu código fuente (de hecho, se delega la conversión y extracción al JSDoc mismo, haciéndolo resistente a cambios futuros). Sólo tienes que hacer que Sphinx inicialice un directorio docs en la raíz de tu proyecto, activar sphinx-js como un complemento, y luego escribir tus documentos como quieras usando reStructuredText simple. Cuando llega el momento de llamar a alguna documentación extraída, usa un de las directivas especiales de sphinx-js, modelada según el ejemplo de autodoc centrada en Python. El ejemplo más sencillo se ve así:

.. autofunction:: linkDensity

Esto buscaría y encontraría esta función…

/** * Return the ratio of the inline text length of the links in an element to * the inline text length of the entire element. * * @param {Node} node - The node whose density to measure * @throws {EldritchHorrorError|BoredomError} If the expected laws of the * universe change, raise EldritchHorrorError. If we're getting bored of * said laws, raise BoredomError. * @returns {Number} A ratio of link length to overall text length: 0..1 */ function linkDensity(node) { ... }

Y genera un bloque bien formateado como esto:

Sphinx empieza a mostrar su flexibilidad cuando quieres hacer algo como agregar una serie de ejemplos largos. En lugar de abarrotar el código fuente alrededor de linkDensity, el material adicional puede vivir en los archivos reStructuredText que comprende tu manual:

.. autofunction:: linkDensity Cualquier cosa que escribas aquí será agregado a la descripción de la función justo después de su valor de retorno. ¡Es un buen lugar para ejemplos extensos!

También hay una directiva sphinx-js para clases, ya sea cualquier tipo de ECMAScript 2015 o de las funciones-como-constructor clásicas decoradas con @class. Opcionalmente, puede tierar sobre los miembros de la clase, documentando a como avanza. Puedes controlar el orden, activar o desactivar miembros privados, o incluir o excluir miembros específicos por nombre – todos los bien planeados casos inusuales que Sphinx soporta en código Python. Aquí hay un ejemplo del mundo real que muestra uno pocos métodos realmente públicos mientras esconde algunos métodos “friend” que son específicos del framework:

.. autoclass:: Ruleset(rule[, rule, ...]) :members: against, rules

Yendo más allá de las convenciones bien establecidas de Python, sphinx-js suporta referencias a entidades JS que de otro modo colisionaría: por ejemplo, un foo que es un método estático en un objeto y otro foo que es un método instancia en el mismo. Esto lo hace usando una variante de los namepaths de JSDoc. Por ejemplo…

  • someObject#foo es el método instancia.
  • someObject.foo es el método estático.
  • Y someObject~foo es un miembro interno, el tercer tipo posible superposición.

Ya que JSDoc está haciendo el análisis detrás de escena, aprovechamos su entendimiento de estas complejidades de JS.

Claro, JS es un lenguaje de indentación dura, así que las cosas se vuelven profundas y oscuras a toda prisa. ¿Quién quiere escribir esta ruta completa para documentar innerMember?

some/file.SomeClass#someInstanceMethod.staticMethod~innerMember

¡Qué feo! Afortunadamente, sphinx-js indexa todas estas rutas de objetos usando un árbol de sufijos, así que puedes usar cualquier sufijo que refiera sin ambigüedad a un objeto. Es probable que digas sólo innerMember. O, si hay 2 objetos llamados “innerMember” en tu código base, se podría eliminar la ambigüedad diciendo staticMethod~innerMember y así, moviendo a la izquierda hasta que tengas un único resultado. Esto te da brevedad y, como bono, te ahorra tener que tocar documentos a medida que las cosas se mueven alrededor de tu código base.

Con la madurez y poder de Sphinx, respaldado por las convenciones sintácticas y maquinaria analítica probada de JSDoc, sphinx-js es una excelente manera de documentar cualquier gran proyecto JS. Para empezar, revisa la documentación. O, para un ejemplo de gran escala, revisa la documentación de Fathom. Una página particularmente jugosa es la Referencia de Regla y Conjunto de Reglas, que intercala párrafos tutoriales con documentación de clases y funciones; su código fuente está disponible detrás de un enlace en la esquina superior derecha, como para todas las páginas.

Esperamos tus historias de éxito y reporte de errores — ¡y al próximo crecimiento de la documentación rica, comprensible y organizada de JS!

1JSDoc tiene tutoriales, pero éstos son poco más que simples páginas HTML. No tienen una capacidad particular para realizar enlaces cruzados con el resto de la documentación ni para llamar a los comentarios extraídos.

Artículos relacionados:

Categorías: Mozilla Hispano

La memoria en WebAssembly (y por qué es mas seguro de lo que piensas)

Noticias de Mozilla Hispano - Sáb, 25/11/2017 - 01:42

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

La memoria en WebAssembly funciona un poco distinto a como se hace en JavaScript. Con WebAssembly, tienes acceso directo a los bytes en crudo… y eso le preocupa a muchas personas. Pero en realidad es más seguro de lo que piensas.

¿Qué es un objeto de memoria?

Cuando un módulo de WebAssembly es instanciado, necesita un objeto de memoria. Puedes crear un nuevo WebAssembly.Memory y pasar ese objeto. O, si no lo haces, un objeto de memoria se creará y se adjuntará a la instancia automáticamente.

Todos lo que el motor de JS hará internamente es crear un ArrayBuffer (el cual está explicado en otro artículo). El ArrayBuffer es un objeto de JavaScript  referenciado desde JS. JA asigna la memoria por tí. Puedes decirle cuanta memoria vas a necesitar y creará un ArrayBuffer de ese tamaño.

Los índices del arreglo pueden ser tratado como si fuesen direcciones de memoria. Si necesitas más memoria,  puedes hacer algo llamado growing (crecer) para agrandar el arreglo.

Manipular la memoria de WebAssembly como un ArrayBuffer— como un objeto de Javascript — permite hacer 2 cosas:

  1. Facilita el paso de valores entre JS y WebAssembly.
  2. Ayuda a manejar la memoria de forma segura.
Pasando valores entre JS y WebAssembly

Debido a que solo es un objeto JavaScript, significa que JavaScript puede acceder a estos bytes de memoria. De esta forma, WebAssembly y JavaScript pueden compartir memoria y pasarse valores entre ambos.

En vez de usar una dirección memoria, utilizan un índice del arreglo para acceder a cada posición.

Por ejemplo, el WebAssembly puede poner un string en memoria. Éste se codificaría en bytes…

…y entonces poner esos bytes en el arreglo.

Y luego esto retornaría el primer índice, el cual es un número entero, para JavaScript. Así que JavaScript puede obtener estos bytes y usarlos.

Ahora, la mayor parte de JavaScript no sabe cómo trabajar directamente con bytes. Así que necesitarás procesar en el lado de JavaScript, como lo hiciste en el lado de WebAssembly, para convertir de  bytes a valores mas útiles como cadenas de texto.

En algunos navegadores, puedes usar las APIs de TextDecoder y TextEncoder. O puedes añadir funciones de ayuda a tu archivo .js. Por ejemplo, una herramienta como Emscripten puede agregar funciones para codificar y decodificar.

Así que ese es el primer beneficio de tener la memoria de WebAssembly como un objeto de JS. WebAssembly y JavaScript podrán pasar valores entre sí a través de la memoria.

Haciendo el acceso a memoria más seguro

Existe otro beneficio de tener la memoria de WebAssembly como si fuese un objeto de JavaScript: seguridad. Lo hace más seguro para ayudar a prevenir desbordamiento de memoria a nivel del navegador y ofreciendo aislamiento de memoria.

Desbordes de memoria

Cuando administras tú mismo la memoria, existe la posibilidad de olvidar de limpiar. Esto puede causar que el sistema se quede sin memoria.

Si la instancia de módulo de WebAssembly tiene acceso directo a la memoria, y se le olvida liberarla antes de que se salga del ámbito, entonces el navegador podría desbordar memoria.

Pero como el objeto de memoria es un objeto de JavaScript, el mismo es monitoreado por el recolector de basura (aunque su contenido no lo es).

Esto significa que si la memoria de la instancia de WebAssembly se sale del ámbito, todo el arreglo de memoria puede ser recolectado y liberado.

Aislamiento de la Memoria

Cuando la gente escucha que WebAssembly te puede dar acceso directo a memoria, suelen ponerse nerviosos. Piensan que un módulo maligno de WebAssembly puede ir a revisar en partes de la memoria donde debería. Pero ese no es el caso.

Los límites de ArrayBuffer poseen un límite, que es lo que el módulo de WebAssembly puede tocar directamente.

Puede acceder directamente a los bytes que están dentro del arreglo pero no puede ver mas allá de los límites del mismo.

Por ejemplo, cualquier otro objeto de JS que está en memoria, como window, no es accesible a WebAssembly. Eso es muy importante para la seguridad.

Cuando se da una carga o almacenamiento en WebAssembly, el motor hace un chequeo de los límites del arreglo para asegurarse que la dirección de memoria está dentro de la memoria de la instancia de WebAssembly.

Si el código intenta acceder una dirección más allá de los límites, el motor arrojará una excepción. Esto protege al resto de la memoria.

Artículos relacionados:

Categorías: Mozilla Hispano

CSS Shapes, clipping y masking – y cómo usarlos

Noticias de Mozilla Hispano - Mar, 21/11/2017 - 01:34

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

El lanzamiento de Firefox 54 introdujo nuevas características dentro de una propiedad ya genial de CSS: clip-path.

clip-path es una propiedad que nos permite recortar partes de un elemento. Hasta ahora, en Firefox solo podías utilizar un SVG para cortar un elemento. Pero con Firefox 54, también podrás utilizar CSS shapes: ¡Recuadros, círculos, elipses y polígonos!

Nota: esta publicación contiene muchas demostraciones que requieren soporte para clip-path y mask. Para poder ver e interactuar con cada demostración en esta publicación, vas a necesitar Firefox 54 o superior.

Uso básico

Es importante tener en cuenta que clipPath no acepta “imágenes” como entrada pero como elementos <clipPath>:

Algo genial es que estos elementos <clipPath> pueden contener animaciones SVG:

Sin embargo, con Firefox también tendremos funciones CSS shape a nuestra disposición. Éstas nos permiten definir shapes dentro de nuestras hojas de estilo, así no hay necesidad de un SVG. Las funciones shape que tenemos a nuestra disposición son: circle, ellipse, inset y polygon. Aquí los puedes ver en acción:

Y no sólo eso, también podemos animarlos con CSS. Las únicas restricciones son de que no podemos “mezclar” las funciones shapes (por ejemplo, mutar de un circle a un inset) y con polígonos animados, los polígonos deben preservar el mismo número de vértices durante toda la animación.

Aquí hay una animación simple utilizando un shape de circle:

Y aquí hay otra animación que utiliza polygon. Nota: aunque estemos limitados a preservar nuestro número de vértices, los podemos “mezclar” repitiendo los valores. Esto crea la ilusión de animar al polígono con cualquier número de lados.

Nota que el clip-path también abre nuevas posibilidades de diseño. La siguiente demostración utiliza clippping para hacer una imagen más interesante en un artículo de varias columnas:

Animando cosas con JavaScript

Clipping abre buenas posibilidades. En el siguiente ejemplo, clip-path ha sido utilizado para aislar elementos de un sitio. En este caso, simulando un tour/tutorial:

Se hace con JavaScript obteniendo las dimensiones de un elemento durante el proceso, y calculando la distancia respecto a un contenedor de referencia, y luego utilizando esa distancia para actualizar la forma de recuadro utilizada en la propiedad clip-path.

Ahora también podemos cambiar dinámicamente el clipping de acuerdo a la entrada del usuario, como en este ejemplo que incluye un efecto “periscopio” controlado por el mouse:

¿clip-path o mask?

Existe una propiedad CSS similar, mask, pero no es idéntica a clip-path. Dependiendo de tu caso de uso específico, deberías elegir una u otra. También nota que el soporte varía entre los navegadores, y actualmente Firefox es el único navegador que soporta completamente todas las características de mask, así que vas a necesitar ejecutar Firefox 54 para interactuar con las demostraciones de abajo en Codepen.

Masking puede utilizar una imagen o un elemento <mask> en un SVG. Por otro lado, clip-path utiliza un path SVG o un shape CSS.

Masking modifica la apariencia del elemento que oculta. Por ejemplo, aquí hay un mask circular llenado con un gradiente lineal:

Y recuerda que también puedes utilizar imágenes bitmap aún si no tienen un canal alfa (transparencia), mediante la modificación del mask-mode:

El concepto clave de masking es que modifica los píxeles de una imagen, cambiando sus valores  hasta el punto de hacer de algunos de ellos completamente transparentes.

Por otro lado, clipping “corta” el elemento, y esto incluye su superficie de colisión. Mira la siguiente demostración que muestra dos imágenes idénticas con mask y clip con la misma forma de cruz. Intenta posar el cursor sobre las imágenes y ve lo que pasa. Notarás que en la imagen con mask el área de colisión también contiene partes con mask. En la imagen clipped, la única parte visible es el área de colisión (la forma de cruz) del elemento.

¿Entonces masking es mejor que clipping, o viceversa? No, solo son utilizadas para diferentes cosas.

Espero que esta publicación haya despertado tu curiosidad sobre clip-path. ¡Utiliza Firefox para probarla!

Artículos relacionados:

Categorías: Mozilla Hispano

Quantum de cerca: ¿qué es el motor de un navegador web?

Noticias de Mozilla Hispano - Dom, 12/11/2017 - 03:16

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Sergio Carlavilla Delgado.

En octubre del año pasado Mozilla anunció el Proyecto Quantum – nuestra iniciativa para crear un motor de navegación web de nueva generación. Ya estamos en marcha con el proyecto. De hecho liberamos nuestra primera pieza significativa de Quantum con Firefox 53.

Pero sabemos que para personas que no construyen navegadores web (¡y eso es la mayoría de la gente!), puede ser difícil ver por qué algunos de los cambios que estamos realizando en Firefox son tan importantes. Después de todo, muchos de los cambios que estamos haciendo serán invisibles para los usuarios.

Con esto en mente, estamos lanzando una serie de publicaciones para proporcionar una visión más profunda de lo que estamos haciendo con el proyecto Quantum. Esperamos que esta serie de publicaciones te brinde una mejor comprensión de cómo funciona Firefox y las formas en que Firefox está construyendo un motor de navegación web de nueva generación para mejor aprovechar el hardware de los ordenadores modernos.

Para comenzar esta serie de publicaciones, creemos que es mejor comenzar por explicar el aspecto fundamental que Quantum está cambiando.

¿Qué es un motor de navegación web y cómo funciona?

Si vamos a empezar por algún lado, debemos empezar desde el principio.

Un navegador web es una pieza de software que carga archivos (normalmente de un servidor remoto) y los muestra localmente, permitiendo la interacción del usuario.

Quantum es el nombre clave para un proyecto que hemos emprendido en Mozilla para actualizar masivamente la parte de Firefox que calcula qué mostrar a los usuarios basándose en esos archivos remotos. El término que utiliza la industria para esta parte es “motor web”, y sin uno, estarías leyendo código fuente en lugar de ver realmente un sitio web. El motor web de Firefox se llama Gecko.

Es bastante fácil ver al motor web como una caja negra, algo así como una TV: los datos entran, y la caja negra calcula qué mostrar en la pantalla para representar esos datos. La pregunta de hoy es: ¿cómo? ¿Cuáles son los pasos que convierten los datos en las páginas web que vemos?

Los datos que componen una página web son muchas cosas, pero se desglosan principalmente en 3 partes:

  • código que representa la estructura de una página web
  • código que proporciona estilo: el aspecto visual de la estructura
  • código que actúa como un script de acciones que el navegador puede tomar: computación, reaccionar a las acciones del usuario, y modificar la estructura y el estilo más allá de lo que se cargó inicialmente.

El motor del navegador web combina la estructura y el estilo para dibujar la página web en tu pantalla y averiguar qué partes son interactivas.

Todo comienza con la estructura. Cuando se le pide a un navegador web que cargue un sitio web, se le da una dirección. En esta dirección se encuentra otra computadora que, cuando es contactada, enviará los datos de vuelta al navegador web. Los detalles de cómo esto ocurre es un artículo completo en sí mismo, pero al final el navegador tiene los datos. Estos datos son enviados en un formato denominado HTML, y este describe la estructura de la página web. ¿Cómo entiende un navegador web HTML?

El motor del navegador web contiene fragmentos especiales de código llamados parsers que convierten los datos de un formato en otro que el navegador web mantiene en su memoria. El parser de HTML toma el HTML, algo así como:

Hello!

Y lo analiza, entendiendo:

Bien, hay una sección. Dentro de la sección se encuentra un título de nivel 1, que contiene el texto: “Hello!”. También hay una imagen dentro de la sección. Puedo encontrar los datos de la imagen en la ubicación: http:// example.com/image.png

La estructura almacenada en memoria de la página web se denomina Modelo de Objeto de Documento o DOM (Document Object Model). A diferencia de un texto largo, el DOM representa un árbol de elementos de la página web final: las propiedades de los elementos individuales y qué elementos están dentro de otros elementos.

Además de describir la estructura de la página, el HTML también incluye direcciones donde se pueden encontrar estilos y scripts. Cuando el navegador los encuentra, se pone en contacto con esas direcciones y carga sus datos. Esos datos alimentan a otros parsers que están especializados en esos tipos de datos. Si se encuentran scripts, pueden modificar la estructura y el estilo de la página antes de que haya finalizado el parseo del archivo. El formato de estilo, CSS, juega el siguiente papel en nuestro motor del navegador web.

Con estilo

CSS es un lenguaje de programación que permite a los desarrolladores describir la apariencia de elementos particulares en una página. CSS significa “hojas de estilo en cascada”, denominado así porque permite múltiples conjuntos de instrucciones de estilo, donde las instrucciones pueden sobreescribir las instrucciones anteriores o más generales (llamado cascada). Un poco de CSS podría tener el siguiente aspecto:

section { font-size: 15px; color: #333; border: 1px solid blue; } h1 { font-size: 2em; } .main-title { font-size: 3em; } img { width: 100%; }

CSS se divide en gran parte en agrupaciones llamadas reglas, que constan de dos partes. La primera parte son los selectores. Los selectores describen los elementos del DOM (¿recuerdas los de arriba?) a los que se les está aplicando los estilos y una lista de declaraciones que especifican los estilos que se aplicarán a los elementos que coincidan con el selector. El motor del navegador web contiene un subsistema llamado motor de estilos cuyo trabajo es tomar el código CSS y aplicarlo al DOM que fue creado por el parser HTML.

Por ejemplo, en el CSS anterior, tenemos una regla que hace referencia al selector “section”, que coincidirá con cualquier elemento en el DOM con ese nombre. Entonces se hacen anotaciones de estilo para cada elemento en el DOM. Eventualmente, cada elemento en el DOM termina teniendo un estilo y llamamos a este estado el estilo computado para ese elemento. Cuando se aplican múltiples estilos que compiten sobre el mismo elemento, los que vienen después o son más específicos ganan. Piensa en las hojas de estilo como en el papel de trazado fino; cada capa puede cubrir las capas anteriores, pero también permite que se muestren las capas inferiores.

Una vez el motor del navegador web ha computado los estilos, ¡es hora de ponerlo en uso! El DOM y los estilos computados son introducidos en un motor de diseño que tiene en cuenta el tamaño de la ventana que se est´ dibujando. El motor de diseño utiliza varios algoritmos para tomar cada elemento y dibujar una caja que incluya su contenido y tenga en cuenta todos los estilos que se le aplican.

Cuando el diseño esta completo, es el momento de convertir el esquema de la página en la parte que tú ves. Este proceso se conoce como dibujado, y es la combinación final de todos los pasos previos. Cada caja definida se dibuja, llena del contenido del DOM y con los estilos del CSS. Ahora el usuario ve la página, reconstruida a partir del código que la define.

¡Esto solía ser todo lo que sucedía!

Cuando el usuario desplaza la página, volveremos a dibujar, para mostrar las partes nuevas de la página que estaban anteriormente fuera de la ventana. ¡Resulta, sin embargo, que a los usuarios les encanta desplazar la página! El motor del navegador web sabe con bastante seguridad que se le pedirá que muestre contenido fuera de la ventana inicial que ha dibujado (llamada ventana de visualización o viewport). Los navegadores más modernos aprovechan este hecho y dibujan más página de la que está visible inicialmente. Cuando el usuario se desplaza, las partes de la página que quiere ver ya están dibujadas y listas. Como resultado, el desplazamiento es más rápido y fluido. Esta técnica es la base de la composición, que es un término para las técnicas que reducen la cantidad de pintados requeridos.

Además, algunas veces necesitamos volver a dibujar partes de la pantalla. Tal vez el usuario esté viendo un vídeo que se reproduce a 60 cuadros por segundo. O tal vez hay una presentación de diapositivas o una lista animada en la página. Los navegadores pueden detectar qué partes de la página se moverán o actualizarán, y en lugar de pintar toda la página, crean una capa para contenerlo. Una página puede estar formada por muchas capas que se superponen entre sí. Una capa puede cambiar de posición, desplazamiento, transparencia o moverse detrás o delante de otras capas, ¡sin tener que volver a pintar nada! Bastante conveniente.

A veces, un script o una animación cambia el estilo de un elemento. Cuando esto ocurre, el motor de estilo necesita volver a calcular el estilo del elemento (y potencialmente el estilo de muchos más elementos de la página), recalcular el diseño y volver a dibujar la página. Esto lleva mucho tiempo en términos de velocidad de computadora, pero siempre que ocurra de manera ocasional, el proceso no afectará negativamente la experiencia del usuario.

En las aplicaciones web modernas, la estructura del documento en sí misma es modificada frecuentemente por los scripts. Esto podría requerir que todo el proceso de diseño comience más o menos desde cero, con el HTML siendo analizado en el DOM, computar el estilo, reflujo y dibujado.

Estándares

No todos los navegadores web interpretan HTML, CSS y JavaScript de la misma forma. El efecto puede variar: desde pequeñas diferencias visuales hasta el sitio web ocasional que funciona en una navegador y en no en otro. Actualmente, en la Web moderna, la mayoría de los sitios web parecen funcionar independientemente del navegador que elija. ¿Cómo logran los navegadores este nivel de consistencia?

Los formatos del código de sitios web, así como las reglas que rigen la forma en que el código se interpreta y se convierte en una página visual interactiva, se definen mediante documentos mutuamente acordados denominados estándares. Estos documentos son desarrollados por comités que constan de representantes de los fabricantes de los navegadores web, desarrolladores web, diseñadores y otros miembros de la industria. Juntos determinan el comportamiento preciso que el motor del navegador web debería exhibir dada una pieza especifica de código. Existen estándares para HTML, CSS y JavaScript, así como los formatos de datos de imágenes, vídeo, audio y más.

¿Por qué es esto importante? Es posible crear un motor para el navegador web completamente nuevo, y siempre que se asegure de que el motor cumpla los estándares, dibujará las páginas web de una manera que coincida con el resto de navegadores web, para las miles de millones de páginas web. Esto significa que la “salsa secreta” para hacer que los sitios web funcionen no es un secreto perteneciente a un navegador. Los estándares permiten a los usuarios elegir el navegador web que satisfaga sus necesidades.

No más ley de Moore

Cuando los dinosaurios vagaban por la tierra y las personas solo tenían ordenadores de escritorio, era una suposición relativamente segura de que las computadoras se volverían más rápidas y potentes. Esta idea se baso en la Ley de Moore, una observación en la cual la cantidad de componentes (y por lo tanto la miniaturización / eficiencia de los chips de silicio) se duplicaría aproximadamente cada dos años. Increíblemente, esta observación fue válida hasta bien entrado el siglo XXI, y algunos argumentarán que sigue siendo válida en la vanguardia de la investigación actual. Entonces, ¿por qué la velocidad de un ordenador medio parece haberse estabilizado en los últimos 10 años?

La velocidad no es la única característica que los clientes buscan cuando compran un ordenador. Los ordenadores rápidos suelen consumir mucha energía, calentarse mucho y ser muy costosos. A veces, la gente quiere un ordenador portátil que tenga una buena duración de la batería. A veces, quieren un pequeño ordenador con pantalla táctil, con una cámara que quepa en el bolsillo y ¡que dure todo el día sin cargar! Los avances en informática lo han hecho posible (¡lo cual es increíble!), pero a costa de la velocidad bruta. Del mismo modo que no es eficiente (ni seguro) conducir tu coche lo más rápido posible, no es eficiente conducir tu ordenador lo más rápido posible. La solución ha sido tener múltiples “ordenadores” (núcleos) en un chip de CPU. No es raro ver teléfonos inteligentes con 4 núcleos más pequeños y menos potentes.

Lamentablemente, el diseño histórico del navegador web asumió esta trayectoria ascendente de velocidad. Además, escribir código que sea bueno usando múltiples núcleos de la CPU al mismo tiempo puede ser extremadamente complicado. Entonces, ¿cómo hacemos un navegador rápido y eficiente en la era de muchos ordenadores pequeños?

¡Tenemos algunas ideas!

En los próximos meses, analizaremos más detenidamente algunos de los cambios que llegarán a Firefox y cómo aprovecharán mejor el hardware moderno para ofrecer un navegador más rápido y estable que haga brillar los sitios web.

¡Adelante!

Artículos relacionados:

Categorías: Mozilla Hispano
Subscribe to Proyecto NAVE aggregator - Mozilla Hispano