Explore My Notes

I can never remember what the differences are between noopener, noreferrer, and nofollow, or when best to use them, so here's a handy guide that covers pretty much all of the basics.

Tl;dr:

• All three are values for the rel attribute on <a> tags;
• There's no point using any of them unless you have target="_blank" set (i.e. the link will force a new tab to open), and if you do you should use noopener to reduce cross-site phishing risks (there's no downside);
• Their primary goal is to restrict the access the linked page has to your website/the page linking to it;
• noreferrer blocks analytics tracking, which you probably don't want to do (but I guess is a way to subtweet via the indie web 😂). It also prevents SEO cross-linking scores, so if you really hate a linked website and don't want to boost it in search, then use this value;
• Ditto nofollow, though this is relevant regardless of what the target is; it just stops search engine crawlers from traversing the link, so ideal if you have it go somewhere you don't want associated with your site or search indexed, or if the link is doing fancy stuff (i.e. it should be a button 😉). There's a valid point here that user-generated content (such as comments) can benefit from applying nofollow by default, to reduce spam efficacy;
• Apparently, nofollow is a requirement for sponsored links and ads, so you don't generate clickthrough revenue based on spiders.

(PS: the article's own tl;dr is arguably even more concise and worth a read)

Now here's something I've been looking for: online (non-Flash) versions of popular board games. It feels like this industry should be booming right now! Board Game Arena looks pretty interesting, with a lot of great games, multiplayer options, and a cheap premium track of only $4 a month (guests can play for free). I also hadn't realised that Steam has a decent selection.

An interesting thought experiment from Chris: if a client asked you to build a website that could last a minimum of 10 years, what would you do? Lots of influential people in his answers, but I'm most interested in some of the proposed solutions. Basically:

• Use semantic HTML and CSS; minify JS as much as possible (and obviously no JS frameworks or dependencies);
• No externally hosted resources or data i.e. you can't call out. Either inline, self-host, or remove everything external;
• Clean, minimal design; simple colour palette; good typography (several people recommend system fonts, but I actually feel it would be best to host font files locally and fall back to "classic" system fonts. You never know when Windows might kill Arial, or when a new OS suddenly takes off);
• Consider internationalisation support (who says English is the main language in 10 years?);
• Stick to viewport units wherever possible to adapt to new screen resolutions and sizes; ditto SVG;
  
• Minimal copy – "even words go stale";
• Register the domain and hosting for the full 10 years upfront and set up auto-renewal of stuff like SSL.
  

Based on experience and observation in my time in the industry, I’d say it’s somewhere around 75% of websites are completely gone after 10 years, let alone particular URL’s on those websites being exactly the same (reliable external resources).

In all of these apps, every change you make updates the URL, instantly saving your progress in an easily sharable link. You don’t have to create an account or log in. In fact, you couldn’t if you wanted to because there’s no database! These apps are completely static.

What a fun idea. I've obviously seen (and have used) URLs contain state information in the past, such as user preferences (light/dark mode or animation), but building an entire game using nothing but URL parameters is pretty slick. The tip of encoding into base64 is great, too, as that really maximises what you can do with the space you have, though it does hurt extensibility (and readability) for your users.

Kasey mentioned this blog post in her talk yesterday. I wish I'd checked it out sooner, as it pretty much covers my notes from her (excellent) presentation but with greater clarity 👍 The perfect overview of the main WCAG 2.1 guidelines that all websites should strive to meet.

Oh dear. Tim's put together some actual numbers on the impact that using a frontend framework has on the user. As a proponent of the Jamstack, which pretty much has JavaScript frameworks at its core, these types of articles are always worrying, but they remain absolutely necessary information. So let's rip off the band-aid:

Sites with Angular ship 344% more JavaScript on desktop at the 10th percentile, and 377% more on mobile. Sites with React, the next heaviest, ship 193% more  JavaScript on desktop and 270% more on mobile devices.

Ouch 😢

Vue fares a little better, then comes jQuery (no real surprises there), with "vanilla" websites in the lead (again, not surprising; as Tim puts it, you can't start with JavaScript and expect to ship less). Thread times are similar, though here React is bottom of the pile by a clear margin:

React sites bring up the tail end, spending 248% more time on desktop devices and 658% more time on mobile devices. No, 658% is not a typo. At the 10th percentile, sites with React spend 2.7s on the main thread dealing with all the JavaScript sent down.

In comparison, Angular is rocking 230%-313% at the 10th percentile. This gets "better" as you begin looking at worse sites (i.e. the 90th percentile), but the overall trend persists and the numbers are still terrifying. At the tail-end, React sites are spending 20.8 seconds just parsing the JavaScript! Even more damning for React is that single-framework sites (which should perform better across the board) actually end up performing worse for the bottom 50%. Quite why is debatable, though Tim argues for site migrations meaning that some React sites are still offloading a lot of the work to jQuery, which remains more performant.

Worse still is how badly these framework-based websites perform on mobile.

Even at the 10th percentile, React sites spend 431.5% more time on the main thread on mobile devices as they do on desktop devices.

That's equivalent to over 10 seconds just to load the page properly... Still, whilst these results are even more damning than I would have predicted, there is room for hope. Tim is right in suggesting that vanilla JavaScript is the best alternative, but he also points to other technologies which could be a positive trade-off. More performant frameworks like Svelte and Preact help a lot; SSGs such as Gatsby, NuxtJS, and NextJS also give you massive savings (whew 😊).

He even points out that there are some forks and tools beginning to appear that simply strip all that JS out of the shipped site. For instance, the No JS Gatsby plugin looks pretty great; probably something worth experimenting on for this site.

Indonesia is a part of the world high on my "to visit" list. Between Komodo dragons, Homo floresiensis, the Wallace Line, and – of course – the delicious satay dishes, there's a lot that draws me to this region. Matt's write-up of his own trip is a little OTT at times, but it contains some useful information and a cracking itinerary. I had no idea that Borobodur was the biggest Buddhist temple in the world, for example.

Also, Matt notes this rather wonderful piece of folklore:

A long time ago, [the Dragon Princess] gave birth to twins, a human boy called Gerong and a female dragon called Ora. They separated at birth and reunited as adults in the forest, over a shared love of deer meat. Ever since then, the islanders have considered the Komodos their sacred ancestors and have lived in relative harmony with  them...

A fascinating breakdown of how the early web was forever changed by one of the first truly popular CMSs: MovableType. Most importantly, this is the likely culprit as to why so much of the web is now sorted chronologically, even though that may be a terrible model for what web pages actually are.

A wonderfully easy to navigate list of resources, tutorials, and guides for every stage of the web dev journey.

Though of course some people really do still rely on RSS readers, stubbornly adding an RSS feed to your blog, even in 2019, is a political statement.

A fascinating dive into the history of RSS. From the initial duel-creation of RDFSS and Scripting News format, to the perceived pre-bubble-burst concept that syndication was the future, until the present competing formats and slow recession out of view, it's very neatly put together. I think there's validity in the argument that RSS was always too "geeky for mainstream use" (something I also worry about with the IndieWeb movement, no matter how much I agree with it):

Regular people never felt comfortable using RSS; it hadn’t really been designed as a consumer-facing technology and involved too many hurdles; people jumped ship as soon as something better came along.

I certainly remember thinking, in the early days of Twitter, that this was clearly the evolutionary step that RSS needed (hah!). But it's a sad thing that, as the article concludes, these "single-author" silos are much easier to evolve and adapt than consensus-driven community efforts like RSS.

Just a really nice resource for trying to track down good areas to see the night sky or mess around with a little astrophotography.

The team behind the HTTP Archive do a fantastic job of analysing the web and 2019 is no exception. From JavaScript to accessibility, if you want to see how well we're doing as a community at standing up for our own ideals, implementing best practices, embracing new technologies, or just doing stuff in general, there aren't really any better resources.