Yeah, ok, it's a touch bold to talk about something being the thing of the year as early as January, but the potential of the web streams API has gotten me all excited.

Streams can be used to do fun things like turn clouds to butts, transcode MPEG to GIF, but most importantly, they can be combined with service workers to become the fastest way to serve content.

I just had my responsive images epiphany and I'm writing it all down before I forget everything. This is what I know…

When I told my colleague Matt Gaunt I was thinking of writing a piece on microtask queueing and execution within the browser's event loop, he said "I'll be honest with you Jake, I'm not going to read that". Well, I've written it anyway, so we're all going to sit here and enjoy it, ok?

Recently, ppk claimed the web is going too fast in the wrong direction, and asked for a year's moratorium on web features. I was so angry I ran straight to a dictionary to find out what "moratorium" meant. Turns out it means "suspension".

I got a bit snarky about it on Twitter, which isn't really fair, so here's a more considered response:

There's been some confusion around the new fetch API recently. Let's clear things up.

ServiceWorker brief overview gives you control over caching and how requests are handled. It doesn't give you patterns, you create them yourself. Let's look at a few!

ES6 gives us a new way to iterate, and it's already supported in stable releases of Firefox, Chrome, & Opera. Here it is…

With ServiceWorkers you can control requests to any page on your origin, and any of the subresource requests made by those pages. This is powerful stuff, and I'm curious to know what security measure you think is appropriate…

The implementation for ServiceWorker has been landing in Chrome Canary over the past few months, and there's now enough of it to do some cool shit!