Charles Harries

Posts Stream Books Walks • Clear filters

• Thursday, 29 Sep 2022 12:11 am | Stream

  Looking back

  Feeling weepy-eyed and nostalgic tonight because I watched a short video that my brother William put together out of home movies from some time in 1993. My grandparents on my dad's side are still alive, and my parents are young and bouncy, and I'm still small enough to be picked up & carried. I've not done a particularly good job of keeping artefacts from before I was 16 or 17, so this feels particularly precious. Then again I've always been susceptible to nostalgia.

  Been slowly moving the posts from Everything You Have Heard over to this blog, as well. It's been a fun trip back to my first year in Hokkaido, even if I was a little gung-ho with the approach to writing.

  It makes me wonder: ten or twenty years hence, what will I want to remember from today? Certainly not my petty attitudes towards edge functions, nor wonder at golfed JavaScript, nor any of the other things I post on here to keep my blog tech-related. I'll want home movies, pictures of my day-to-day, exasperation with Ghyll or excitement about riding the motorbike.
  

  I oughta be a bit better about recording this kinda stuff.

  Home Movies, Deadharrie

  Idle thoughts

• Wednesday, 28 Sep 2022 4:00 pm | Stream

  Old solutions, new tricks

  Right okay: let me get this straight. Phil Hawksworth created a site (displaying the current localised time) that redeployed itself every single minute for years. That's a funny idea and good marketing for the speed and reliability of Netlify deploys. Bit of a waste though—Netlify, after all, keeps all of your previous deploys around forever—so Phil updated the site to use a Netlify edge function to interpolate the current date into the statically generated site on every request. Et voilà—the current time, up to date and with no residual deploys.

  Heck, the site even uses <meta http-equiv="refresh" content="30" /> to force the browser to reload the page after 30 seconds, which means that your page won’t be stuck on the wrong time. Learned a new use for the <meta> tag today!

  But this feels like a lot of hullabaloo for, as far as the user is concerned, a plain PHP application from 2005 + a global CDN. Even from the developer’s perspective there’s almost no difference between this and an Express server running on Heroku. Using an Edge Function to interpolate a value into an HTML file is just serverside rendering with extra steps. And don’t get me wrong—the whole Netlify toolchain is a great value-add; being able to deploy globally with no configuration is a huge deal! But…

  This doesn’t feel like progress, somehow, to me. It feels like we’re spending countless mental CPU cycles catching up to a standard set years and years ago. Static sites were a game changer—why re-render an application if the content hasn’t changed? Eleventy + Netlify in particular is a terrific recipe for radically simplifying websites with minimal dynamic content.

  But between incremental static regeneration and edge functions and partial hydration and all the rest, we’re inventing more and more esoteric ways to reintroduce servers into the equation. And spending too much processing time on the server was the problem we were solving for in the first place.

  Here’s a 🔥 take for you: Netlify, Vercel, Render, or any other edge function provider is just offering CPanel as a Service.

  I have to be missing something. Am I just curmudgeonly? Are my skills going out of date? Am I burnt out? Surely the answer isn’t just CI/CD + CDN + novelty?

  Web Tech

• Thursday, 22 Sep 2022 11:40 pm | Stream

  Effective design

  I like Jim Nielsen’s interpretation of Good Design as requiring the context of the designer: Design is Good when it fulfils its purpose and intent.

  I'm always reminded of a module on New Criticism in a literary theory class at McGill at times like this. I like the idea of judging a work outside of its context from an aesthetic point of view, but I realise that it's almost totally impractical in reality.

  Sometimes the intent can be misleading: the intent of a poorly-presented unsubscribe button is usually the opposite of its actual function: not to stop the user receiving emails they no longer desire, but to reduce the sender’s unsubscription metrics. In that sense, the unsubscribe button is very well-designed indeed, since it serves the purpose it was designed for—even if it’s actively at cross-purposes to the end user.

  Same goes for e.g. hostile architecture: those leaning benches you see in railway stations aren’t designed to help people rest, but designed to prevent people sleeping on them. They’re very well designed, even if they’re ethically dubious. Design is not moral—it’s just a measure of fitness. (Designers, however...)

  I think for that reason I don’t like passing judgement on whether design is “good” or “bad”, since that carries some semantic baggage. Is the Like Button good design? What about ads in children's iPad games? Instead I think in terms of Effective Design: design that actually does what it purports to do.

  Good Design, Jim Nielsen

  Design

• Wednesday, 14 Sep 2022 5:12 pm | Stream

  Global variables

  In JavaScript—especially in modern JavaScript—variables are always declared with let or const (or, historically, var):

  function me() {
   let name = "Charles"; // scoped to me
  }
  

  I’m not going to get into the details here, since there are thousands of other blog posts diving into the differences out there. Instead. I want to talk about declaring variables without these keywords:

  function me() {
  	name = "Charles";
  }
  

  Up until the widespread adoption of ES Modules (and so long as you weren’t using strict mode) this was valid code. It declared name as a global variable—on window, if you’re in the browser.

  Developers are usually warned against doing this, because the global scope in the browser is already pretty full of stuff and you can never be sure whether you’re going to step on something that already exists.

  But I’m not just talking about browser APIs—did you know that every id attribute maps to a value on window (that is, the global namespace) in the browser?

  <nav id="navbar">The nav goes here</nav>
  
  <script type="text/javascript">
  	console.log(navbar) // => <nav id="navbar">
  </script>
  

  Thankfully we don’t tend to have to think about these things much nowadays—we’re well into the Age of ES Modules and if you’re not using "type": "module" from the start then you’ve likely got some bundler or another that abstracts all of this out of your regular thinking. But there’s always value in understanding the platform.

  Code JavaScript

• Monday, 12 Sep 2022 9:17 am | Stream

  Page weight matters

  I might be the last person on the planet to have discovered this 10-year-old post from Chris Zacharias about how optimising page weight on YouTube suddenly brought access to vast parts of the world that previously couldn't load the watch page. He recounts how, after putting together a proof of concept reducing the page weight from 1.2 MB to 100 KB, page latency times increased. The reason came down to geography:
  

  "When we plotted the data geographically and compared it to our total numbers broken out by region, there was a disproportionate increase in traffic from places like Southeast Asia, South America, Africa, and even remote regions of Siberia. Further investigation revealed that, in these places, the average page load time under Feather was over TWO MINUTES! This meant that a regular video page, at over a megabyte, was taking more than TWENTY MINUTES to load! This was the penalty incurred before the video stream even had a chance to show the first frame. Correspondingly, entire populations of people simply could not use YouTube because it took too long to see anything. Under Feather, despite it taking over two minutes to get to the first frame of video, watching a video actually became a real possibility. Over the week, word of Feather had spread in these areas and our numbers were completely skewed as a result. Large numbers of people who were previously unable to use YouTube before were suddenly able to."

  Unfortunately, it looks like developers over the past decade have let Chris's high standard slip—the first request on the current watch page weighs in at 1.6 MB as of today.

  Page weight matters, Chris Zacharias

  Web Accessibility

Archive