You are here

Noticias de Mozilla Hispano

Subscribe to Noticias de Mozilla Hispano feed Noticias de Mozilla Hispano
Tu comunidad en español de Mozilla
Updated: hace 2 horas 54 mins

Nuevo en Firefox 58: Developer Edition

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

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

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

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)

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

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?

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

El monitor de red recargado (parte 1)

Sáb, 14/10/2017 - 00:01

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

La herramienta del monitor de red ha estado disponible en Firefox desde los primeros días de las herramientas de desarrollo de Firefox. Es una herramienta indispensable para cualquier persona que se preocupa por el rendimiento de carga de las páginas web y las páginas web modernas y rápidas. Esta herramienta pasó por una extensa refactorización recientemente (bajo el nombre Netmonitor.html) y este artículo pretende ser una explicación de cómo diseñamos la nueva arquitectura y qué nuevas tecnologías hemos utilizado.

Observa el monitor de red ejecutándose dentro de la caja de herramientas de desarrollador de Firefox:

Objetivos

Uno de los principales objetivos de la refactorización fue reconstruir toda la herramienta utilizando tecnologías web estándar. Hemos eliminado todo el código antiguo específico de Firefox como XUL (XML User Interface Language), pero también el código que utilizaba APIs específicas de Firefox. Este es un gran paso adelante, ya que utilizar estándares web ahora te permite ejecutar todo el código en dos entornos diferentes:

  • Caja de herramientas de desarrollo
  • Cualquier página web

El primer caso es bien conocido para cualquiera que este familiarizado con las herramientas de desarrollo de Firefox (también puedes ver la imagen anterior). La caja de herramientas de desarrollo puede ser abierta fácilmente en la parte inferior de la ventana del navegador con varias herramientas, monitor de red incluido, a tu alcance.

El segundo caso de uso es nuevo. Ahora la herramienta puede cargarse dentro de una pestaña del navegador como cualquier otra aplicación web estándar. Observa cómo se ve en la siguiente captura de pantalla:

Nota que la página se carga desde localhost:8000. Ahí es donde se está ejecutando el servidor de desarrollo.

¡La posibilidad de ejecutar la herramienta como una aplicación web es una gran oportunidad! Ahora podemos utilizar todas las herramientas del navegador para el trabajo de desarrollo. Aunque antes era posible usar las herramientas de desarrollo para depurar las herramientas de desarrollo (con la caja de herramientas del navegador), ahora es mucho más fácil y más conveniente simplemente el uso de las herramientas del navegador. Y por supuesto, podemos ejecutar la herramienta en otros navegadores. El desarrollo también es más simple ya que no tenemos que compilar Firefox. En su lugar, una simple recarga de la pestaña es suficiente para volver a cargar el monitor de red y probar tus cambios en el código.

Arquitectura

Hemos construido el front-end del nuevo monitor de red sobre las siguientes tecnologías:

Las herramientas de desarrollo de Firefox necesitan funciones complejas para la interfaz gráfica y estamos usando el popular combo React & Redux para todas nuestras herramientas para construir un código limpio y consistente. El monitor de red no es una excepción. Hemos implementado un conjunto de componentes de React los cuales son responsables de procesar la vista (interfaz), un almacén con todos los datos interceptados por HTTP y finalmente un conjunto de acciones que el usuario podría querer ejecutar.

También hemos cambiado la forma en la que escribimos las pruebas. En lugar de utilizar la infraestructura de pruebas específica de Firefox, estamos cambiando lentamente hacia bibliotecas bien conocidas como Mocha y Enzyme. De esta manera es más fácil entender nuestro código y también contribuir a él.

Estamos utilizando Webpack para crear un paquete cuando se ejecuta dentro de una página web. Por consiguiente el paquete es servido a través de localhost:8000.

La arquitectura general está basada en un flujo introducido en el concepto React & Redux.

  • El componente raíz que representa el NetMonitorApp puede ser renderizado dentro de la caja de herramientas o en una página web.
  • Las acciones son responsables de cosas como el filtrado, limpieza de la lista de peticiones, ordenamiento y apertura de un panel lateral con información detallada.
  • Todos nuestros datos son almacenados dentro del objeto de almacenamiento. Incluyendo todos los datos recopilados sobre el tráfico HTTP.
Nuevas características

Hemos estado centramos principalmente en la refactorización del código, pero también se han implementado algunas nuevas características / mejoras en la interfaz de usuario a lo largo del camino. Veamos algunas de ellas.

Selector de columna

Hay nuevas columnas con información adicional sobre las solicitudes individuales y el usuario puede usar el menú contextual para seleccionar las que son importantes.

Resumen de datos

Hemos implementado un mejor resumen de las solicitudes mostradas actualmente en la lista. Ahora se encuentran en la parte inferior del panel.

  • Número de peticiones en la lista
  • Tamaño / tamaño transferido de todas las peticiones
  • Tiempo total requerido para cargar todas las peticiones
  • Tiempo en que el evento DomContentLoaded
  • Tiempo en que el evento load ocurre
Filtrado por propiedades

La interfaz de usuario del filtrado es ahora mucho más potente. Es posible filtrar la lista de peticiones conforme a varias propiedades. Por ejemplo, puedes escribir: larger-than:50 en la caja de entrada del filtro para ver sólo aquellas peticiones que son mayores de 50 bytes.

Lee más sobre el filtrado por propiedades en MDN.

Aprende más en MDN

Hay enlaces en muchos lugares de la interfaz de usuario que llevan a MDN para obtener más información. Por ejemplo, puedes aprender rápidamente cómo se utilizan varias cabeceras de HTTP.

Conclusión

Creemos que construir la nueva generación de herramientas para desarrolladores de Firefox utilizando estándares web es el camino correcto, ya que significa que las herramientas pueden ejecutarse en diferentes entornos e integrarse de manera más eficaz con otros proyectos (por ejemplo, IDEs). Basarse en estándares web hace muchas cosas posibles: ahora también podemos pensar en empaquetar nuestras herramientas como un servicio web que pueda beneficiarse de la plataforma de Internet. Podemos compartir datos recopilados, así como el contexto de depuración a través de la web, abriendo así las puertas a un verdadero mundo de depuración social.

El equipo de Netmonitor.html ha hecho una gran cantidad de trabajo en la refactorización. Muchas gracias al equipo principal:

  • Ricky Chien
  • Fred Lin

Pero también ha habido muchos contribuyentes externos:

  • Jaroslav Snajdr
  • Leonardo Couto
  • Tim Nguyen
  • Deepjyoti Mondal
  • Locke Chen
  • Michael Brennan
  • Ruturaj Vartak
  • Vangelis Katsikaros
  • Adrien Enault
  • Y muchos más…

Haznos saber lo que piensas. Puedes unirte a nosotros en el canal de Slack devtools-html.

Artículos relacionados:

Categorías: Mozilla Hispano

WebGL 2 disponible en Firefox

Dom, 08/10/2017 - 21:39

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

Con el lanzamiento de Firefox 51, ¡el soporte de WebGL2 ha llegado! WebGL es una API estándar para representar gráficos 3D en la web. Está basado en OpenGL ES, que es utilizado comúnmente para los videojuegos móviles.

Hasta la fecha, hemos sido capaces de utilizar WebGL 1 (basado en OpenGL ES 2) para representar gráficos fantásticos en el elemento <canvas>. WebGL 2, sin embargo, está basado en la especificación OpenGL ES 3.0, la cual introduce nuevas características – la mayoría destinadas a aumentar el rendimiento y la fidelidad visual.

Anteriormente, WebGL2 había sido utilizable mediante un parámetro de configuración
o en las ediciones Developer Edition o Nightly, pero con Firefox 51, está desbloqueado para todos los usuarios de Firefox en Windows, MacOS y GNU/Linux.

Demostración: “After the Flood” (PlayCanvas)

Para darte una idea del contenido que permite WebGL 2, estamos emocionados en destacar After the Flood, una demostración interactiva de WebGL 2 por PlayCanvas. (Por favor, ten en cuenta que esta demostración se encuentra disponible únicamente para el escritorio, con el soporte para móvil próximamente.) Da un paseo a través del fantástico entorno de agua, vidrio y acero ¡el cual se desarrolla completamente dentro de tu navegador web!

Cómo usar WebGL 2

Para disponer de un contexto WebGL 2, todo lo que tienes que hacer es solicitar uno a un elemento <canvas>. La cadena que usaremos para solicitar WebGL2 es “webgl2”.

let canvas = document.querySelector('canvas'); let ctx = canvas.getContext('webgl2');

WebGL 2 podría no estar presente en todos los navegadores, por lo que debes incluir algo de código para controlar los errores.

let canvas = document.querySelector('canvas'); let ctx = canvas.getContext('webgl2'); let isWebGL2 = !!ctx; if (!isWebGL2) { // intentar usar webgl 1 ctx = canvas.getContext('webgl') || canvas.getContext('experimental-webgl'); } if (!ctx) { console.log('your browser does not support WebGL'); } Unas palabras de advertencia…

Ten en cuenta que mientras WebGL 2 está basado en OpenGL ES 3.0, no es idéntico. Por ejemplo, WebGL 2 no soporta programas binarios y un número de restricciones opcionales en OpenGL se han hecho obligatorias para WebGL 2. Las diferencias entre las dos están presentadas en la especificación de WebGL 2, así que si ya estás familiarizado con OpenGL, podrás ponerte al día con WebGL 2 rápidamente.

Otra cosa a tener en cuenta es que WebGL 2 no es estrictamente compatible con WebGL1, asá que existe la posibilidad de que tu código WebGL 1 no funcione como se espera en un contexto de WebGL 2. Dicho esto, las diferencias son bastante mínimas, y deberías de poder portar tu código y shaders (sombreadores) sin mucha dificultad. Puedes leer la lista de incompatibilidades en la especificación, además de esta guía rápida de los fundamentos de WebGL 2 acerca de la migración de código desde WebGL 1 a WebGL 2.

Ten en cuenta que mientras WebGL 2 traerá estas nuevas características a muchos de nuestros usuarios, no podemos ofrecer WebGL 2 a usuarios con tarjetas gráficas o controladores viejos o anticuados.

Funciones destacadas Lenguaje de sombreado actualizado

WebGL 2 soporta OpenGL ES Shading Language 3.0, el cual permite programas de sombreado mucho más capaces y eficientes. Los nuevos juguetes incluyen:

  • Verdaderos tipos enteros
  • Bloques uniformes
  • Vincular los índices de ubicación para las entradas y salidas de shader en la fuente de sombreado
  • Descarte de fragmentos
  • Bucles dinámicos
  • Muestras sofisticadas de texturas incorporadas
Múltiples objetivos de renderizado (“MRTs”)

Este te permite renderizar varios búferes de color o texturas en un solo paso, usando múltiples salidas del sombreador de fragmentos.

Esta característica se habilitó en WebGL 1 a través de una extensión, pero ahora forma parte del conjunto básico de características de WebGL 2, por lo que no es necesario preocuparse por un camino alternativo.

Una de las principales aplicaciones de MRTs es una técnica llamada sombreado diferido – y ya hemos escrito antes acerca de ella en Hacks. Es una técnica de renderizado que permite gran cantidad de luces dinámicas en una escena, ya que la complejidad del renderizado no depende de la cantidad de luces, sino del número real de píxeles que se están encendiendo.

Dibujo de geometría instanciada

El instanciamiento te permite renderizar múltiples instancias de una geometría con una única llamada, lo que reduce la carga en la CPU. Ten en cuenta que cada instancia puede tener sus propios atributos, como una matriz de transformación, así que puedes usarlo para renderizar muchos objetos simulares, como partículas, árboles en un bosque, gente en una multitud, etc.

La siguiente demostración de THREE.js hace instanciación a través de una extensión – que, recuerda, ya no es necesaria en WebGL 2.

Nuevas características en texturas

Las texturas 3D o con volumen son texturas en las que se accede a los datos utilizando tres coordenadas en lugar de dos (como en las texturas 2D). Estas son más utilizadas para el mapeado de tonos, pero también pueden ser útiles para el renderizado de efectos volumétricos, como el humo, la niebla y los rayos.

Las matrices de texturas 2D contienen una serie de capas 2D separadas, las cuales un sombreador puede indexar para seleccionar sólo una de las texturas 2D contenidas.

Los objetos sampler son nuevos en WebGL 2. Estos desacoplan la forma en que se la textura se muestra de la textura seleccionada para el muestreo, por lo que se puede realizar el muestreo de una única textura de varias formas, y múltiples texturas pueden apuntar al mismo objeto sampler.

WebGL 2 también elimina las restricciones de las texturas non-power-of- two (NPOT).

Retroalimentación de transformación

La retroalimentación de transformación captura la salida del sombreador de vertex en un objeto de buffer, utilizando a menudo esta salida como entrada para el siguiente cuadro. Esto crea un bucle que no deja la GPU, liberando a la CPU de estos cálculos. Los sistemas de partículas suelen aprovechar ésto para iterar la posición de cada partícula y moverla en cada cuadro sin interacción de la CPU.

La retroalimentación de transformación también puede ser combinada con “rasterizer discard”, el cual permite correr el sombreador de vertex sin el sombreador de fragmentos. Esto permite flujos de procesamiento de datos naturales tipo “mapa” GPGPU (computación de uso general en GPU).

¡Y más!

Hay muchas más características que han llegado en WebGL 2, incluyendo Vertex Array Objects, MSAA renderbuffers y Uniform Buffer Blocks por nombrar algunas. Para una lista completa de todo lo nuevo en WebGL 2, puedes echar un vistazo a la especificación oficial, ya que sólo contiene las diferencias entre WebGL 1 y 2.

Algunas de estas características pueden ser vistas con relativo aislamiento en la página de ejemplos de WebGL 2. Estas demostraciones específicas de cada función sirven para ilustrar los nuevos efectos posibles con las nuevas características, así como para proporcionar código de ejemplo sobre cómo usarlas.

Lo que sigue

Estamos publicando la API para su uso generalizado, pero todavía hay más trabajo por hacer. Estamos deseando trabajar en mejorar el rendimiento, relajar algunas restricciones y mejorar el pulido general. Sabemos que todos tienen el rendimiento muy presente, por lo que tenemos un trabajo muy interesante en la trastienda para ofrecer aplicaciones con el rendimiento necesario para ofrecer experiencias aún más sofisticadas e impactantes.

Además de ver a las aplicaciones añadir soporte de WebGL 2, esperamos ver la integración de WebGL 2 en los frameworks y motores WebGL existentes. PlayCanvas soporta WebGL 2, como se muestra en nuestra destacada demostración After the Flood. Three.js también tiene soporte para utilizar WebGL 2. ¡Estate al tanto de otros motores que reciban soporte de WebGL 2 durante el año!

¿Algún problema? Por favor, registra un error en nuestro Bugzilla. (Recuerda: ¡también puedes usar GitHub para ingresar!)

Artículos relacionados:

Categorías: Mozilla Hispano

Mecanismos de control en juegos JavaScript

Sáb, 07/10/2017 - 04:06

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

Las laptops, computadoras, smartphones, tablets, televisores, e incluso refrigeradores tienen una cosa en común — probablemente corren un navegador, así que probablemente puedas jugar un juego HTML5 en ellos. Renderizar el juego en pantalla es una cosa, pero también tienes que controlarlo de algun modo, y hay un montón de opciones diferentes adecuadas para varias plataformas. Desde táctiles, pasando por el ratón y el teclado, al gamepad, incluso un control remote de televisor o … plátanos — estas interfaces están cubiertas en una serie de nuevos artículos sobre mecanismos de control, ahora disponibles en la MDN.

Para mostrar su uso en la vida real en un proyecto, estos mecanismos de control están implementados en el juego de demostración de Captain Rogers: Battle at Andromeda desarrollado con Phaser, para que puedas ver cómo el juego se ve afectado por la plataforma. También puedes ver que no necesitas desarrollos separados para diferentes plataformas — la naturaleza multiplataforma de la Web puede ayudarte a ajustar los controles al dispositivo en el que se juega sin mucho esfuerzo de codificación.

Hay una pequeña demostración de controles en JavaScript puro de código abierto en GitHub, así que puedes ver exactamente cómo están implementados estos mecanismos, y pruébalos por ti mismo en tus propio entorno de desarrollo. Sumérgete en el código, o revisa lo más destacado de las partes clave a continuación.

Tacto en móviles

Vamos a empezar con el soporte de tacto en móviles debido al enfoque de móvil primero en los juegos HTML5:

document.addEventListener("touchstart", touchHandler); document.addEventListener("touchmove", touchHandler); function touchHandler(e) { if(e.touches) { playerX = e.touches[0].pageX - canvas.offsetLeft - playerWidth / 2; playerY = e.touches[0].pageY - canvas.offsetTop - playerHeight / 2; } }

Estas pocas líneas de código JavaScript son todo lo que necesitas para unos controles muy básicos en tu juego, para que puedas jugarlo en dispositivos móviles. Las primeras dos líneas inicializan los monitores de evento para los eventos táctiles en los que estamos interesados — cuando tocas la pantalla, y cuando deslizas tus dedos a través de ella. La función verifica si algunos toques son realizados, y luego establece las coordenadas del jugador para que la nave se pueda renderizar en el lugar correcto del lienzo del juego.

Esto sólo es lo básico, y tú puedes (y deberías) expandir las posibilidades, por ejemplo implementar multitoques o gestos. Todo depende de qué tipo de juego tienes, y qué debe ser controlado (y cómo). También puedes ofrecer botones en pantalla para realizar acciones, por ejemplo flechas de movimiento y un botón de disparo. Mira el artículo de controles táctiles para móvil para más detalles.

Mouse y teclado de escritorio

Ya que estamos hablando de “flechas de movimiento”, puedes imprimirlas en pantalla para dispositivos móviles, pero puedes implementarlas en escritorio también. Las teclas de cursor o teclas WASD son formas populares de mover un personaje en el juego. Por ejemplo, el siguiente caso maneja las techas de cursor:

document.addEventListener("keydown", keyDownHandler); function keyDownHandler(e) { if(e.keyCode == 39) { rightPressed = true; } else if(e.keyCode == 37) { leftPressed = true; } if(e.keyCode == 40) { downPressed = true; } else if(e.keyCode == 38) { upPressed = true; } }

Todo se trata de detectar constántemente y luego guardar la información sobre qué tecla fue presionada, para que pueda ser procesada en el bucle de dibujo:

function draw() { ctx.clearRect(0, 0, canvas.width, canvas.height); if(rightPressed) { playerX += 5; } else if(leftPressed) { playerX -= 5; } if(downPressed) { playerY += 5; } else if(upPressed) { playerY -= 5; } ctx.drawImage(img, playerX, playerY); requestAnimationFrame(draw); }

Las variables de las posiciones x y y del jugador son ajustadas y luego la imagen de una nave es movida al nuevo punto.

El mouse de escritorio y los toques móviles son muy similares desde el punto de vista de codificación: todo lo que necesitas haces es darle la información de en donde ocurre el click o el toque y actualizar la posición del juegador:

document.addEventListener("mousemove", mouseMoveHandler); function mouseMoveHandler(e) { playerX = e.pageX - canvas.offsetLeft - playerWidth / 2; playerY = e.pageY - canvas.offsetTop - playerHeight / 2; }

El evento mousemove es detectado, y la posición del jugador es ajustada para colocar la nave en el centro del puntero del mouse siempre que cambie. Eso es todo lo que necesitas para hacer tu juego jugable en escritorio usando tanto teclado y mouse — para más detalle, revisa el artículo controles de teclado y mouse en el escritorio.

Gamepad

Mi control favorito — uso la API Gamepad para controlar todas mis diapositivas basadas en HTML durante mis presentaciones. He hablado sobre esta API algunas veces, escrito un par de artículos, implementado algunos juegos, e incluido toda la información relevante en el Kit de Contenido del API Gamepad. Es realmente asombroso de seamos capaces de sentir la experiencia de una consola en una computadora. ¡Y funciona gracias a las tecnologías Web! Jugar Captain Rogers con un gamepad enriquese la experiencia y se siente mucho mejor.

Cubrir el soporte del API Gamepad es un poco más complejo que eventos de tacto y telcado, pero sigue siendo bastante sencillo:

window.addEventListener("gamepadconnected", gamepadHandler); function gamepadHandler(e) { controller = e.gamepad; } function gamepadUpdateHandler() { buttonsPressed = []; if(controller.buttons) { for(var b=0; b

Cuando el gamepad se conecta, se lanza un evento así que podemos obtener la referencia a sus datos en una variable que podemos usar después. En cada actualización, un nuevo arreglo de botones presionados es creado, así que el estado actual siempre será el útlimo. También hay una función que recorrerá el arreglo para ver si un botón específico que nos interesa se presiona. Esta información puede, entonces, ser usada en el bucle de dibujo, en una manera similar a la comprobación del teclado:

function draw() { // ... gamepadUpdateHandler(); if(gamepadButtonPressedHandler(0)) { playerY -= 5; } else if(gamepadButtonPressedHandler(1)) { playerY += 5; } if(gamepadButtonPressedHandler(2)) { playerX -= 5; } else if(gamepadButtonPressedHandler(3)) { playerX += 5; } if(gamepadButtonPressedHandler(11)) { alert('BOOM!'); } // ... }

Esa es la manera en que controlamos la nave del jugador presionando los botones DPad correspondientes, e incluso lanzar una explosión de bomba con el botón A. También puedes detectar los ejes, o incluso construir tu propia pequeña librería para manejar la entrada desde gamepad — revisa el artículo sobre controles de gamepad en el escritorio para más detalles sobre esto.

Controles no convencionales

Si gustas, puedes ir incluso más lejos y jugar con un control remoto en una gran pantalla de televisor en tu sala, agitando tu mano en frente de una laptop, o presionar alimentos cotidianos conectados con cables a tu PC.

Por ejemplo, el cotrol remoto de los televisores Panasonic es sorprendentemente fácil de implementar, ya que reusa los eventos de teclado, y las fechas direccionales tiene los mismos códigos que las teclas de cursor de teclado — 37, 38, 39 y 40, así que está listo para usar. Si necesitas más botones específicos, aquí tienes una lista completa, junto con información más detallada.

En lugar de presionar los botones en un control remoto, puedes usar la capacidad de dispositivos Leap Motion para detectar la posición de las manos y otros parámetros para tomar control de la nave del navegador sin tocar algún control. En un bule predefinido podemos obtener los detalles de las manos...

Leap.loop({ hand: function(hand) { horizontalDegree = Math.round(hand.roll() * toDegrees); verticalDegree = Math.round(hand.pitch() * toDegrees); grabStrength = hand.grabStrength; } });

y usarlos para actualizar la posición del jugador:

function draw() { // ... if(horizontalDegree > degreeThreshold) { playerX -= 5; } else if(horizontalDegree < -degreeThreshold) { playerX += 5; } if(verticalDegree > degreeThreshold) { playerY += 5; } else if(verticalDegree < -degreeThreshold) { playerY -= 5; } if(grabStrength == 1) { alert('BOOM!'); } // ... }

Podrás encontrar la implementación de otros mecanismos de control como el efecto Doppler, la API de Proximidad, o incluso Makey Makey en el artículo de controles no convencionales.

Resumen

Estos días, hay una gran cantidad de dispositivos, grandes y pequeños, en los cuales puedes jugar juegos HTML5. ¿Tu reloj? ¿Un juego web activado por voz? Las posibilidades son infinitas. Y recuerda: cuantos más mecanismos de control pueda soportar tu juego, mejor, ya que podrá ser jugado en un amplio rango de dispositivos, en todas las plataformas posibles. Toma ventaja de las oportunidades habilitadas por el navegador.

Artículos relacionados:

Categorías: Mozilla Hispano

SLUD 2017: Software libre, tecnología, desarrollo e Internet de las Cosas

Lun, 02/10/2017 - 18:34

Mozilla Colombia participó de la Semana Linux en la Universidad Distrital -SLUD 2017- que se llevó a cabo del 28 de agosto al 2 de septiembre, organizada por el Grupo GNU/Linux de la Univerisdad Distrital (GLUD). El evento contó con la participación de más de 400 personas entre estudiantes, profesores, empresarios, representantes gubernamentales y más interesados en el software libre.

Durante el evento se reflexionó sobre el desarrollo, filosofía, uso y difusión del Software libre. Además, de las ventajas, alcances, progresos y también en la implementación del mismo para el progreso tecnológico de las sociedades. El objetivo fue el de promover el uso de software libre, la participación y reflexiones sobre el papel que cumple la tecnología en nuestras vidas, y como desde nuestro trabajo debemos priorizar pensar en el beneficio y desarrollo de las personas y sociedad en general.

A lo largo de esta semana, hubo conferencias, talleres, discusiones y también un hackathon de tecnología libre que se enfocó a Internet de las cosas (IoT). Por su parte Mozilla Colombia presentó la charla ‘Mozilla’s Open IoT Studio y Common Voice por Mozilla‘ en donde presentamos el estudio realizado por Mozilla sobre IoT, y cómo desde la comunidad venimos trabajando por prácticas y desarrollos responsables.

Nuestro interés se centra en que en los desarrollos se prioricen a las personas y también se conforme una red de profesionales de IoT que realizan investigaciones, hacen prototipos y construyen colaboraciones significativas. De igual forma, hablamos del proyecto Common Voice, cuyo objetivo es el de ayudar a que el reconocimiento de voz sea abierto para todos. Tanto Common Voices como Open IoT Studio son dos iniciativas de Mozilla, una comunidad de voluntarios que trabajamos por la Web abierta e inclusiva. A través de la innovación los Mozillians buscamos conseguir una meta común: Internet para las personas.

De igual forma este evento contó con la participación y el apoyo de grandes empresas y organizaciones que tienen y promueven culturas abiertas y libres lo que permitió mostrar los alcances del software libre e incrementar la confianza en su uso y desarrollo. Entre los participes estuvo también RedHat y Skinatech quienes compartieron y presentaron conferencias sobre algunos modelos de negocio del software libre. A su vez, Koghi dió su apoyo en la hackathón de IoT y por si fuera poco, durante la SLUD 2017 se llevó a cabo el lanzamiento del Portal de Software Público por parte del Ministerio de Tecnologías de la Información y Comunicaciones de Colombia.

El grupo GNU/Linux Universidad Distrital fue fundado en el 2002 como el primer grupo académico dedicado a software libre en el país. Su misión es fomentar el uso, apropiación y desarrollo de tecnología libre buscando su integración al desarrollo económico y social de la ciudad – región, con proyección en el ámbito nacional e internacional. Estos jóvenes trabajan de cerca con la administración distrital y el Ministerio de TIC y contribuyen con las decisiones en materia tecnológica de la ciudad de Bogotá. En el presente aparte de la Semana Linux, el colectivo trabaja en diferentes líneas de desarrollo como con Videojuegos, Realidad Aumentada, Seguridad informática y Hacking, Hardware abierto y libre, desarrollo en general y por supuesto GNU/linux.

El evento culminó con el hackathon enfocado a Internet de las Cosas (IoT). El hackathon consistió en realizar un proyecto de software libre implementando tecnologías de IoT, en el los participantes definían la idea de proyecto que querían trabajar durante la hackathon.

El proyecto ganador fue GeoSmart, desarrollado por un grupo de cuatro personas que ya venían trabajando desde antes en su idea de desarrollo. Este desarrollo consistió en un sistema de geolocalización de ambulancia, que en caso de un accidente de tránsito notificá a la ambulancia que se encuentra más cerca para que esta llegue lo más pronto posible al lugar de los hechos, de esta forma los pacientes o personas que soliciten el servicio serán atendidos de manera rápida y oportuna. Después de esto, se procederá a clasificar al paciente mediante una paleta de colores para remitirlo al hospital que cumpla con los requisitos, y se trazará la ruta mejor desde el lugar del accidente hasta el hospital seleccionado.

Fue una semana estupenda en donde se habló, promovió y vivió el software libre. La próxima versión de la Semana Linux tiene miras e interés en que sea más grande además de contar con la participación de más organizaciones, empresas, desarrolladores y comunidad en general. Así que desde ahora, todas las personas interesadas están invitadas a visitar los sitios Web, conocer los proyectos y participantes, seguirnos en nuestras redes sociales y estar pendientes de la próxima Semana Linux Universidad Distrital.

Escrito por Juan Velandia y Mónica Bonilla.

Artículos relacionados:

Categorías: Mozilla Hispano

¿Por qué WebAssembly es mas rápido que asm.js?

Sáb, 30/09/2017 - 22:10

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

WebAssembly, es nuevo formato de ejecución para la Web, disponible en la versión estable de la mayoría de navegadores. Uno de los principales objetivos de WebAssembly es ser rápido. Esta entrada explicará detalles técnicos de cómo lo hace.

Por supuesto, “rápido” es relativo. Comparado con JavaScript y otros lenguajes dinámicos, WebAssembly es rápido porque es estáticamente tipado y simple para optimizar. Pero WebAssembly pretende ser tan rápido como el código nativo. asm.js ha estado muy cerca de ello, y WebAssembly cierra la brecha aún más. Esta entrada se enfoca en como WebAssembly es más rápido que asm.js.

Antes de empezar, hay algunas advertencias: el rendimiento es difícil de medir y tiene muchos aspectos. También, en la tecnología siempre van a existir casos donde aún no se han optimizado. Así que no todas las pruebas de rendimiento actuales serán rápidas para WebAssembly. Esta entrada describe cómo WebAssembly debería ser rápido; donde aún no es, es debido a bugs que se deben corregir.

Ahora veamos por qué WebAssembly es rápido:

1. Inicio

WebAssembly está diseñado para ser rápido de descargar y rápido de analizar gramaticalmente, así que incluso las aplicaciones de gran tamaño pueden iniciar rápidamente.

En realidad no es tan fácil mejorar el tamaño de descarga de un archivo de JavaScript minificado y comprimido con gzip, ya que es casi tan compacto como el código nativo. Aún así, el formato binario de WebAssembly puede seguir mejorando, siendo diseñado con cuidado para ser de poco tamaño (los índices son LEB128s, etc.). Suele ser aproximadamente 10–20% mas pequeño (comparado con archivos comprimidos con gzip).

WebAssembly mejora el análisis gramatical en una forma mas grande: puede ser interpretado en un orden de magnitud mas rápido que JavaScript. Esto se debe principalmente a que los formatos binarios son mas rápidos de interpretar, especialmente aquellos diseñados para ello. WebAssembly también facilita analizar (y optimizar) funciones en paralelo, lo cual ayuda mucho en máquinas con múltiples núcleos.

El tiempo total de arranque puede incluir factores mas allá de la descarga y análisis gramatical, tales como la optimización del código de la VM, o descarga de dependencias adicionales antes de la ejecución inicial, entre otros. Pero la descarga y análisis son inevitables y por ello es importante mejorar tanto como se pueda. El resto puede ser optimizado y mitigado, bien sea en el navegador o en la aplicación (por ejemplo, la optimización total del código puede ser evitada usando un compilador base o intérprete para WebAssembly, al inicio).

2. Características de CPU

Un truco que hizo asm.js tan rápido es que, a pesar de que todos los números en JavaScript son doubles, en asm.js tienen una operación and de bits al final, lo que hace que sea lógicamente igual a un CPU haciendo una suma de enteros, algo en lo que los CPU son muy buenos. Así que asm.js facilitó a las VM usar el poder de los CPUs al máximo.

Pero asm.js estaba limitado a cosas que son expresadas en JavaScript. WebAssembly no está limitado a ello y nos deja usar características adicionales de la CPU tales como:

  • Enteros de 64 bits. Las operaciones en ellos pueden ser hasta 4 veces mas rápidas. Esto permite acelerar algoritmos de cifrado, por ejemplo.
  • Traslado de carga y almacenamiento. Es una gran ayuda, básicamente en todo lo que use memoria de objetos con campos fijos (structs de C, entre otros).
  • Cargas y almacenamiento no alineado, evita la necesidad de asm.js de enmascarar (que asm.js lo hace para compatibilidad con los vectores tipados). Esto ayuda prácticamente con cualquier carga y almacenamiento.
  • Varias instrucciones de CPU como popcount, copysign, etc. Cada uno de éstos ayudan en circunstancias específicas (ejem. popcount puede ayudar en el cryptonalisis).

Qué tanto beneficiará una prueba de rendimiento específica dependerá del uso de las características mencionadas anteriormente. Generalmente vemos una mejora de velocidad del 5% en promedio respecto a asm.js. Las futuras mejoras mejoras esperadas son el soporte de instrucciones SIMD.

3. Mejoras en el ecosistema de herramientas

WebAssembly principalmente es un objetivo de compilación, y por lo tanto tiene 2 partes: compiladores que lo generan (el lado del conjunto de las herramientas), y las máquinas virtuales (VM) que lo ejecutan (el lado del navegador). Un buen rendimiento depende de ambos.

Este ya era el caso con asm.js, y Emscripten hizo muchas optimizaciones en el lado de las herramientas, corriendo optimizadores de LLVM y también el optimizador de asm.js de Emscripten. Para WebAssembly, se ha construido encima de ello, pero hemos añadido mejoras significantes mientras se hacía. Tanto asm.js como WebAssembly no son objetivos de compilación comunes, y en maneras similares, se aprendieron lecciones durante los días asm.js que ayudaron a hacer mejor las cosas para WebAssembly. Particularmente:

En general, estas mejoras ayudan tanto que migrar de asm.js a WebAssembly ayudo a mejorar un (7% y 5% en Box2D, respectivamente).

4. Buen rendimiento

asm.js podía correr básicamente a velocidad nativa, pero nunca pudo hacer de forma consistente en todos los navegadores. La razón es que unos los optimizaron para una manera y otros de otra forma, produciendo diferentes resultados. Con el tiempo las cosas empezaron a converger, pero el problema era que asm.js no era un estándar: era una especificación formal de un subconjunto de JavaScript, escrito por un solo proveedor, que vio gradualmente interés por otros creadores de navegadores.

WebAssembly, por otra parte, ha sido diseñado en conjunto por todos los principales navegadores. A diferencia de JavaScript, que se puede hacer rápido usando muchos métodos creativos, o asm.js, que podía hacerse rápido usando métodos sencillos pero no todos los navegadores lo hicieron. WebAssembly tiene más acuerdos de como se debe optimizar. Aún existe mucho campo para para la diferenciación de VMs (diferentes formas de realizar la compilación, AOT vs. JIT, entre otros.), pero una buena base de rendimiento predecible se puede esperar para toda la Web.

Artículos relacionados:

Categorías: Mozilla Hispano