El sector de los navegadores web ya cuenta con un nuevo índice de referencia común para medir el rendimiento de todos ellos: Speedometer 3.0. Pero esta herramienta no es solo una actualización de Speedometer 2.0 (la referencia 'de facto' hasta ahora).

Desde su primera versión en 2014, creada en solitario por el equipo desarrollador de WebKit, Speedometer ha evolucionado significativamente. ¿La principal novedad de su nueva versión, además de ser el benchmark de este tipo más avanzado disponible?

Que ahora se trata de "un esfuerzo colaborativo sin precedente entre los tres principales motores de navegadores":

• Blink/V8 (Google, Microsoft).
• Gecko/SpiderMonkey (Mozilla).
• WebKit/JavaScriptCore (Apple).

"Esta es la primera vez que el punto de referencia Speedometer, o cualquier punto de referencia importante de navegador, se desarrolla a través de una colaboración respaldada por cada uno de los principales motores de navegador [...]".

"Se ha desarrollado bajo un nuevo modelo de gobernanza, impulsado por consenso, y está alojado en un repositorio compartido que está abierto a contribuciones. Esta nueva estructura implica mucho esfuerzo colectivo [...]".

De este modo, a partir de ahora, contaremos con una herramienta de referencia para comparar navegadores entre sí sin miedo a que las puntuaciones reflejen un sesgo a favor de uno de los motores.

En Genbeta

Firefox afirma haber superado a Chrome en velocidad. Tienen razón, pero su test tiene truco

Siempre es bueno contar con herramientas fiables, y que los estándares de desarrollo web (aunque sólo lo sean 'de facto', como en este caso) se desarrollen mediante cooperación entre compañías.

"Nuestro objetivo es proporcionar a los desarrolladores una herramienta que refleje de manera precisa las demandas del mundo real que enfrentan los navegadores modernos".

Sin embargo, Speedometer 3.0 busca ir más allá de simplemente medir la velocidad de ejecución de JavaScript o la capacidad de renderizado de las páginas. Y no lo decimos sólo porque incluya las últimas versiones de frameworks populares como React, Vue y Angular, sino que también introduce una variedad de cargas de trabajo simuladas para medir más aspectos del trabajo que el navegador realiza en respuesta a las acciones del usuario.

Así, esta herramienta intenta simular la gama completa de interacciones que un usuario típico llevaría a cabo en la WWW: desde editar texto enriquecido y leer sitios de noticias hasta trabajar con listas de tareas. Es este enfoque en la experiencia real del usuario lo que distingue a Speedometer 3.0 de otras herramientas de benchmarking.

En Genbeta

Microsoft Edge vs el resto: comparamos su rendimiento frente a Chrome, Firefox y Opera

Hay quien se pregunta si es necesario a estas alturas

Sin embargo, algunos expertos cuestionan la relevancia de este benchmark en un mundo donde la mayoría de los navegadores comparten una base tecnológica cada vez más homogeneizada, gracias a la adopción generalizada del motor de renderizado Chromium por parte de muchos de los navegadores (no sólo Google Chrome, sino también Microsoft Edge, Brave, Opera o Vivaldi).

Tarquin Wilton-Jones, experto en seguridad de Vivaldi (desarrolladores del navegador homónimo), señala que, si bien existen diferencias menores entre navegadores debido a opciones de compilador, en términos prácticos, estas son casi despreciables cuando todos comparten el mismo núcleo:

"Lo que realmente marca la diferencia para los usuarios son las pequeñas características y funcionalidades únicas de cada navegador. Estas pruebas no capturan completamente esos aspectos, por lo que su utilidad puede ser limitada en ciertos casos".

Dicho esto, la realidad es que, hasta ahora, no sólo Safari, también Chrome y MS Edge sacaban pecho cada cierto tiempo de ser el navegador más rápido... y lo hacían tomando Speedometer como referencia, lo cual indica que lo consideran lo bastante útil como para aplicar mejoras con base al mismo.

En Genbeta | "Podríamos haber tenido streaming de videojuegos hace años": ingeniero de Chrome acusa a Apple de retrasar la adopción de tecnologías web

Alex Russell es un ingeniero de software que trabaja en el desarrollo de Google Chrome desde hace 12 años; también tiene un blog titulado Infrequently Noted en el que habla de navegadores y estándares web. Y el pasado viernes publicó un post en el mismo titulado "El progreso retrasado es progreso denegado" en el que argumenta una polémica acusación contra Apple.

Russell recopila, antes de exponer su tesis, tres hechos:

1. Que Apple prohíbe la presencia de aplicaciones web progresivas en la App Store, la única tienda de apps disponible en iOS.
2. Que Apple obliga a que todos los navegadores de la competencia usen su motor HTML (WebKit) al ser portados a iOS, prescindiendo de los suyos propios.
3. Que Apple enarbola las PWAs como defensa en las demandas antimonopolio, como demostración de que es 'posible' usar apps al margen de la App Store en iOS.

Y, a partir de ahí, pone sobre la mesa su teoría: que Safari y WebKit llevan años siendo deliberadamente retrasados en su desarrollo frente a otros navegadores precisamente con el fin de que las PWAs nunca puedan convertirse en una alternativa creíble a las aplicaciones de la App Store.

En Genbeta

Microsoft xCloud y Google Stadia son las últimas "víctimas" de las normas de Apple en la App Store, y no llegarán a iPhone y iPad

Tecnologías habituales que no verás en WebKit para iOS

Pero, ¿qué clase de funcionalidades disponibles desde hace tiempo en el resto de navegadores faltan por ser implementados Safari/WebKit para iOS? ¿En serio son tantas como para hablar de un retraso deliberado? Pues bien: esta lista incluye tecnologías tan básicas y cotidianas como

• Las ya cotidianas notificaciones push (con lo que eso supone para las apps de mensajería, redes sociales, noticias, viajes o e-commerce).

• Las indicaciones de instalación de PWA y creación de accesos directos a las mismas, dos aspectos fundamentales para éstas a la hora de competir contra las apps nativas.

• Acceso a la Screen Wake Lock API, que impide que el protector de pantalla tome el control en momentos críticos, una función fundamental para apps de presentaciones o de visualización de códigos QR.

• La Media Session API, que permite la reproducción multimedia cuando la app web está en segundo plano; está ya en desarrollo para WebKit… pero ya lleva un retraso de 5 años con respecto al resto de navegadores.

• Acceso a otras API como las de Web Share Target, fundamental para compartir contenidos desde las aplicaciones web.

• Precarga de navegación, que proporciona experiencia sin conexión y es una de las funciones más demandadas por las principales PWAs del mercado.

• Ya no hablemos de las APIs de acceso a hardware, un campo en el que Chromium tiene el liderato y que carece del más mínimo soporte por parte de iOS: tecnologías como Web Serial, Web Bluetooth, Web USB y similares son fundamentales, por ejemplo, para permitir el manejo desde una web de dispositivos IOT.

Retrasos de 5 años que lastraron la aparición de servicios como Stadia

Otras tecnologías web, ya disponibles en Safari para iOS sufrieron un retraso de media década con respecto a su implementación en los navegadores de la competencia.

Entre ellas, destacan WebRTC (protocolo de red en tiempo real fundamental en aplicaciones de videoconferencia, uso compartido de escritorio y streaming de juegos) o Gamepad API, una pieza básica para PWAs de streaming de juegos como Stadia, GeForce NOW o xCloud.

En Genbeta

Estas aplicaciones web gratuitas son tan buenas que pueden llegar a sustituir al software que solemos instalar

Otras tecnologías relacionadas con el rendimiento gráfico de las aplicaciones web siguen sin llegar a iOS, como es el caso de la API gráfica WebGL2, presente en Chrome y Firefox desde 2017 y aún 'en desarrollo' en WebKit, o el de su sucesora WebGPU, cuya llegada a iOS aún no está programada (Chrome tiene previsto incorporarla antes de que termine el presente año).

WebXR, una API para la realidad virtual online disponible en Chrome desde hace dos años, tampoco tiene fecha oficial de desembarco en iOS.

El post de Russell incluye muchos más casos similares. Pero si hay una sección que debamos destacar del post es la siguiente:

"La política de Apple contra la libre elección del motor de navegador añade años de retrasos [...] esto se traduce en que los desarrolladores web no pueden competir con sus homólogos de aplicaciones nativas en iOS en categorías críticas como juegos, compras y herramientas creativas.

Supongamos que Apple hubiera implementado WebRTC y la API de Gamepad a su debido tiempo. ¿Podríamos afirmar que la revolución del streaming de videojuegos que estamos viviendo ahora teniendo lugar podría haber sucedido antes? Sí, es posible que se hubieran podido desarrollar años antes productos como Amazon Luna, NVIDIA GeForce AHORA, Google Stadia y Microsoft xCloud".

También es posible que las API ya implementadas en todas las demás plataformas, pero que aún no están disponibles en los navegadores para iOS, por culpa de Apple, puedan resultar clave para desbloquear categorías enteras de experiencias en la web".

Microsoft está poniendo mucho empeño en que su nuevo navegador consiga situarse casi desde el momento de su salida a la misma altura que veteranos como Chrome o Firefox, y para conseguirlo están dispuestos a romper con todo lo que han hecho en el pasado y emprender un nuevo camino muy diferente al que venían siguiendo con Internet Explorer.

Con esto no nos referimos sólo a todas las nuevas funciones que va a implementar Microsoft Edge, sino también a cambios internos y de filosofía destinados a que los desarrolladores vuelvan a confiar en ellos eliminando, tal y como han contado en un post de su Microsoft Edge Dev Blog, los obstáculos a los que se tenían que enfrentar a la hora de desarrollar páginas para su predecesor.

Adaptándose a los nuevos estándares

Hasta ahora la estrategia de Microsoft con Internet Explorer había sido la de centrarse en sus propios estándares, algo que teníamos que sufrir todos los usuarios cuando entrábamos en ciertas páginas que, al estar especialmente pensadas para funcionar en su navegador, funcionaban mal o daban problemas a la hora de acceder a ellas desde otros.

Microsoft Edge implementará 45 nuevos estándares

Microsoft también han decido dar un paso atrás en la utilización de los agentes de usuario, que es lo que utilizan las páginas para identificar qué navegador se está utilizando para ofrecerle diferentes tipos de contenido. De esta manera, quieren hacer que lo que un usuario de Microsoft Edge vea en una web sea exactamente lo mismo que verán los que utilicen Chrome o Firefox.

Unificando contenidos y aumentando la flexibilidad

Los de Redmond quieren ser flexibles y apostar por unas webs diseñadas por igualpara todos los navegadores, de manera que le han pedido públicamente a los desarrolladores que no hagan sus webs pensando en Edge o Internet Explorer.

Para desanimar a los que todavía se resistan a estas prácticas, Microsoft Edge se identificará a sí mismo como un navegador WebKit. De hecho, Microsoft ha llegado a asegurar en su post que cualquier diferencia que se pueda encontrar entre Edge y WebKit será básicamente un bug que estarán interesados en arreglar.

Las diferencias entre Edge y WebKit serán tratadas básicamente como bugs

Edge también se adaptará a la realidad con unas cuantas medidas como la de soportar el CSS prefijado para WebKit, relajando las normas de los estándares y siendo mucho más permisivo a la hora de aceptar el código y los tags malformados en vez de simplemente ignorarlos como hasta ahora siempre había hecho su antecesor.

Vía | Microsoft Edge Dev Blog
En Genbeta | Microsoft Edge ya está entre nosotros, el nuevo navegador de Microsoft ya tiene nombre

Opera es uno de los navegadores que más tiempo llevan por Internet. Lleva funcionando desde 1994, con cada vez más mejoras e innovaciones. A pesar de eso, nunca ha pasado de tener una cuota marginal en el escritorio. Hoy, han hecho un anuncio sorprendente: dejarán de desarrollar su motor Presto para pasarse a WebKit. Aunque Opera ya había anunciado Opera Ice, un proyecto con WebKit, no esperábamos que abandonasen su propio motor de renderización.

¿Las razones? Que WebKit es código abierto y que pueden dedicarse a mejorarlo y colaborar con Google y Apple en lugar de simplemente hacer un desarrollo paralelo. A cambio, podrán dedicar más recursos a mejorar la experiencia de usuario: mejor interfaz, más características... Además, WebKit soporta la gran mayoría de estándares (y no estándares también).

Según Opera, la migración será gradual, y llegará tanto al escritorio como a las versiones de tablet y móvil de sus navegadores. Y prometen sorpresas dentro de unos días, en el MWC, donde mostrarán lo que tienen preparado en Opera para Android.

Para los usuarios de Opera, es una noticia muy buena. Se acabaron las ventanitas de "este sitio no es compatible con tu navegador". El motor de renderizado será el mismo que el de Chrome, así que todas las páginas deberían funcionar sin ningún problema (o, mejor dicho, con menos problemas que antes).

Ahora bien, para el resto de usuarios de Internet, no creo que sea una noticia tan buena. No porque WebKit sea malo, no, sino porque se está convirtiendo en lo que muchos llaman el nuevo Internet Explorer 6. No os tiréis a mi yugular todavía: se dice en el sentido de que los desarrolladores web están empezando a centrarse _únicamente_ en que las webs funcionen en WebKit. Veréis muchas páginas web, sobre todo las que hacen uso intensivo de HTML5, CSS3 y demás tecnologías de última hora, que sólo funcionan en Chrome o Safari.

De momento no es un problema muy grande, porque como digo la mayoría de cosas funcionan a la perfección en todos los navegadores, y WebKit no se está separando demasiado de la senda de los estándares. Sin embargo, es algo a lo que deberíamos estar atentos para no repetir los errores del pasado.

Vía | The Verge Más información | Opera

Los usuarios de Mac OS X más veteranos quizás conozcan a Camino, un navegador sin grandes pretensiones con una gran ventaja: implementa el motor de renderizado Gecko de forma nativa en una interfaz construida en Cocoa. Camino ha sido siempre una alternativa discreta, pero apreciada por ser una aplicación muy ligera frente a otros navegadores más pesados como Firefox o Safari.

Hasta ahora todo ha ido bien con Camino, pero ahora Mozilla acaba de anunciar el fin de la tecnología que permitía incluir Gecko de forma nativa en el navegador. Por este motivo, los desarrolladores voluntarios de Camino han llamado a recapitular y decidir el futuro del navegador en su blog oficial:

<blockquote>

El futuro es incierto. [...] Nadie trabaja en Camino como empleado, sino que todos lo hacemos de forma voluntaria y en nuestro tiempo libre. Crear un ‘fork’ del proyecto para integrar Gecko de forma nativa es teóricamente posible, pero no tenemos recursos humanos para poder hacerlo. Otra opción más realista seria pasar a usar Webkit, pero tampoco somos tantas personas como para poder hacerlo posible. Animamos a cualquier interesado en llevar a Camino hacia un nuevo motor de renderizado que se pase por nuestros foros de desarrollo.

</blockquote>

Es curioso como algunos de los navegadores que nacieron usando Gecko pasan a basarse en Webkit. Flock ya lo hizo, y si Camino consigue los suficientes voluntarios también lo va a hacer. Si no, me temo que veremos como se abandona el avance de uno de los navegadores para Mac OS X. Esperemos que no pase.

Vía | MacStories
Más información | Blog oficial de Camino

Falta ya muy poco para que Office 2011 para Mac llegue a las estanterías de las tiendas, y aún con esta corta espera la nueva suite ofimática de Microsoft nos sigue dando sorpresas: Outlook utiliza el motor WebKit de Apple para renderizar los elementos HTML que puedan aparecer en los correos electrónicos.

Es la primera vez en la historia del software de Microsoft en Mac OS X que la compañía de Redmond prefiere usar un motor de renderizado diferente al suyo, hasta ahora los usuarios de Entourage (el nombre que recibía el gestor de correos de Office para Mac hasta ahora) abrían sus correos con HTML renderizados con un motor propio sacado de Microsoft Word.

Son también noticias buenas desde el punto de vista del código libre, ya que al fin y al cabo Microsoft ha pasado de usar su motor propietario a usar el motor abierto de Apple. Además, Outlook 2011 también usa WebKit en sus plantillas para crear correos con un diseño hecho con HTML, integrándose aún más con el sistema Mac OS X.

Vía | 9to5mac

Boxee va camino de ser una excelente opción en el mundo de los reproductores multimedia de salón, y poco a poco "su desarrollo va dándonos noticias":https://www.genbeta.com/multimedia/boxee-beta-disponible. La última es que la aplicación ha decidido dejar a un lado el motor Gecko para usar WebKit en su módulo de navegación web.

La razón según el mismo equipo de desarrolladores es que de este modo se garantiza el soporte del nuevo estándar HTML5, que no terminaba de funcionar del todo bien con el motor de Firefox. De hecho, califican a WebKit como "el futuro de los exploradores que se usan desde el televisor".

La versión final de Boxee estará disponible a finales de año, tras la salida del hardware Boxee Box para reproducir contenido. Con esto, Boxee se sitúa en una buena posición para poder hacer frente a Google TV y a la nueva estrategia de Apple con su "nuevo Apple TV":https://www.applesfera.com/apple/nuevo-apple-tv-sencillamente-asombroso, a la venta de momento en una serie de países donde hay servicio de alquiler de películas.

Vía | "Electronista":http://www.electronista.com/articles/10/09/08/boxee.browser.to.drop.firefox.for.webkit/ Imagen | "Nan Palmero":http://www.flickr.com/photos/nanpalmero/4278434739

¿Os acordáis de Flock, esa apuesta de navegador con los servicios de las principales redes sociales integradas en él? Era una buena idea, pero no ha llegado a cuajar mucho entre los usuarios por ser lento y pesado, además de demasiado recargado para la mayoría. Después de algunos signos de cambio el año pasado, parece que Flock quiere cambiar de aspecto para centrar de nuevo nuestra atención.

Lo primero y más importante es que Flock pasará de basarse en Gecko a hacerlo en Webkit, con la ayuda del proyecto Chromium de código libre. Gracias a eso conseguirá más rendimiento, y una nueva interfaz que se olvida completamente del recargado aspecto que tenía Flock anteriormente. Ahora el navegador cuenta simplemente con una barra lateral en la que podremos integrar las redes sociales que queramos y que están disponibles. Además, el aspecto en general del navegador recuerda mucho al de Chrome, graciasa las pestañas superiores y a la simplicidad. Por supuesto, también acaptará extensiones.

También tendremos una nueva funcionalidad llamada Groups, en la que podremos centrar las actualizaciones de ciertos contactos en las redes sociales para estar al corriente de lo que digan. De este modo podemos, por ejemplo, tener un grupo para nuestros familiares presentes en Twitter o Facebook.

Flock 3 está en estado de beta para Windows, y una versión para Mac OS X llegará el mes que viene.

Vía | The download blog
Sitio oficial y descarga | Flock Beta

Hoy os presento un salvapantallas que hará las delicias de todo aquél que quiera personalizarlo y actualizarlo al máximo. Websaver es una aplicación _shareware_ para Mac OS X que se basa en WebKit y que nos permite configurar qué webs se van a visualizar cuando el sistema active el salvapantallas. Tan fácil como entrar en sus opciones, seleccionar aquellas direcciones que vamos a mostrar, cuatro parámetros básicos como el permitir ejecución de código javascript, el tamaño de la fuente o la opacidad y listo, ya tendréis salvapantallas configurado.

Tampoco conviene dejarlo conectado a nuestras redes sociales o a webs con información personal ¡para que todo el mundo pueda leer nuestro buzón de correo por ejemplo! (aunque antes debe uno estar conectado en Safari) Así que si queréis usarlo, hacedlo con cabeza. Resulta genial para dejar aquellas webs con notícias que nos interesan y por qué no, poner este humilde blog (por poner un ejemplo) como salvapantallas.

Si queréis comprar la aplicación os costará la friolera de 4 euros su licencia, pero la versión que podéis descargar grauitamente tiene limitados a 4 los sitios web a mostrar y algún opción más os aparecerá deshabilitada, con lo que podéis bajarosla y probarla sin problema para ver si luego os convence y decidís haceros con la versión completa.

Vía | "popurls.com":http://popurls.com Descarga | "Websaver":http://www.sandwichlab.net/websaver/

La irrupción de Google Chrome en el mundo de los navegadores puso en alerta a todos sus competidores, lo hemos podido comprobar en nuestro especial sobre el futuro de los navegadores, donde se ha convertido en el rival a batir o al menos, a imitar.

Por supuesto, en Apple no ha sentado nada bien, desde el comienzo, que un navegador basado en el mismo motor que Safari haya obtenido mejores resultados y sea elegido por los usuarios, antes que Safari, a la hora de navegar por la web.

Es por eso, que en Apple llevan trabajando desde hace un tiempo en mejorar Webkit, el motor que hay detrás de Safari y Chrome. Pretenden exprimirlo al máximo y mejorar su posición frente al navegador de Google.

Este nuevo Webkit2, como ha sido bautizado por los propios desarrolladores pretende optimizar el modelo de procesos separados que con tanto éxito implementa Chrome y obtener una ejecución multiproceso más eficiente. De esta manera se pretende crear procesos distintos para la ejecución del código Javascript, HTML, CSS,...

Otro de los objetivos de esta revisión es crear una nueva API no bloqueable basada en C, para ello se están utilizando algunas técnicas que mejoran el funcionamiento general de la aplicación y a su vez permiten ofrecer un nuevo conjunto de características a aquellos que usen el nuevo motor.

Algunas de esas nuevas características son el cambio en las notificaciones de las callbacks al cliente, revisión de la política de las callbacks del cliente, configuración en las políticas y la inyección de código. Esta última característica, que todavía no ha sido implementada, permitirá forzar el cargado del código en un proceso web cuando fallen los métodos normales.

Aunque la aproximación al modelo de multiproceso es distinta a la realizada por Chrome se espera obtener mejores resultados, de hecho ya se están realizando las primeras pruebas.

A pesar de ello, aún tendrán que pasar algunos meses hasta ver este nuevo motor en una versión estable de Safari, sobretodo porque supone utilizar una API totalmente reescrita y por lo tanto, bastante distinta a la que utiliza, actualmente, el navegador de Apple.

Como WebKit2 es un motor abierto, habrá que ver si Google también aprovecha estas nuevas características que se están incluyendo, aunque le supusiera cambiar la forma de trabajo multiproceso de su navegador.

Enlace | WebKit2