JavaScript — Piper Haywood

Published Thursday, 3 June 2021 by Piper Haywood

Two articles on SPA or SPA-like sites vs alternatives

I missed these two articles by Tom MacWright from last year.

Second-guessing the modern web, 10 May 2020
If not SPAs, What?, 28 October 2020

In both, he outlines few upsides and downsides about the single page app (SPA) approach to websites and has a few points that I have really struggled to articulate in the past.

From “Second-guessing”:

There is a swath of use cases which would be hard without React and which aren’t complicated enough to push beyond React’s limits. But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are trying to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.

I’ve dabbled with React and Vue in small side projects and experiments. But the point above is the big reason I’ve never taken the time to sit down and learn either of them properly. For almost every client site I’ve ever done, it just didn’t make sense to make it an SPA.

And I’m not 100% sure, but I think this might contribute to longevity. Some of my clients are still working with the same sites I built for them nearly 10 years ago, a few with just minor security-related updates in the meantime and no other maintenance strictly required. That’s not to say that those sites couldn’t use a “lick of paint” to bring them in to the 2020s; the point is that they work. And for organizations working on really tight budgets, or budgets that fluctuate wildly due to public funding, stability is really important. They can’t afford a developer on retainer to keep things running smoothly.

But of course the SPA vibe is pretty attractive, particularly for cultural orgs. MacWright has some decent alternatives suggested in “If not SPAs” including Turbolinks, Barba.js, and instant.page. Will also mention MoOx/pjax since I’ve used it before for page transitions with very good results, but probably won’t use it in the future as it hasn’t been updated in a while.

And again, there’s the rub. The more non-native scripts, plugins, etc I use in a project, the more likely that it’s going to be a major headache (and thus major time/money for the client) for me to change things down the line if or when that bit of tech is no longer supported or has changed significantly.

So it’s not even so much about being wary of React or Vue, it’s about not making assumptions, being cautious and cognizant of future needs or restrictions when proposing a tech stack. Any tech stack you choose will ultimately become a ball-and-chain, not just those based on JavaScript frameworks. It’s just that the ball can sometimes be heavier than it needed to be, and you can anticipate that with a little foresight.

Published Thursday, 9 January 2020 by Piper Haywood

Switching from Google Analytics to Matomo (f.k.a. Piwik) on WordPress

It’s a new decade, time to leave Google Analytics.

A big part of me wants to say screw it, just get rid of analytics altogether. But I find it interesting. I’ve never used it to decide what to write, and I don’t think I ever will, but it’s just fascinating to find out what makes the rounds. I’ll never know why a short post about repairing my mom’s straw bag was my most popular post for years, but I’m glad to know a lot of people checked it out.

So I decided to keep my Google Analytics property in place and just locked it down as much as I could. I adjusted the script to respect users’ Do Not Track browser settings (Paul Fawkesley has a short article about how to do this). I also configured Google Analytics to anonymise IP addresses, and I deliberately disabled Data Collection for Advertising Features, Demographics and Interest Reports, User-ID, and all data-sharing settings. I also set a low data retention policy to make sure old data would get deleted.

None of this changed the fact that I was still sharing data with Google.

Date-based colour

Read “Dynamic, Date-Based Color with JavaScript, HSL, and CSS Variables” by Rob Weychert

This is such a useful article. His implementation on Tinnitus Tracker is definitely more involved than what I’ve done on this site, particularly what he’s done to account for inherent saturation levels and lightness vs luminance. And his colour wheel mapping is slightly offset from mine. I feel like August is the reddest month! I’ve wanted to reconsider the colour here for a while, particularly since the accessibility of some of the hues isn’t up-to-snuff. Rob’s write-up might make that adjustment a bit more straightforward which is a big relief.

I remember being really interested in where Grant Custer went with colour on his blog when I started screwing around with colour on this site. See his blog in 2013 on the Internet Archive. I wanted to see whether or not there was some way to ambiguously reflect where I was in the world, particularly since I live so far away from most of my family.

The first version of the colour experimentation on this site mapped the HSL values to the season, temperature, and time of day where I was at the time the site was visited. This is an example from Paris in late 2016. The hue value was mapped to the date/season (same as now), and the lightness was mapped to the time of day using Moment.js and Moment Timezone. The goal was to map the saturation to the weather where I was using the OpenWeatherMap API with stormy and cloudy days being less saturated, but that never came to be since the weather descriptions weren’t consistent enough. I ended up mapping the saturation to the temperature instead, but I don’t think it was quite as effective.

When I turned the site in to a blog first and foremost, I dropped the location and weather aspect. It could be fun to return to it since it might bring a bit more variation, particularly on the list page. Might be a little wild though, and it might be a massive headache to introduce location and weather on old posts… At bare minimum, I could probably incorporate the time of day as lightness. We’ll see!

Published Wednesday, 2 October 2019 by Piper Haywood

New site for a Barcelona-based architecture practice

We launched a new site for architecture practice Barozzi Veiga about a month ago. It was a pleasure to work with Adrien Vasquez at John Morgan studio during the development process and to work with the Barozzi Veiga folks as we fine-tuned things. The site launch coincided with the announcement that Barozzi Veiga had been selected to take on a major renovation of the Art Institute of Chicago (read more).

barozziveiga.com

Published Thursday, 13 June 2019 by Piper Haywood

britishearways.com

Last month, I completed a major overhaul of the British Earways website. The design by Valerio di Lucente of Julia is almost entirely unchanged, the adjustments were largely performance-related and under the hood, geared towards modern browsers. Here’s brief rundown of the changes:

Style the full-window player layouts using CSS Grid Layout + 100% height (not 100vh since that can lead to unexpected behaviour on mobile browsers), and use CSS Scroll Snap w/ polyfill for scroll behaviour
Achieve flexible typography and spacing with “CSS Locks”
On non-touch screens, implement invisible DragDealer instances so that each player’s scrubber can be dragged
On touch screens, add click event listeners that advance the relevant scrubber to the click target
Use styled HTML5 progress elements for each player since these are easily manipulated via their max and value attributes and don’t require adjustment if the window is resized
Use the Web Audio API to initialise each audio file and trigger the necessary state changes as the time updates
Switch the audio preload attribute from auto to metadata to reduce the size of the page when it initially loads
Update CMS to Kirby 3 (this was a joy, IMO the panel layout options make v3 much more client-friendly)
Adjust post_max_size, memory_limit, max_execution_time, and upload_max_filesize to allow upload of large (150MB+) audio files

I ran in to one issue that isn’t yet resolved. Kirby copies all uploaded media from the private /content folder to the publicly-accessible /media folder. This copying normally happens almost instantly, even with very large files. On the BE site however, the copy is pretty slow. Since the site pulls the audio duration from the audio file itself via the Web Audio API, the displayed duration is incorrect until the file has finished copying. This is almost certainly related to some rate limiting done by the shared hosting company, a legacy from the preexisting site. It isn’t a huge deal since the copying always finishes eventually, but it isn’t the best behaviour. I’d like to raise the issue with the hosting company but don’t have high hopes, shared hosting providers use rate limiting for a reason.

At any rate, I’m really looking forward to seeing how DB uses the site over the next year and listening to the new mixes.

Published Wednesday, 13 June 2018 by Piper Haywood

Exploring the use cases for serverless website architecture

Last Saturday, Sam introduced me to Chris Coyier’s talk on serverless-ness, The All-Powerful Front-End Developer. Pretty interesting and useful. I’m glad he leads it by breaking down the problematic nature of the word “serverless”! The following day was spent in agorama’s p2p workshop at furtherfield. Coincidentally, there is a lot of overlap in these topics.

I’ve spent the past few days wrapping my head around all of this, contextualising it against the sorts of concerns and projects we work with. Though I desperately want to get going with Dat, I’m starting with serverless because it may solve an urgent need in my day-to-day work. Right now, I’m spending much more time than I realistically can maintaining CMSs and hosting environments for older websites.

All of the below is a thought dump on the topic, an attempt to pick apart the meaning of and the use cases for a serverless website architecture.

Notes from 24 Pull Requests event

See notes and further research prompts below in relation to yesterday’s 24 Pull Requests event. It was organised by Codebar, Ladies Who Code, and Your First PR, sponsored by Gitter, Shutl, and Twitter. I left Twitter HQ with my brain fizzing, always a good thing.

Snippet for LazyLoad + Spin.js

/**
 * Identify images by class. For each image, add 
 * [Spin.js](http://fgnass.github.io/spin.js/) to parent, [LazyLoad](http://verlok.github.io/lazyload/) image, stop spinner 
 * when image is loaded.
 */

var imgClass = "lazy";

var spinOpts = {
  // [Spin.js options](http://fgnass.github.io/spin.js/#usage)
};

var spinners = [];
var elems = document.getElementsByClassName( imgClass );
for ( var i = 0; i < elems.length; i++ ) {
  var pId = "lazy-" + ( i + 1 );
  var parent = elems[i].parentElement;
  parent.id = pId;
  spinners[pId] = new Spinner( spinOpts ).spin( parent );
}

var lazyLoad = new LazyLoad( {
  elements_selector: "." + imgClass,
  callback_load: function( element ) {
    var spinner = spinners[element.parentElement.id];
    if ( spinner ) {
      spinner.stop();
    }
  }
} );

For use with LazyLoad by Andrea Verlicchi and Spin.js by Felix Gnass. SB and I have both checked out a few different lazyloading plugins, we’re pleased with how this one works with srcset.

Since the default positioning of Spin.js centres the spinner in the element, it’s best for the image to be the only child of the parent element. The code above assumes that this is the case. If I didn’t have control over the markup or needed to individually wrap each image for any other reason, would probably implement something similar to the above w/ jQuery (see the Spin.js jQuery plugin).

Published Tuesday, 1 September 2015 by Piper Haywood

black-hole.js, by Cliff Crosland

Demo and explanatory blogpost for black-hole.js by Cliff Crosland.

Published Thursday, 13 August 2015 by Piper Haywood

Surfing with coffee 2

Surfing w/ coffee #2. Order of exploration:

A
Google search “web worker” paper.js jerky (trying to sort out animation+ajax issues) → Paper.js issue #634 “Allow using paperjs without canvas” → Paper.js issue #561 “Add Font and Glyph types from plumin.js” (↓B) → Plumin.js (↓C) → Louis-Rémi Babé @louis_remi → Surge, static web publishing

B
Opentype.js → Frederik De Bleser (↓D) → NodeBox, tools for generative design

C
Yannick Mathey @_____________y → USA, limited edition typographic print

D
Overtone, collaborative programmable music → Meta-eX, “Live coding. Live synths. Live music.”

See previous surf sesh.