Explore My Notes

Wipe Git history from a repository | Freek Van der Herten

A short guide to removing Git history entirely. Particularly useful when you're forking an existing project as a base for something new.

  1. Delete the .git folder entirely
  2. Run git init to create a new one
  3. Add all files and create your new first commit

Not tricky, but surprised me that there wasn't a solution within Git itself.

World building online | World Anvil

This looks like a very interesting world-building tool. Create maps, family histories, write stories, track campaigns, all from a single profile. Neat 💪

The mobile performance inequality gap 2021 | Alex Russell

A frankly depressing look at the state of the mobile web in 2021. From lacklustre technological advancement in the past decade, to increasing device saturation, and the overuse of JavaScript, here's the main conclusion:

  1. The global performance baseline provides ~100KiB (gzipped) of HTML/CSS/fonts and 300-350KiB of JavaScript (compressed and assuming minimal HTTP requests);
  2. The web is losing to native because performance genuinely matters, and it shouldn't be.

On how one poorly performing site can lead users away from the web and towards apps:

Bad individual experiences can colour expectations of the entire ecosystem.
Plenty of native apps are happy to aggregate content and serve it up in a reliably fast package, given half a chance. The consistency of those walled gardens is a large part of what the mobile web is up against — and losing to.
CPUs are not improving fast enough to cope with frontend engineers' rosy resource assumptions

---

On how a single disruptive carrier forced India's mobile market to embrace 4G, significantly improve cost (as much as 95% reduction in some areas), and brought an entire country online with stable, fast connections:

In 2016, Jio swept over the subcontinent like a monsoon dropping a torrent of 4G infrastructure and free data rather than rain.

Interesting that slow 4G is now considered a global baseline speed. That's impressive, given that 5 years ago slow 2G was the baseline 😬

---

On global smartphone purchase trends:

The worldwide device replacement average is now 33 months. In markets near smartphone saturation, that means we can expect the median device to be nearly 18 months old.

As of 2021, the average smartphone looks a lot like a Moto G7: Android, mid-tier, about 2-3 years old, running Chrome.

But average is only half the market. A better baseline would be the Moto E6 (or even Moto G4): still Android and Chrome, quad-core, 2GB RAM.

---

On how those same trends are creating a significant inequality gap:

As high-end phone performance accelerates away from mass-market devices (still largely with the same performance as 2012) we're creating a high inequality gap:
When we construct a digital world to the limits of the best devices, the worse an experience we build, on average, for those who cannot afford iPhones or $800 Samsung flagships.

---

On the folly (and privilege) of making choices based on DX instead of UX:

But we must never forget that measurable improvement for users is the yardstick.
Trickle-down user experience from developer-experience is, in 2021, as fully falsified as the Laffer Curve. There's no durable substitute for compassion.

---

On what comes next:

But there's light at the end of the tunnel: if we can just hold back the growth of JS payloads for another year or two — or reverse the trend slightly — we might achieve a usable web for the majority of the world's users by the middle of the decade.

📆 28 May 2021  | 🔗

  • Frontend
  • mobile
  • web
  • web performance
  • report
  • inequality
  • Android
  • benchmark
  • JavaScript
  • SPA
  • DX
  • 4G
  • India
  • phone 

Code words and language barriers | Seth Godin

Seth has a good point about the barriers that language can create between groups that ultimately share the same goal:
Often, when people with goodwill and shared values end up disagreeing, it’s because they didn’t understand the code words that were being used.

(I often wonder how much the Left's ever-changing vocabulary hurts its ability to work cohesively, for example)

What the heck, z-index? | Josh W. Comeau

The best overview of z-index and stacking contexts that I've come across, plus it keeps getting better as Josh extends the useful tools section 👏👏

Top of the tips is isolation: isolate, a very useful CSS function that I never remember; it effectively resets the stacking context, which means it's particularly useful for component-based UI structures.

Also a worthy shout-out to the CSS Stacking Context Inspector plugin (also available for Chrome). It's already helped me locate a rogue stacking context being created by a global opacity attribute (of all things 😂).

📆 25 May 2021  | 🔗

  • HTML & CSS
  • z index
  • CSS
  • stacking context
  • Firefox
  • plugin
  • isolation 

Layout love and drumming | Stuff & Nonsense

A follow-up to Andy's previous explanation of his compound grid layout in which they explain their logic behind a 4 + 5 compound grid a bit more. It's neat, but this description is what really caught my eye:

Think of each column as a beat. When you drum the cadence of 12 evenly-sized columns with your fingers, the rhythm is monotonous.

That's a nice way of framing a layout. I'd like to give it a try in reverse one day: think of a drumbeat I like and work out what grid layout is equivalent to the hits and gaps, then see if it could be the foundation to a site. Sounds like fun 🥁

Design for reading | Sara Soueidan

A very clever article (as ever) from Sara on how to ensure the content you create is accessible through RSS feeds and Reader modes (and a host of other applications).

This is something I'm guilty of. There's a kind of magic to automating content through CSS which I find very appealing, but Sara's warning here is something I'll need to keep in mind moving forward:

In order to ensure readers always get a proper reading experience, provide real content in HTML, and leave CSS pseudo-elements for decorational content that is not required for the core reading experience.

They also point out how problematic call-out content can be, and suggest hiding unnecessary content in a couple of ways. The simplest is removing it from the <article> element, which should cater for a number of scenarios (and I wonder if things like Safari's Reader mode deal with <aside> elements correctly?), but if your markup requires it to be kept there's a really clever trick using hidden:

Since the hidden attribute has a very low specificity, you can override it in your CSS using a simple display: block/flex/grid/etc..

In other words, add the hidden attribute to your content block, then have a utility class like hide-reader-mode which sets it to display: block (or just target directly). Users on your site will see it, but if your CSS doesn't load, neither will the content (so also useful if the stylesheet fails to download for some reason).

Sara also points out you can do the inverse, having a utility class like reader-mode-only that shows content only where your CSS doesn't load. So you can still have fancy CSS pseudo-elements or drop caps etc. but RSS feeds will get plain text equivalents. Can be particularly useful for live examples (they point to a styled <hr> example) which can be switched out for images.

Strikes me you could use similar tricks to show messages in RSS feeds that otherwise wouldn't appear. Just a lot of cool ideas going on here!

📆 10 May 2021  | 🔗

  • HTML & CSS
  • Inclusion
  • hidden
  • reader mode
  • Safari browser
  • RSS
  • a11y
  • CSS
  • trick
  • utility class
  • hr
  • specificity 

Sexism, racism, toxic positivity, and TailwindCSS | Cher

Cher has written an excellent, concise, and extremely evenly-handed response to the current Tech Twitter™ nonsense. I wanted to save it (alongside Andy's) to refer to next time this happens (because, unfortunately, there will be a next time) 😤

A response to the initial article that acted as a flashpoint (and some useful ideas around TailwindCSS for my own understanding to evolve a bit):

I do think it's important that we frame our critique and support for technology in a way that makes it clear we understand that while it did or did not work for us, or our team, or our project; we know it's for our case and our reasons are reflective of that specificity.

On the inherent bigotry on show (and that ending is just superbly well written):

Sara has had to earn his respect and admiration, as a non-American woman of color, instead of getting it from default in-group bias, and anything other than the admiration he gives her is felt as betrayal.
A man incited bullying onto a Lebanese woman for sharing a critique of a framework he wrote not for the critique itself, but because she didn't give him the admiration he felt he deserved. That's not respect. That's systemic entitlement.

Frontend hype and dogmatism | Andy Bell

Tech Twitter™ is bickering again and, as ever, Andy's take is the best take: use what works, understand that criticism is not an attack, and realise that what works for you may not work for others.

(Also, best practices are real but are not globally applicable)

(Also also, I need to do better to remember this article and just immediately return to it each time Tech Twitter™ has an opinion)

On best practices:

With this context in mind: when someone says “best practices don’t work”, or similar—without a caveat of “in our particular situation”—then remember: this is likely a statement of naivety and I would strongly recommend dismissing it.

The caveat that should factor into your decisions and arguments/discussion on anything:

Remember, that’s my preference.

Tailwind adds complexity, does nothing | Brian Boyko

I've never understood the appeal of TailwindCSS. I've watched friends and colleagues get amped for it, seen their code, and just felt like it was a meaningless abstraction of the existing technology. Brian does a solid job of delving into why Tailwind can also be a problematic tool that champions bad practices over good ones.

The tl;dr involved is that:

  • Tailwind isn't DRY, making maintenance trickier (and bugs more likely); (he claims it's WET, but it's not even that, it's just repetitive);
  • It ignores the principle of separation of concerns by stuffing CSS back into HTML;
  • Its naming is willfully obtuse and non-semantic, making it harder to read, debug, and maintain (both in language and structure i.e. horizontal code lines rather than vertical code blocks);
  • It breaks core CSS functionality, such as grouping (classes), the cascade, combinators (* + *), and media queries;
  • It introduces polyfills to recreate some of this functionality, thereby admitting its own model is inflexible and problematic;
  • It is a solution in want of a problem;
  • Better ideas exist (styled-components, Emotion, Sass);
  • And, well, this:
Screenshot from the TV show Rick and Morty, with Rick saying
Are we actually desperate to reinvent inline styles? Original image from Brian's article.

Or in his words:

You're basically left with a less readable, more complex version of inline styles, a coding technique that we've been trying to breed out of junior developers for the past decade or so.

He also makes a very valid point about imagining the inverse situation. Let's say CSS works like Tailwind does today and then a CSS 2.0 is announced which gives you the equivalent of modern CSS... that would be a godsend!

If you could go from the limitations of Tailwind to CSS, wouldn't you consider that a quantum leap forward? Expressive syntax! Semantic naming! Style grouping! Selectors and combinators!. It would be like moving from Assembly to C for the first time.

So why is Tailwind the hot new thing? I'm still utterly unsure 🤷‍♂️

Au revoir, mon AMPmour? | Ethan Marcotte

I'm late to the "goodbye AMP" party, but Ethan's has been the best take I've read so far (no surprise there). In brief: it's good that AMP is on the way out, but we're stuck with it for some time, and the new Core Web Vitals still have some issues:

I’ll say again: deprioritizing AMP in favor of Core Web Vitals is a very good thing. But it’s worth noting that Google’s taken its proprietary document format, and swapped it out for a proprietary set of performance statistics that has even less external oversight.

📆 07 May 2021  | 🔗

  • Frontend
  • core web vitals
  • Google
  • AMP
  • web performance 

Space Jam | Max Böck

Max has done a performance analysis of the new Space Jam website versus the old, classic variation, with a damning conclusion:

So after 25 years of technological progress, after bringing 4.7 billion people in the world online, after we just landed a fifth robot on Mars, visiting the Space Jam website is now 1.3 seconds faster. That seems… underwhelming.

🤦‍♂️

📆 06 May 2021  | 🔗

  • Frontend
  • Space Jam
  • movie
  • web performance
  • page speed
  • comparison
  • loading 

Made By Me, But Made Possible By:

CMS:

Build: Gatsby

Deployment: GitHub

Hosting: Netlify

Connect With Me:

Twitter Twitter

Instagram Instragram

500px 500px

GitHub GitHub

Keep Up To Date:

All Posts RSS feed.

Articles RSS feed.

Journal RSS feed.

Notes RSS feed.