Philip Walton has an awesome deep dive into a new API the Chrome team has been working on to give you (the developer) control over how to respond when the browser unloads your tabs.

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.

Read full post.

My first comment is that you should read Philips post. It's incredible.

On mobile, Chrome can be pretty aggressive at backgrounding (freezing or discarding) the page to conserve resources when the user is not using it (for example, when you swap tabs or move from the Chrome app on Android), when the browser backgrounds your page as a developer you traditionally have no knowledge of when this happens so you can't easily persist state or even close down open resources and just as importantly when you're app is back re-hydrate the state cleanly. When developers have control they can make more informed choices, which also means that the browser can be more aggressive in conserving resources in the future without severely impacting user or developer experience.

Finally, the below diagram explains it all pretty darn well.

Pete LePage writes about important changes to Add to Homescreen in 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.

Read full post.

I had mixed feelings about this originally because so many people don't handle the beforeinstallprompt event it meant that all of a sudden the number of installs of Web APK's would drop quite significantly, but I think it's actually the right thing to do.

The goal is to reduce the number of annoying prompts happening on the web, and the last thing that we need in the industry is for a relatively large prompt to appear when we think the user might want to install a PWA, instead you now need to think about where and when you want to prompt for an install and you have to do it in response to a user-gesture.

The neat thing is that we (Chrome) are introducing more ambient ways of letting the user know that an experience is able to be installed, right now it's the small bottom bar that appears on the first load, and hopefully in the future we can explore more subtle ways of letting the user know they can take action.

A great overview of Pinterest's PWA

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.

Read full post.

This is a really great post show the benefits of building high-quality, fast and engaging sites. It's great to also see that the 'App' part of PWA, specifically 'Add to Homescreen' installability is being used by lots of users. Reading the broader post it's good to see that they were focusing on a great website experience, that is focus on fast loading sites that have repeatable and predictable performance via code-splitting to reduce the initial load and also good architecture that they can share across the team. Then once you have the base experience you can layer on features like push notifications for the users that want them.

By default Hugo doesn't serve .mjs files with the correct content type. In fact it wasn't until recently that hugo could serve more than one file extension per mime-type. It looks like with v0.43 this has been fixed.

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

Read full post.

The above code lets me serve mjs files for ES Modules with the correct mime-type (note modules need to be served with 'text/javascript'). This is only needed for local testing, hosting is another issue :)

I've got thoughts on the post I did yesterday about ES Modules

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.

Read full post.

One of the things that I wanted to try and articulate in the original article but I decided to pull out is that there is a huge amount of code in the Node ecosystem that is not really that specific to Node per se but has been tightly coupled with Node via Common JS and other very specific Node API's (Buffer, old URL etc etc) that it's going to take a lot of effort to pull ourselves up and thus the change be required to make ES Modules ubiquitous will be potentially quite painful, and until the ecosystem changes we are going to need to use a lot of conversion tools and bundlers to be able to cleanly share code across multiple platforms (web/server).

We are where we are, there wasn't an importing story on the web, we didn't have a heap of the primitives that Node introduced and are now what many would now consider de-facto platform requirements, so I hope that this is more of an acknowledgement of the situation than a criticism.

There is also a move to use '.mjs' as a file extension that is standard across both node and the web. I feel totally comfortable with this, however .msj is not a file that any infrastructure yet recognises as 'text/javascript' and I'm looking forward to this just being sorted so that it's automatically inferred by every web server on the planet, so I don't have to deploy yet more configuration changes to my serving infrastructure.

Lots of fun times ahead, I for one am looking forward to being able to bring a lot more functionality to the web.

In this post, I share a Rollup configuration I created to easily import npm modules into a front-end project using ES6 modules. I needed a way to use the 'get-urls' npm package in my ES6 project without resorting to CommonJS. My solution involves creating a wrapper file, using Rollup to bundle it with necessary plugins (node-resolve, commonjs, node-builtins, node-globals, closure-compiler-js), and then importing the resulting bundle into my HTML using a <script type="module"> tag. While the resulting bundle size is larger than ideal, this method allows me to use npm modules directly within my ES6 code. Read More

Tracy Lee from This Dot organised a rather neat live-stream that brought in many of the browser vendors to give an overview of what they are working on:

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

Read full post.

I thoroughly enjoyed the live stream and it was great to hear what everyone is up to. I also love the vision that Beaker Browser has for a distributed web, they've done a lot of work since the last time that we met.

I encourage you to watch the linked video, Edge has had a huge amount of updates including full Service Worker support, variable fonts and also they are introducing WebP. Mozilla have a huge focus on Web Assembly and developer tooling, Beaker is doing amazing things with dat: and distributed computing and Brave has been moving along alot on BAT.

I focused on the work that our team is doing at the moment, and it's broadly around Discovery, Speed and Reliability, UI Responsiveness, UX - Get stuff done, Security and Privacy. A little more concretely:

• Discovery - we really need to make it easier for developers to build sites with JS that render in headless services such as indexers and embedders. That means we need to focus on educating developers in how indexers work and how to test against them, and also how to build good solid SSR experiences.
• Speed and Reliability - All sites should have a TTI < 5s on 3g network on the Median device (a MotoG 4/5) and you should optimize your FID (first input delay). FID is a new metric, so it's important to understand that it's meant to represent how your users experience your site in the wild, where TTI has been hard to measure, FID should be easier. There is a polyfill here that you can use to test FID
• UI Responsiveness - We would like the web to be 60fps everywhere and make it easier for developers to achieve, so we are working on making ‘FLIP’ easier to understand, building out Houdini so we can give developers a lot more control over the rendering enging and finally trying to move as much work as possible 'off-main-thread' via things like img.decode and tools like comlink to making workers easier to use.
• UX - Get stuff done - We really want to change the way that we talk about new features coming to the platform, specifically we would like to make show where technology should be effectively used to improve users experiences to help them get their work done quickly with as little interruption as possible.
• Security and Privacy - I think Apple's Intelligent Tracking prevention is going to have a long term impact on the web and developers need to start to think more about building privacy supporting web experiences. If anything GDPR is making the web an 'interesting' experience in the EU.

Finally, it was humbling and heart-warming to hear that everyone wants to bring back Web Intents :)

Sam Thorogood from our team writes:

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.

Read full post.

I was amazed by this library, and I'm glad to see it getting a bit more attention. It was the first time I actually saw the Splash Screen on iOS work in the last 5 years and he generates them in a really neat way - he generates the image on the fly based on the exact screen size of the device and base64 encodes the image... it also fills in a lot of the rest of the gaps in the Safari Add To Homescreen story.

If you're building a PWA I would include it.

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.

Read full post.

This is a great introduction to variable fonts and it's a great playground to quickly see everything that you can vary in action. Adding multiple text lines looks like it will be landing soon.

Note: I believe this doesn't work yet in Firefox because they don't fully support Variable Fonts.

Patrick writes about 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.

Read full post.

This is not a million miles away from what we do internally, where we have a concept of 'snippets'. It's up to you how you manage it, but it's a great way of keeping track of what you did, but also shared across your team you get a nice picture of what your peers, managers and reports are also doing.

The model I like is to split each weekly summary into a 'what I did' and 'what intend to do this week'. It helps me reflect and plan at the same time.

Atishay Jain on CSS Tricks writes about an area close to my heart, linking:

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.

Read full post.

This was a great article that covers all the different types of hyperlinking available to apps and sites. I've been doing a lot of research into this space ever since Web Intents and the state of advanced linking on the web leaves a lot to be desired, imo.

One of the reasons why I love the web, is that behind a link is direct access to the resource, I don't know any other platform that can combine the link and the actual resource in the same way, but it could be soooo much more. The standard link provides essentially a VIEW intent that contains state (the url) and context (text between the anchors), and you can hack about with it custom protocols but we need to go a lot further.

• We need to expand the vocabulary to registerProtocolHandler to all more access to more native schemes
• Anything registered with the protocol handler needs to be system wide.
• We need to be able to have web-sites to be able to handle opening a range of content types and have pages available to be registered as a system file handler.
• We need to have higher order actions available to developers, VIEW is great, we need an agreed upon set of core actions such as PICK, SAVE, EDIT so that we can more effectively understand a site's or app's capabilities, and the ability to extend them with higher-order semantics. Android has this, Siri is getting it, both using 'Intents', the Web should have it too.

This is one of the reasons why I'm so excited about messaging abstractions such as Comlink that remove the burden of the postMessage madness and let you think about exposing function to other apps, and then once you expose function you need to more easily enable the discovery of that function... and that's what links enable.

Dan from Redfin has a great post about prioritising web speed:

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

Read full post.

It's not just us (Google) that can do this. I look at our team (Web and Chrome DevRel) being able to provide the tools and the guidance to help you start fast and then stay fast, but after that the industry has to recognise that performance is a feature and not an after thought.

I wrote in challenges for web developers that there are still many reasons that developers don't prioritize performance (tools, guidance and clear business incentives), I don't think Google asserting as written in Dan's article post is the answer for the long term health of the web, it needs to come from businesses seeing performance convert better.

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.

Read full post.

I don't have much to add, it's absolutely amazing. Check it out.

Dean Hume's been doing a lot great work with PWA's recently, and he's also been exploring a lot of the new platform API's, in this case the Generic Sensor API:

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.).

Read full post.

I spoke about the Generic Sensor API at Chrome Dev Summit 2016, so it's certainly taken a while for it to land in Chrome (I think it is still behind a flag) and it looks like it has landed in Edge first. The Ambient light sensor is one of many API's that is built on top of Generic Sensors — there are more such as gyro and magnetometers — and it allows you to get information about the ambient light levels around the user opening up use-cases such as automatic adjustment of brightness or even offering the user to switch to a dark-mode theme. It's certainly going to be interesting to see what the base Generic Sensor API will bring to web experiences.

Jonathan Fulton, Videoblocks:

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

Read full post.

This is an amazing article that gives a really great overview of a relatively standard stack that is designed to scale many web apps. It also shows why a lot of developers also like Platform as a Service tools like Heroku, Firebase or AppEngine that can abstract a lot of the complexity at the expense of cost.

Eric Bidelman on Google Developer's Web updates, writes:

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.

Read full post.

I'm interested to see how this lands. I worry that developers won't care about this, or that they will be pressured. As I said on Twitter, I worry about the incentives and we need to combine the fact that this feature will let developers control a large number of the available features that either take up memory, can slow the page down, or inadvertently leak user-privacy to third parties embeds, with things that developers can sell in to their business. One example could be that if the Play Store were ever to list PWA's then they could come with a set of policies automatically applied when the app is launched, and you as a developer would agree to this for the benefit of being in the store.

I'm excited to see what happens with this API, and I'm keen to see it adopted, even if it's only used by developers to ensure that their teams don't regress.

Jeff Posnick writes, wrt to Workbox

A common source of unexpectedly high quota usage is due to runtime caching of opaque responses, which is to say, cross-origin responses to requests made without CORS enabled.

Browsers automatically inflate the quota impact of those opaque responses as a security consideration. In Chrome, for instance, even an opaque response of a few kilobytes will end up contributing around 7 megabytes towards your quota usage.

Read full post.

Service Workers are an amazing and integral part of the web ecosystem, but there are still quite a few gotchas - and this is one of them that can bite you if you don't know this ahead of time.

It's great to see tools like Workbox being able to handle this and inform you so that you know what happens.

Sam Thorogood on Dev.to writes,

Why did I write this post? Emscripten is a wonderful tool, but it has a long history (for asm.js), and isn't perfect. I think it errs too much on the side of "magic", and many posts rave about how it's so easy to EM_ASM_ or use binding-fu, but this all comes at a cost, and can introduce huge amounts of inadvertent overhead—think copying huge memory buffers around because we're trying to make them immutable or easily exposed.

Every language that is being compiled to Web Assembly needs a runtime—whether it be Go, or Rust, or C/C++ as we have here. I don't believe that we'll ever really be able to directly import Web Assembly via ES2015 modules, at least not without changes on the JS side. But it behooves us to write the smallest one we possibly can.

Read full post.

I think we all see the potential of wasm, bit for many of us a lot of the other platforms that are now able to come to the web are completely alien to us, and we really need to learn those tools, improve the wasm developer experience and imo offer prebuilt libraries that 'traditional web devs' can just use.

Mustafa for Google Chrome, on Dev-Channel writes,

The Gestalt principles are a series of laws that are used to explain why human beings naturally find organized patterns in objects they see around them. The goal with the principles was to explain why we group objects in some ways but not others.

There are many different principles, but here I am going to look at the ones that effect grouping, these are; proximity, similarity, common fate, continuity, closure, and prägnanz.

Read full post.

Share Target API is now in Chrome breaking down one of the last silos of native platforms Read More