There are a lot of static site generators out there!
Tuesday, July 10th, 2018
I remember Jason telling me about this weird service worker caching behaviour a little while back. This piece is a great bit of sleuthing in tracking down the root causes of this strange issue, followed up with a sensible solution.
Tuesday, May 29th, 2018
Push notifications explained using astrology. But don’t worry, there’s also some code, just in case you prefer your explanations to also include models that actually work.
Tuesday, February 27th, 2018
Here’s a really smart approach to creating container queries today—it uses
ResizeObserver to ensure that listening for size changes is nice and performant.
There’s a demo site you can play around with to see it in action.
While the strategy I outline in this post is production-ready, I see us as being still very much in the early stages of this space. As the web development community starts shifting its component design from viewport or device-oriented to container-oriented, I’m excited to see what possibilities and best practices emerge.
Friday, January 26th, 2018
Chris has set up a whole site dedicated to someone-else’s-server sites with links to resources and services (APIs), along with ideas of what you could build in this way.
Thursday, January 18th, 2018
Here’s a clever idea from Harry if you’re willing to play the long game in tracking down redundant CSS—add a transparent background image to the rule block and then sit back and watch your server logs for any sign of that sleeper agent ever getting activated.
If you do find entries for that particular image, you know that, somehow, the legacy feature is potentially still accessible—the number of entries should give you a clue as to how severe the problem might be.
Sunday, January 14th, 2018
Sunday, December 3rd, 2017
Tuesday, October 31st, 2017
A great bucketload of common sense from Jake:
Rather than copying bad examples from the history of native apps, where everything is delivered in one big lump, we should be doing a little with a little, then getting a little more and doing a little more, repeating until complete. Think about the things users are going to do when they first arrive, and deliver that. Especially consider those most-likely to arrive with empty caches.
And here’s a good way of thinking about that:
I’m a fan of progressive enhancement as it puts you in this mindset. Continually do as much as you can with what you’ve got.
All too often, saying “use the right tool for the job” is interpreted as “don’t use that tool!” but as Jake reminds us, the sign of a really good tool is its ability to adapt instead of demanding rigid usage:
Netflix uses React on the client and server, but they identified that the client-side portion wasn’t needed for the first interaction, so they leaned on what the browser can already do, and deferred client-side React. The story isn’t that they’re abandoning React, it’s that they’re able to defer it on the client until it’s was needed. React folks should be championing this as a feature.
Monday, September 25th, 2017
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:
Thursday, September 21st, 2017
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.
Monday, September 11th, 2017
This blog post saved my ass—the Huffduffer server was b0rked and after much Duck-Duck-Going I found the answer here.
I’m filing this away for my future self because, as per Murphy’s Law, I’m pretty sure I’ll be needing this again at some point
Monday, August 7th, 2017
Paul goes into detail describing how he built a progressive web app that’s actually progressive (in the sense of “enhancement”). Most of the stuff about sharing code between server and client goes over my head, but I understood enough to get these points:
- the “app shell” model is not the only—or even the best—way of building a progressive web app, and
- always, always, always render from the server first.
Thursday, July 20th, 2017
It’s all very admirable, but it also feels a little bit 927.
Thursday, March 30th, 2017
Charlotte’s step-by-step account of setting up a Node server is going to be invaluable if and when I get around to dipping my toes in those waters.
Friday, February 3rd, 2017
Phil describes the process of implementing the holy grail of web architecture (which perhaps isn’t as difficult as everyone seems to think it is):
I have been experimenting with something that seemed obvious to me for a while. A web development model which gives a pre-rendered, ready-to-consume, straight-into-the-eyeballs web page at every URL of a site. One which, once loaded, then behaves like a client-side, single page app.
Now that’s resilient web design!
Sunday, January 15th, 2017
Scott runs through the latest improvements to the Filament Group website. There’s a lot about HTTP2, but also a dab of service workers (using a similar recipe to my site).
Saturday, December 10th, 2016
Certbot renewals with Apache
I wrote a while back about switching to HTTPS on Apache 2.4.7 on Ubuntu 14.04 on Digital Ocean. In that post, I pointed to an example .conf file.
I’ve been having a few issues with my certificate renewals with Certbot (the artist formerly known as Let’s Encrypt). If I did a dry-run for renewing my certificates…
/etc/certbot-auto renew --dry-run
… I kept getting this message:
Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories. Falling back to default vhost *:443…
It turns out that Certbot doesn’t like HTTP and HTTPS configurations being lumped into one .conf file. Instead it expects to see all the port 80 stuff in a
domain.com.conf file, and the port 443 stuff in a
So I’ve taken that original .conf file and split it up into two.
First I SSH’d into my server and went to the Apache directory where all these .conf files live:
Then I copied the current (single) file to make the SSL version:
cp yourdomain.com.conf yourdomain.com-ssl.conf
Time to fire up one of those weird text editors to edit that newly-created file:
I deleted everything related to port 80—all the stuff between (and including) the
VirtualHost *:80 tags:
<VirtualHost *:80> ... </VirtualHost>
Hit ctrl and o, press enter in response to the prompt, and then hit ctrl and x.
Now I do the opposite for the original file:
Delete everything related to
<VirtualHost *:443> ... </VirtualHost>
Once again, I hit ctrl and o, press enter in response to the prompt, and then hit ctrl and x.
Now I need to tell Apache about the new .conf file:
I’m told that’s cool and all, but that I need to restart Apache for the changes to take effect:
service apache2 restart
Now when I test the certificate renewing process…
/etc/certbot-auto renew --dry-run
…everything goes according to plan.
Thursday, December 8th, 2016
Remy wants to be able to apply progressive enhancement to React: server-side and client-side rendering, sharing the same codebase. He succeeded, but…
In my opinion, an individual or a team starting out, or without the will, aren’t going to use progressive enhancement in their approach to applying server side rendering to a React app. I don’t believe this is by choice, I think it’s simply because React lends itself so strongly to client-side, that I can see how it’s easy to oversee how you could start on the server and progressive enhance upwards to a rich client side experience.
I’m hopeful that future iterations of React will make this a smoother option.
Saturday, August 6th, 2016