Hmm …seems like I should probably wait for the
load event before triggering
Hmm …seems like I should probably wait for the
A massively in-depth study of boundary-breaking music, recreated through the web audio API.
- Steve Reich - It’s Gonna Rain (1965)
- Brian Eno - Ambient 1: Music for Airports, 2/1 (1978)
- Brian Eno - Discreet Music (1975)
You don’t have to be a musician or an expert in music theory to follow this guide. I’m neither of those things. I’m figuring things out as I go and it’s perfectly fine if you do too. I believe that this kind of stuff is well within reach for anyone who knows a bit of programming, and you can have a lot of fun with it even if you aren’t a musician.
One thing that definitely won’t hurt though is an interest in experimental music! This will get weird at times.
One of the things we’d hoped to enable via Web Components was a return to ctrl-r web development. At some level of complexity and scale we all need tools to help cope with code size, application structure, and more. But the tender, loving maintainance of babel and webpack and NPM configurations that represents a huge part of “front end development” today seems…punitive. None of this should be necessary when developing one (or a few) components and composing things shouldn’t be this hard. The sophistication of the tools needs to get back to being proportional with the complexity of the problem at hand.
I completely agree with Alex here. But that’s also why I was surprised and disheartened when I linked to Monica’s excellent introduction to web components that a package manager seemed to be a minimum requirement.
Here’s the flow that eBay use for the font-loading. They’ve decided that on the very first page view, seeing a system font is an acceptable trade-off. I think that makes sense for their situation.
Interestingly, they set a flag for subsequent visits using
localStorage rather than a cookie. I wonder why that is? For me, the ability to read cookies on the server as well as the client make them quite handy for situations like this.
It looks like this is landing in Chrome. The
navigator.connection.type property will allow us to progressively enhance based on connection type:
A web application that makes use of a service worker to cache resources during installation might have different bundles of assets that it might cache: a list of crucial assets that are cached unconditionally, and a bundle of larger, optional assets that are only cached ahead of time when
There are potential security issues around fingerprinting that are addressed in this document.
A good analysis, but my takeaway was that the article could equally be called Why it’s tricky to measure Client-side Rendering performance. In a nutshell, just looking at metrics can be misleading.
Pre-classified metrics are a good signal for measuring performance. At the end of the day though, they may not properly reflect your site’s performance story. Profile each possibility and give it the eye test.
And it’s always worth bearing this in mind:
- the early era: ~1996 – 2004,
- the jQuery era: ~2004 – 2010,
- the Single Page App era: ~2010 - 2014, and
- the modern era: ~2014 - present.
You can use
navigator.storage.estimate() to get a (vague) idea of how much space is available on a device for your service worker caches.
Ooh, this is a tricky scenario. If you decide to redirect all URLs (from, say, a
www subdomain to no subdomain) and you have a service worker running, you’re going to have a bad time. But there’s a solution here to get the service worker to remove itself.
The server-side specifics are for NGINX but this is also doable with Apache.
There are some great service worker optimisation tips in these slides.
The reality is transpiling and including polyfills is quickly becoming the new norm. What’s unfortunate is this means billions of users are getting trillions of bytes sent over the wire unnecessarily to browsers that would have been perfectly capable of running the untranspiled code natively.
script type="module" and put your transpiled fallback in
Most developers think of
<script type="module">as way to load ES modules (and of course this is true), but
When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.
If you’re interested in predicting the future of the web, just look at what high-performance native systems look like, then figure out how we can apply those ideas in the browser.
I like that Tom encourages learning from native, but not at the expense of the web (hint, hint, Google devrels encouraging slavish imitation of native apps in progressive web apps with no regard for URLs).
Our job now is figuring out how to adapt the ideas of high-performance native code while preserving what makes the web great: URLs, instant loading, and a security model that allows us to forget that we run thousands and thousands of untrusted scripts every day.
This article makes a good point about client-rendered pages:
Asynchronously loaded page elements shift click targets, resulting in a usability nightmare.
…but this has nothing, absolutely nothing to do with progressive web apps.
More fuel for the fire of evidence that far too many people think that progressive web apps and single page apps are one and the same.
This is a smart way to queue up POST submissions for later if the user is offline. It’s not as powerful as background sync (because it requires the user to revisit your site) but it’s a good fallback for browsers that support service workers but don’t yet support background sync