• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

JavaScript

Don’t space walk without a tether, get a worker

February 29, 2016 Leave a Comment


I sit here on Oscar night, wearing my “science the shit out of this” Martian t-shirt, reflecting on how often we enjoy a tense moment in a space movie where we hope that an actor doesn’t get shifted off into space.

You can’t help but gasp a little for air as you think about the awful thought of slowly moving in the wrong direction in space, without a thrust ability to change momentum and get you going anywhere but slowly to your doom.

You see it coming. “REMEMBER THE TETHER!” you cry at the screen, or you look for something that will harm said flimsy chord.

I have had a similar feeling when shipping production changes that effected cache headers. You have tested and tested, but you fear a bug that sets a cache header too far into the future, a bug that has your client without a tether. The client doesn’t think it has to phone home to see if there is a new version of the content, and you have no way to fix this after the fact. ET can’t phone home.

Service Workers give you a tether

One of the great features of service workers is how it gives you power over the full installation experience and running of the web applications in your domains. You get to aggressively cache the pieces of content that can be cached, yet you also have the browser talking back to you outside of the tab to nicely swap in new versions of the service worker that controls the lifecycle, and the cache itself. The platform gives you rich programmatic power, and tools are popping up to help make common cases simpler (e.g. sw-toolbox is battle tested in production by folks such as Flipkart).

One of the important implementation details of service workers is the lifecycle and how often the browser will look to see if a new one is available (all it takes is One Byte).

The service worker is precious. When you update it you want your users to get that update in relatively short order. But blimey, what if you somehow messed up and set a far future header on this puppy? No worries, the tether is firmly in place.

As you can read in the spec you can set a cache header if browsers are hammering you for an updated worker all the time (no need to prematurely optimize of course, this is all done out of band):

“The user agent obeys Cache-Control header’s max-age value in the network layer to determine if it should bypass the browser cache”

But, the max-age can never be more than a day (or as our APIs think of it, as 86400ms:

“If the time difference in seconds calculated by the current time minus registration’s last update check time is greater than 86400”

You get some rope, but it isn’t there to hang you, it is there to make sure your update never goes beyond a day.

Can I fix more?

This is all very empowering, and in typical fashion when you give someone an inch they want a mile. Being able to programmatically dink around with the cache directly makes me with that I could do the same for the entire browser cache.

With a service worker you have a way for the user agent to talk to some of your code that can control a particular scope, outside of the typical page loading life-cycle.

What if I could have some code that would be able to fix any other mistakes that I have made. Let me clean up some of those old cookies I forgot about, or add a tether after the fact and let me say “hey if you have /path/to/foo.html please change the caching expiration. I messed up a year ago, and it feels so good that I have a way to now fix my mistake”.

Having that special bit of code is pretty special. Being able to create a true offline first application that makes everything run as fast as possible feels very progressive, but I also can’t help feel like we have only just begun to build a model that gives me amazing control over the relationship between myself and my users agent.

Hippocratic Service Worker

You want to be careful with new tethers, so how about getting the hippocratic service worker out there on your site so you can start experimenting? Get something trivial that lets you see what is happening, lets you play with updating the service worker and your kill switch system. Then you can take ownership of the dinosaur as you get on the fast path to delivering your users a fast path.

Running up and down the Web stack

February 8, 2016 Leave a Comment


As my mind shifted into consciousness on waking in London this morning, I noticed a dream where mice were running and up and down keys on a piano.

I have been thinking about how nice it is to see the Web platform evolve in both directions up and down the stack.

In the beginning there was HTML to define documents. Then we added styling via CSS, and dynamic behavior via <script>.

We tended to focus a solution in one of the worlds, and there were a few links between the worlds.

Animation

At some point we wanted to move things around, and the only way to do so was to take that script thing and change the location of the contain of the thing you want to move.

That was sloooooow. How about if we can declare animations and let the browser do all of the work? And then we ended up with CSS transitions and animations. GPU to the rescue.

But, what if we want to do some kind of movement that doesn’t fall into the auspices of the CSS capability? Ugh.

You want the best of all worlds. For common ideas that you can declare, you can CSS away and be done, however if you need something more wouldn’t it be nice to script on top of the performant browser engine rather than trying to do everything yourself (and slow)?

We are getting to that place. With Web Animations we have had the unification of declarative and imperative for awhile, and thanks to work coming out of Houdini we will be able to go through even more of an escape hatch to make sure to hit maximum polish.

For example, with a compositor worker you can ask the browser to keep you in the loop on certain DOM elements. This can allow you to keep elements nicely in sync so you can do keep 60fps as your UI flows around like this:

Service Workers

How do you want to work with service workers? Depending on your use case and how you like to work, you may prefer registering a service worker through your apps javascript:

navigator.serviceWorker.register(‘/sw.js’).then(function() {
 // you now control all pages on the origin!
});

Or you may want to declare the service worker from some HTML:

<link rel=”serviceworker” href=”/serviceworker.js”>

There are many other areas where this comes up. If the platform has the capability to create a custom element, it is nice to be able to register my own element both declaratively and imperatively.

As we continue to extend the Web, I like what I am seeing with respect to taking care of: core platform capability to how to access it to how to make it very productive for developers.

Streams is a fantastic, latest example of how a team will be able to go the extra mile for their users:

Make the common tasks trivial, and make custom tasks possible.

The Evolving State of Web Development

January 12, 2016 Leave a Comment


Wow, it looks like the web development is in a really sorry state! As I read the bileblog-esque post I found myself acknowledging some of the points, but also feeling like the baby was being thrown out of the bath water.

Writing my first web page to serve to lynx and mosaic was so simple. Man I miss it. I could telnet to my web server, pop open vi or emacs depending on my mood, add some <markup>, hit save (:wq!), and reload my browser.

Why can’t life be that simple?

  • The Web platform can do a lot more…. you know… useful things for people
  • The bar for great experiences has gone up.

I love developer ergonomics. I want to invest in my tooling so I can live reload to enable a very fast change, run, test life cycle. It is possible to wire up your babel build so they are watch’d, and you can tie into live reloading. Does it takes some upfront work? Sure. Is it worth it? yes.

The React Ecosystem, So Complex!

One of the poster boys for complaining about the complexity of Web development is taking the 2015 hot fave and tearing it down. Pete Hunt does a great job of reminding us how we got here. The initial concerns that React tried to solve hit a nerve for some folk, but once people got building applications we kept running into more issues and decided to do what we do as developers: we created abstractions to try to solve them.

If you haven’t been through this ride yourself it can be tough to understand what is going on. When we are born and join the world we are placed in environments where we use a ton of abstractions. Tools like knives, forks and spoons. Outlets at a particular voltage. They are everywhere and we don’t understand the evolutionary path that had us end up at this particular point.

Web development is evolving, and it needs to evolve fast. Many of us wish it would evolve faster, but this evolution always brings tension and pain. The problem is that true app developers who just want to build the right widget get tricked into the world of the engineer. They have to tie together a world that is changing rapidly, one that easily gets out of date. This is where you have a choice: do you reach for the new rung, knowing that you will pay the tax of keeping things up to date? Or, do we stick with something simpler, something that isn’t changing at quite the rapid rate.

You could easily argue that too many people join the rat race of the new shiny, and they jump on something that looks new but it won’t have any effect on the end user experience. It feels like you are jumping to a new rung, but really you just moved sideways.

One clue for us to understand how fast something changing is how “packaged” a solution can be. If the ecosystem is moving so fast that you can’t have a stable answer to the stack then this is a sign greater than the velocity of new releases (although breaking API changes is another sign).

I do agree with the pain of working with a package that doesn’t do anything out of the box. Convention over configuration works well when there are intelligent defaults that cover the majority use cases, while allowing people the escape hatch.

Jumping between top frameworks such as Ember, React, Angular, Polymer, etc isn’t going to do much for your users as is. I do think that we are at a point where it is time to reach for the next rung, and that is by re-thinking your web application to be offline-first.

When Google Maps came out, MapQuest instantly felt old and wrong. This is one of the apps that sparked the AJAX revolution (even though the panning Google Maps experience didn’t use XMLHttpRequest at all!) I think we will see similar examples as folks use service workers and friends to create offline capable applications. It will be stark, and it will happen fast. This time, users are already used to the capability via apps. Nothing frustrates me more than when I expect something to work, and find that it doesn’t. For example, using a task system that doesn’t allow you to add a new task unless you have a connection.

As you kick start 2016, what can you change that can genuinely change the user experience? Is there a change to your dev tool chain that allows you to build that experience so much faster that it will get more features to your users?

« Previous Page
Next Page »

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • Stitching with the new Jules API
  • Pools of Extraction: How I Hack on Software Projects with LLMs
  • Stitch Design Variants: A Picture Really Is Worth a Thousand Words?
  • Stitch Prompt: A CLI for Design Variety
  • Stitch: A Tasteful Idea

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile AI Native Dev AI Software Design AI Software Development Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Design Systems Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Eyes Family Fitness Football Founders Future GenAI Gender Equality Google Google Developer Google IO Google Labs Habits Health Hill Climbing HR Integrations JavaScript Jobs Jquery Jules Kids Stories Kotlin Language LASIK Leadership Learning LLMs Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Soccer Software Software Development Spaced Repetition Speaking Startup Steve Jobs Stitch Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • October 2025
  • September 2025
  • August 2025
  • January 2025
  • December 2024
  • November 2024
  • September 2024
  • May 2024
  • April 2024
  • December 2023
  • October 2023
  • August 2023
  • June 2023
  • May 2023
  • March 2023
  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

The right thing to do, is the right thing to do.

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2026 · Log in

Loading Comments...