Hello.

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 EMASM 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

Use onappinstalled to detect when a progressive web app is installed.

A simple bookmarklet that will performance trace the current page and open in an hosted devtools instance

A simple docker container that can host an instance of puppeteer and a custom app.

A curl-like utitly that runs JavaScript

CSP nonce values can help you securely run inline content on you site. But it can be hard to get it working with Service Workers... until now.

If we are to build HTML in Workers then we need some 'DOM' in them.

Templating libraries needn't be so hard

Summary of the challenges that I beleive we developers face every day.

This article is over a year late. It was stuck in my drafts for a long time, yet I think the idea is something that we need to solve into 2018. It also turns out that other issues have arisen in the last year that make it a bit more relevant. I was in Indonesia earlier in 2016 idly chatting with developers and it came up in conversation that the web is screwed (they were the literal words).

What is this? This is my Software Engineering final year project for University from about 2003. I used to be work in the Fraud Detection industry (mortgage and credit card fraud) and this project was to solve a problem that I had found in the telecoms industry: fraudulent phone calls. It was impossible (for me) to get phone records from telecoms companies, so I had to build a tool that would model fraudulent calls and normal call patterns, I then had to build a tool that would detect calls that were fradulent from all of the call records.