A quick dive in to how to use Lighthouse to try and understand how users in a country might experience the web.

Ruth John se mudó a Chrome OS (temporalmente):

The first thing, and possibly the thing with the least amount of up to date information out there, was enabling Crostini. This runs Linux in a container on the Chromebook, something you pretty much want straight away after spending 15 minutes on it.

I have the most recent Pixel, the 256GB version. Here’s what you do.

• Go to settings.
• Click on the hamburger menu (top left) - right at the bottom it says ‘About Chrome OS’
• Open this and there’s an option to put your machine into dev mode
• It’ll restart and you’ll be in dev mode - this is much like running Canary over Chrome and possibly turning on a couple of flags. It may crash, but what the hell you’ll have Linux capabilities ��
• Now you can go back into Settings and in regular settings there’s a ‘Linux apps’ option. Turn this on. It’ll install Linux. Once this is complete you’ll have a terminal open for you. Perfect

Leer la publicación completa.

Ruth tiene un gran relato de mudarse a Chrome OS porque su máquina principal se rompió.

Me mudé a Chrome OS a tiempo completo hace 4 meses (antes de Google I / O) y solo me mudé a la Mac porque rompí mi PixelBook (ahora corregido).

Para mí es una de las mejores máquinas de desarrollo web que existe hoy en día. Es el único dispositivo con el que puedo probar el “verdadero móvil”: puede instalar Chrome en dispositivos móviles en él, Firefox Mobile, el navegador Samsung, Brave, etc. a través de la plataforma ARC. Crostini también cambia las reglas del juego para Chrome OS, ya que aporta gran parte del ecosistema de aplicaciones de Linux al sistema operativo Chrome y realmente comienza a llenar una gran brecha de aplicaciones para mí en Chrome OS; Tengo Firefox, vim, git, VS Code, Node, npm, todas mis herramientas de compilación, GIMP e Inkscape … Eso no quiere decir que haya sido perfecto, Crostini podría ser más rápido, aún no está acelerado por GPU y podría estar más integrado con Filemanager, etc., y, finalmente, el PixelBook realmente necesita más puertos físicos; puedo adjuntar dos pantallas 4k, pero no puedo cargar al mismo tiempo.

Creo que el resumen de Ruth también es bastante preciso, el PixelBook es una máquina costosa, pero estoy muy emocionado de ver que esto llegue a más y más dispositivos (especialmente a precios mucho más bajos).

Would I pay full price for it? I’m not sure I would pay full price for anything on the market right now. Point me in the direction of a system that will run my graphics software and makes a good dev machine (with minimal setup) and lasts more than 18 months, point me in the direction of a worthy investment and I will pay the money.

Sip.

PWA. Aplicaciones web progresivas. Frances Berriman y Alex Russell acuñaron el término “aplicaciones web progresivas” en 2015 con lo que creo que es una publicación seminal “Aplicaciones web progresivas: escapando pestañas sin perder nuestro alma”. 3 años después, hemos recorrido un largo camino. De una colección suelta de tecnologías: Trabajador de servicio, Manifiesto, Agregar a pantalla de inicio, Web Push, que originalmente solo se implementaron en un motor de navegador, a una marca que comenzó a extenderse a toda la industria con empresas y desarrolladores, y todas las principales proveedores de navegador implementando la mayoría de la pila ‘PWA’.

Mustafa escribe:

Tooling is complicated, we are a tooling focused industry, and they change so much. I have used maybe rough eight different tools, from Photoshop to Sketch. That’s before we add prototyping tools to the mix. This may be something we just have to accept. After all, type standards only really started to settle in the 90s, and typography is a 500-year-old discipline.

Designers are still finding it difficult to prove the importance of the process. I think this is something that we have to take on board: to learn how to educate and not just expect everyone to trust us by default. That takes time — perhaps using scenario-based design or design workshops like a design sprint would help. Getting non-designers to observe users while using a prototype they created is one of the best experiences I have seen in this field.

Cross-browser support is lacking crucial features. Designers need to understand developer tooling, to better scope out what is possible. I think using paired programming or the design process described above can help.

Responsive design is still challenging. I think this is in part due to the tools we use; I would love Chrome Design Tools that would help turn the browser into a creative tool. This space is where I think the next evolutionary step for site and web app creation is at. Mozilla is doing some fantastic work in this space, with their layout and shapes tooling.

All in all the challenges that we face seem to be all the age-old ones. Process, tools, and respect.

Leer la publicación completa.

Me pareció una publicación muy interesante que también complementa una publicación que escribí sobre desafíos para desarrolladores web. No es sorprendente que la compatibilidad con el navegador sea un problema, pero lo que todavía preocupa es que construir para IE11 todavía es algo que está frenando a la industria. Del mismo modo, Mustafa señala que todavía existe un problema con las herramientas en torno al diseño receptivo y el énfasis en una sola solución receptiva siempre conduce a lo siguiente (que está en la publicación de Mustafa):

Designing once and using everywhere is still hard to reach ambition.

Este es un problema con el que creo que todos aún luchamos. Por un lado, queremos que todos creen una solución receptiva que pueda servir a todos en cada factor de forma de dispositivo; por otro lado, el contexto del usuario es importante y, a menudo, el usuario solo estará dispuesto a realizar determinadas acciones en determinados momentos; Vemos esto mucho en la industria del comercio minorista y el comercio: las personas navegarán en dispositivos móviles y las completarán en computadoras de escritorio, y la pregunta que se tiene es: ¿se atiende más a este modelo multimodal o se crea una experiencia consistente en todos los dispositivos? … sospeche que la respuesta es ‘depende’, pero de cualquier forma es un problema difícil para todos, desde equipos de productos hasta equipos de ingeniería.

Philip Walton tiene una profunda inmersión en una nueva API en la que el equipo de Chrome ha estado trabajando para darle a usted (el desarrollador) el control sobre cómo responder cuando el navegador descarga sus pestañas.

Application lifecycle is a key way that modern operating systems manage resources. On Android, iOS, and recent Windows versions, apps can be started and stopped at any time by the OS. This allows these platforms to streamline and reallocate resources where they best benefit the user.

On the web, there has historically been no such lifecycle, and apps can be kept alive indefinitely. With large numbers of web pages running, critical system resources such as memory, CPU, battery, and network can be oversubscribed, leading to a bad end-user experience.

While the web platform has long had events that related to lifecycle states — like load, unload, and visibilitychange — these events only allow developers to respond to user-initiated lifecycle state changes. For the web to work reliably on low-powered devices (and be more resource conscious in general on all platforms) browsers need a way to proactively reclaim and re-allocate system resources.

In fact, browsers today already do take active measures to conserve resources for pages in background tabs, and many browsers (especially Chrome) would like to do a lot more of this — to lessen their overall resource footprint.

The problem is developers currently have no way to prepare for these types of system-initiated interventions or even know that they’re happening. This means browsers need to be conservative or risk breaking web pages.

The Page Lifecycle API attempts to solve this problem by:

• Introducing and standardizing the concept of lifecycle states on the web.
• Defining new, system-initiated states that allow browsers to limit the resources that can be consumed by hidden or inactive tabs.
• Creating new APIs and events that allow web developers to respond to transitions to and from these new system-initiated states.
• This solution provides the predictability web developers need to build applications resilient to system interventions, and it allows browsers to more aggressively optimize system resources, ultimately benefiting all web users.

The rest of this post will introduce the new Page Lifecycle features shipping in Chrome 68 and explore how they relate to all the existing web platform states and events. It will also give recommendations and best-practices for the types of work developers should (and should not) be doing in each state.

Leer publicación completa.

Mi primer comentario es que deberías leer la publicación de Philips. Es increíble.

En dispositivos móviles, Chrome puede ser bastante agresivo al generar fondos (congelar o descartar) la página para conservar recursos cuando el usuario no la está usando (por ejemplo, cuando intercambias pestañas o te mueves desde la aplicación Chrome en Android), cuando el navegador Como desarrollador, usted tradicionalmente no tiene conocimiento de cuándo sucede esto, por lo que no puede mantener fácilmente el estado o incluso cerrar los recursos abiertos, y lo que es más importante cuando su aplicación vuelve a hidratar el estado limpiamente. Cuando los desarrolladores tienen el control, pueden tomar decisiones más informadas, lo que también significa que el navegador puede ser más agresivo en la conservación de recursos en el futuro sin afectar severamente la experiencia del usuario o desarrollador.

Finalmente, el diagrama a continuación explica todo bastante bien.

Pete LePage escribe sobre cambios importantes para Agregar a la pantalla de inicio en Chrome

Add to Home Screen changes

If your site meets the add to home screen criteria, Chrome will no longer show the add to home screen banner. Instead, you’re in control over when and how to prompt the user.

To prompt the user, listen for the beforeinstallprompt event, then, save the event and add a button or other UI element to your app to indicate it can be installed.

Leer publicación completa.

Tenía sentimientos encontrados sobre esto porque mucha gente no maneja el evento beforeinstallprompt, significaba que, de repente, la cantidad de instalaciones de Web APK caería significativamente, pero creo que es lo correcto.

El objetivo es reducir el número de mensajes molestos que suceden en la web, y lo último que necesitamos en la industria es que aparezca un mensaje relativamente grande cuando creemos que el usuario podría querer instalar un PWA, en su lugar, ahora necesita piense en dónde y cuándo ** desea solicitar una instalación y debe hacerlo en respuesta a un gesto del usuario.

Lo bueno es que nosotros (Chrome) estamos introduciendo formas más ambientadas de dejar que el usuario sepa que se puede instalar una experiencia, ahora es la pequeña barra inferior que aparece en la primera carga, y con suerte en el futuro podemos explorar formas más sutiles de dejar que el usuario sepa que puede tomar medidas.

Una gran visión general de PWA de Pinterest

The verdict

Now for the part you’ve all been waiting for: the numbers. Weekly active users on mobile web have increased 103 percent year-over-year overall, with a 156 percent increase in Brazil and 312 percent increase in India. On the engagement side, session length increased by 296 percent, the number of Pins seen increased by 401 percent and people were 295 percent more likely to save a Pin to a board. Those are amazing in and of themselves, but the growth front is where things really shined. Logins increased by 370 percent and new signups increased by 843 percent year-over-year. Since we shipped the new experience, mobile web has become the top platform for new signups. And for fun, in less than 6 months since fully shipping, we already have 800 thousand weekly users using our PWA like a native app (from their homescreen).

Looking back over one full year since we started rebuilding our mobile web, we’re so proud of the experience we’ve created for our users. Not only is it significantly faster, it’s also our first platform to support right-to-left languages and “night mode.” Investing in a full-featured PWA has exceeded our expectations. And we’re just getting started.

Leer la publicación completa.

Esta es una muy buena publicación muestra los beneficios de la construcción de sitios de alta calidad, rápidos y atractivos. También es genial ver que la parte de ‘Aplicación’ de PWA, específicamente la instabilidad de ‘Añadir a pantalla de inicio’ está siendo utilizada por muchos usuarios. Al leer una publicación más amplia, es bueno ver que se centraron en una gran experiencia en sitios web, que se centra en sitios de carga rápida que tienen un rendimiento repetible y predecible mediante división de código para reducir la carga inicial y también una buena arquitectura que pueden compartir a través del equipo. Luego, una vez que tenga la experiencia básica, puede aplicar capas a características como notificaciones automáticas para los usuarios que las deseen.

Por defecto, Hugo no sirve archivos .mjs con el tipo de contenido correcto. De hecho, no fue hasta hace poco que hugo podía servir más de una extensión de archivo por tipo de mimo. Parece que con v0.43 esto ha sido arreglado.

[mediaTypes] [mediaTypes.“text/javascript”] suffixes = [“js”, “mjs”]

Leer la publicación completa.

El código anterior me permite servir archivos mjs para los módulos ES con el tipo de mime correcto (los módulos de notas deben ser servidos con ‘text / javascript’). Esto solo es necesario para las pruebas locales, el alojamiento es otro problema :)

Tengo pensamientos sobre la publicación que hice ayer sobre los módulos ES

I needed a quick way import a simple module get-urls into my project. The module is well tested and it does what I needed … ignore the fact that it’s pretty easy to implement in a couple of lines of JavaScript. The problem I had is that my project is built in ES6, uses modules and I didn’t want to have to bundle up using CommonJS (require).

I couldn’t find a lot of guidance on what to do here, so I went to experiement and this solution is the solution I came across:

1. Create a file that imports the npm module I needed. module.exports = require(‘get-urls’); This module will be what’s converted to ES6 style.
2. Create a rollup config that
   1. Imports the node globals, and builtins.
   2. Resolves all npm modules required for my usage of this module.
   3. Pass the results through the commonjs plugin so that it’s now in JavaScript module format.
   4. Compress the output, because it’s huge :
3. Include the bundled file in your project and rejoice.

Leer la publicación completa.

Una de las cosas que quería probar y articular en el artículo original pero decidí retirar es que hay una gran cantidad de código en el ecosistema del Nodo que no es tan específico para el Nodo per se, pero se ha unido estrechamente con Nodo a través de Common JS y otras API de Nodo muy específicas (Buffer, antigua URL, etc.) que requerirá un gran esfuerzo para elevarnos y, por lo tanto, el cambio necesario para hacer que los Módulos ES ubicuos sea potencialmente muy doloroso, y hasta los cambios en el ecosistema vamos a necesitar usar muchas herramientas de conversión y paquetes para poder compartir código de manera limpia en múltiples plataformas (web / servidor).

Estamos donde estamos, no había una historia importadora en la web, no teníamos un montón de las primitivas que presentó Node y ahora son lo que muchos considerarían como requisitos de plataforma de facto, así que espero que esto sea así. más un reconocimiento de la situación que una crítica.

También hay un movimiento para usar ‘.mjs’ como una extensión de archivo que es estándar tanto en el nodo como en la web. Me siento totalmente cómodo con esto, sin embargo .msj no es un archivo que ninguna infraestructura reconozca como ‘text / javascript’ y estoy esperando que esto sea ordenado para que sea inferido automáticamente por cada servidor web del planeta, por lo que No tengo que implementar aún más cambios de configuración en mi infraestructura de servicio.

Muchos tiempos de diversión por delante, por mi parte, estoy deseando poder traer mucha más funcionalidad a la web.

He estado trabajando en una forma de facilitar el envío de contenido a mi sitio estático y ha sido un pequeño ejercicio divertido que compartiré más en otra publicación. En esta publicación, quiero compartir la configuración rollup que utilicé para importar casi cualquier módulo npm en un proyecto frontend utilizando módulos de JavaScript. Necesitaba una forma rápida de importar un módulo simple get-urls en mi proyecto. El módulo está bien probado y hace lo que necesitaba … ignore el hecho de que es bastante fácil de implementar en un par de líneas de JavaScript.

Tracy Lee de This Dot organizó una transmisión en vivo bastante ingeniosa que atrajo a muchos de los proveedores de navegadores para ofrecer una visión general de lo que están trabajando:

Browser representatives from Brave, Beaker, Edge, Chrome, & Mozilla get together to talk about recent updates and the state of browsers.

Featured Speakers:

• Brendan Eich -  Creator of Javascript, Co-founder & CEO at Brave Software
• Paul Frazee - Works on Beaker Browser
• Matthew Claypotch - Developer Advocate at Mozilla
• Paul Kinlan - Senior Developer Advocate at Google
• Patrick Kettner - Edge at Microsoft
• Amal Hussein - Senior Open Web Engineer at Bocoup
• Tracy Lee - GDE, RxJs Core Team, This Dot Co-founder

Leer la publicación completa.

Disfruté mucho de la transmisión en vivo y fue genial escuchar lo que todos hacen. También me encanta la visión que tiene el navegador Beaker para una web distribuida, han hecho mucho trabajo desde la última vez que nos conocimos.

Los animo a que miren el video vinculado, Edge ha tenido una gran cantidad de actualizaciones que incluyen soporte técnico completo para trabajadores, fuentes variables y también están presentando WebP. Mozilla tiene un gran enfoque en el ensamblado web y herramientas de desarrollo, Beaker está haciendo cosas increíbles con dat: y la informática distribuida y Brave se ha estado moviendo mucho en BAT.

Me centré en el trabajo que nuestro equipo está haciendo en este momento, y en general se trata de Descubrimiento, Velocidad y Confiabilidad, Receptividad de UI, UX - Hacer las cosas, Seguridad y Privacidad. Un poco más concretamente:

• Descubrimiento: realmente necesitamos facilitar a los desarrolladores la creación de sitios con JS que se procesen en servicios decapitados, como indexadores y embedders. Eso significa que debemos centrarnos en educar a los desarrolladores sobre cómo funcionan los indexadores y cómo probarlos, y también cómo crear buenas experiencias sólidas de SSR. * Velocidad y confiabilidad: todos los sitios deben tener un TTI <5s en una red de 3g en el dispositivo Median (un MotoG ⁴⁄₅) y debe optimizar su FID (primer retraso de entrada). FID es una nueva métrica, por lo que es importante comprender que pretende representar cómo los usuarios experimentan su sitio en la naturaleza, donde TTI ha sido difícil de medir, FID debería ser más fácil. Hay un polyfill aquí que puede usar para probar FID * Receptividad de la interfaz de usuario: nos gustaría que la web sea de 60 fps en todas partes y que sea más fácil para los desarrolladores lograrlo, por lo que estamos trabajando para hacer & # x2018; FLIP & # x2019; más fácil de entender, construyendo Houdini para que podamos darle a los desarrolladores un mayor control sobre el enging de renderizado y finalmente tratando de mover tanto trabajo como sea posible ‘fuera del hilo principal’ a través de cosas como img.decode y herramientas como comlink para hacer que los trabajadores más fácil de usar. * UX - Hacer las cosas - Realmente queremos cambiar la forma en que hablamos sobre las nuevas funciones que llegan a la plataforma, específicamente nos gustaría hacer un show donde la tecnología se debe utilizar de manera efectiva para mejorar las experiencias de los usuarios para ayudarles a realizar su trabajo rápidamente con la menor interrupción posible. * Seguridad y privacidad: creo que la prevención de seguimiento inteligente de Apple tendrá un impacto a largo plazo en la web y los desarrolladores deben comenzar a pensar más sobre la creación de privacidad que respalde las experiencias web. En todo caso, GDPR está convirtiendo la web en una experiencia “interesante” en la UE.

Finalmente, fue humillante y reconfortante escuchar que todos quieren traer Web Intents :)

Sam Thorogood de nuestro equipo escribe:

You’ve designed a webapp, built its code and service worker, and finally added the Web App Manifest to describe how it should behave when ‘installed’ on a user’s device. This includes things like high-resolution icons to use for e.g. a mobile phone’s launcher or app switcher, or how your webapp should start when opened from the user’s home screen.

And while many browsers will respect the Web App Manifest, not every browser will load or respect every value you specify. Enter PWACompat, a library that takes your Web App Manifest and automatically inserts relevant meta or link tags for icons of different sizes, the favicon, startup mode, colors etc.

Leer publicación completa.

Me sorprendió esta biblioteca y me alegra ver que recibe un poco más de atención. Fue la primera vez que vi la pantalla Splash en iOS en los últimos 5 años y él los genera de una manera muy clara: genera la imagen sobre la marcha basándose en el tamaño de pantalla exacto del dispositivo y base64 codifica la imagen … también llena una gran cantidad del resto de las lagunas en la historia de Safari Add To Homescreen.

Si estás construyendo un PWA lo incluiría.

Font Playground is built for three groups of audiences.

The first group of audience is typographers and designers, who would like to play with fonts that are built with the latest font technologies, such as variable font. It is a playground to fully explore what these new font technologies can offer and how they can be beneficial to your creative workflow.

The second group of audience is me, as a Type Tool’s UI/UX designer. This is a playground for me to test UI experiments for variable fonts and other new upcoming font technologies. One of the key points to the success of new font technology is adoption by design tools, and furthermore, designers. How can design tool present variable fonts in a way that is useful but not too complicated to handle? I hope to find the answers with this playground.

The third group of audience is the type designers and foundries. This is a place to showcase the work-in-progress, cutting-edge font creations. It is a playground to see how fonts are being presented and used in future design tools. How fonts are used can also inform how fonts are made, and what standard should be defined.

Leer la publicación completa.

Esta es una gran introducción a las fuentes variables y es un excelente campo de juego para ver rápidamente todo lo que puedes variar en acción. Al agregar varias líneas de texto, parece que pronto aterrizará.

Nota: Creo que esto aún no funciona en Firefox porque no admite fuentes de variable.

Patrick escribe sobre Did.txt

Time flies by when you’re learning how to code. Its super important to take a second every once in a while to simple write down what you did during the past mental sprint. Writing down what you learned solidifies the knowledge.

Leer la publicación completa.

Esto no está a un millón de millas de lo que hacemos internamente, donde tenemos un concepto de ‘fragmentos’. Depende de usted cómo lo gestione, pero es una gran manera de hacer un seguimiento de lo que hizo, pero también se comparte con su equipo para obtener una buena imagen de lo que sus compañeros, gerentes e informes también están haciendo.

El modelo que me gusta es dividir cada resumen semanal en “lo que hice” y “qué tengo intención de hacer esta semana”. Me ayuda a reflexionar y planificar al mismo tiempo.

Atishay Jain en CSS Tricks escribe sobre un área cercana a mi corazón, vinculando:

Hyperlinks are the oldest and the most popular feature of the web. The word hypertext (which is the ht in http/s) means text having hyperlinks. The ability to link to other people’s hypertext made the web, a web — a set of connected pages. This fundamental feature has made the web a very powerful platform and it is obvious that the world of apps needs this feature. All modern platforms support a way for apps to register a URI (custom protocol) and also have universal links (handling web links in an app).

Let’s see why we’d want to take advantage of this feature and how to do it.

Leer publicación completa.

Este fue un gran artículo que cubre todos los diferentes tipos de hipervínculos disponibles para aplicaciones y sitios. He estado investigando mucho sobre este espacio desde que los Intents Web y el estado de los enlaces avanzados en la web dejan mucho que desear, imo.

Una de las razones por las que amo la web es que detrás de un enlace está el acceso directo al recurso, no conozco ninguna otra plataforma que pueda combinar el enlace y el recurso real de la misma manera, pero podría ser tan mucho Más. El enlace estándar proporciona esencialmente un intento de VISTA que contiene el estado (la url) y el contexto (texto entre los anclajes), y puede hackear con él los protocolos personalizados, pero tenemos que ir mucho más allá.

• Necesitamos expandir el vocabulario a registerProtocolHandler para tener más acceso a más esquemas nativos * Todo lo que se registra con el manejador de protocolo necesita estar en todo el sistema. * Necesitamos poder tener sitios web para poder manejar la apertura de una variedad de tipos de contenido y tener páginas disponibles para registrar como manejador de archivos del sistema. * Necesitamos tener acciones de mayor orden disponibles para los desarrolladores, VIEW es excelente, necesitamos un conjunto acordado de acciones centrales como PICK, SAVE, EDIT para que podamos entender más efectivamente las capacidades de un sitio o de una aplicación, y la capacidad de extender ellos con semántica de orden superior. Android tiene esto, Siri lo está obteniendo, ambos usando ‘Intents’, la Web debería tenerlo también.

Esta es una de las razones por las que estoy tan entusiasmado con las abstracciones de mensajes como Comlink que eliminan la carga de la locura postMessage y le permiten pensar en exponer la función a otra aplicaciones, y luego una vez que expone la función necesita habilitar más fácilmente el descubrimiento de esa función … y eso es lo que permiten los enlaces.

Dan de Redfin tiene una excelente publicación sobre cómo priorizar la velocidad de la web:

JavaScript Is the Web’s CO2

As a web developer, I find that most problems can be solved with just a little more JavaScript. Without someone or something to force the industry to cut back, web developers will continue to make web sites that only load “fast enough” via wifi on a fast laptop.

The browser vendors can’t save us. Every time they make the web faster, web developers “take advantage” of the change by using more JavaScript.

Our industry needs Google to take a principled stand, to significantly prioritize fast-loading sites over slow-loading sites

Leer la publicación completa.

No somos solo nosotros (Google) los que podemos hacer esto. Veo a nuestro equipo (Web y Chrome DevRel) pudiendo proporcionar las herramientas y la guía para ayudarlo a comenzar rápido y luego mantenerse rápido, pero después de eso, la industria debe reconocer que el rendimiento es una característica y no una reflexión.

Escribí en desafíos para desarrolladores web que todavía hay muchas razones por las que los desarrolladores no priorizan el rendimiento (herramientas, orientación e incentivos comerciales claros) ), No creo que afirmar que Google, tal como está escrito en la publicación del artículo de Dan, es la respuesta para la salud a largo plazo de la web, debe venir de las empresas que ven mejor el rendimiento.

This project is a musical experience built with WebGL and WebVR.

Inspired by the music track, we created an ever-changing environment composed of various geometrical shapes. These were generated procedurally in Houdini and exported to Three.js.

All visual elements are randomized differently on each viewing.

Leer la publicación completa.

No tengo mucho que agregar, es absolutamente increíble. Echale un vistazo.

Dean Hume ha estado haciendo un gran trabajo con PWA recientemente, y también ha estado explorando muchas de las nuevas API de la plataforma, en este caso, la API de sensor genérico:

The Ambient Light Sensor API provides developers with the means to determine ambient light levels as detected by the device’s main light detector. This information is available to developers in terms of lux units. If you are building a Progressive Web App and you want to style it differently depending on the light levels in the room, then this could be the feature for you. There are a number of use cases for this feature, such as a web application that provides input for a smart home system to control lighting, a “Kindle” style reading app, or even a web app that calculates settings for a camera with manual controls (aperture, shutter speed, ISO, etc.).

Leer la publicación completa.

Hablé sobre la API de Generic Sensor en Chrome Dev Summit 2016, por lo que definitivamente tardo un poco en aterrizar en Chrome (creo que todavía está detrás de una bandera) y parece que ha aterrizado en Edge primero. El sensor de luz ambiental es una de las muchas API que está construida sobre sensores genéricos y mdash; hay más como giroscopios y magnetómetros y mdash; y le permite obtener información sobre los niveles de luz ambiental alrededor del usuario abriendo casos de uso tales como el ajuste automático del brillo o incluso ofreciendo al usuario cambiar a un tema de modo oscuro. Sin duda va a ser interesante ver qué aportará la base Generic Sensor API a las experiencias web.

Jonathan Fulton, Videobloques:

The basic architecture concepts I wish I knew when I was getting started as a web developer

Leer la publicación completa.

Este es un artículo increíble que ofrece una gran visión general de una pila relativamente estándar que está diseñada para escalar muchas aplicaciones web. También muestra por qué muchos desarrolladores también les gusta las herramientas de Plataforma como servicio, como Heroku, Firebase o App Engine, que pueden abstraer gran parte de la complejidad a costa del costo.

Eric Bidelman en las actualizaciones de la web del desarrollador de Google, escribe:

Building for the web is a rocky adventure. It’s hard enough to build a top-notch web app that nails performance and uses all the latest best practices. It’s even harder to keep that experience great over time. As your project evolves, developers come on board, new features land, and the codebase grows. That Great Experience ™ you once achieved may begin to deteriorate and UX starts to suffer! Feature Policy is designed to keep you on track.

With Feature Policy, you opt-in to a set of “policies” for the browser to enforce on specific features used throughout your site. These policies restrict what APIs the site can access or modify the browser’s default behavior for certain features.

Here are examples of things you can do with Feature Policy:

• Change the default behavior of autoplay on mobile and third party videos.
• Restrict a site from using sensitive APIs like camera or microphone.
• Allow iframes to use the fullscreen API.
• Block the use of outdated APIs like synchronous XHR and document.write().
• Ensure images are sized properly (e.g. prevent layout thrashing) and are not too big for the viewport (e.g. waste user’s bandwidth).

Policies are a contract between developer and browser. They inform the browser about what the developer’s intent is and thus, help keep us honest when our app tries to go off the rails and do something bad. If the site or embedded third-party content attempts to violate any of the developer’s preselected rules, the browser overrides the behavior with better UX or blocks the API altogether.

Leer publicación completa.

Estoy interesado en ver cómo aterriza. Me preocupa que a los desarrolladores no les importe esto, o que sean presionados. Como dije en Twitter, me preocupan los incentivos y tenemos que combinar el hecho de que esta característica permitirá a los desarrolladores controlar una gran cantidad de funciones disponibles que ya sea que tome memoria, puede ralentizar la página o inadvertidamente se escape la privacidad del usuario a las incrustaciones de terceros, con cosas que los desarrolladores pueden vender a su negocio. Un ejemplo podría ser que ** si ** la Play Store publicara alguna vez PWA, entonces podrían venir con un conjunto de políticas aplicadas automáticamente cuando se lanza la aplicación, y usted como desarrollador estaría de acuerdo con esto en beneficio de estar en la tienda.

Estoy emocionado de ver qué sucede con esta API, y estoy ansioso por verla adoptada, incluso si solo la utilizan los desarrolladores para garantizar que sus equipos no sufran regresiones.