I guess, because browser-makers tend to be engineers so they do engineering-type things like making the browser an app-delivery platform able to run compiled code. Or fight meaningless user experience battles like hiding the URL, or hiding View Source – both acts that don’t really help early users that much, but definitely impede the user path from being a consumer to being a fully-fledged participant/maker.
Sunday, August 9th, 2020
Wednesday, August 5th, 2020
Own. Your. Nook. There’s power in owning your nook of the ‘net — your domain name, your design, your archives — and it’s easier than ever to do so, and run a crowdfunding campaign at the same time.
Saturday, August 1st, 2020
So, why would you want to use a service worker? Here are some cool things you can do with it.
Chris lists some of the ways a service worker can enhance user experience.
Friday, July 31st, 2020
Smashing Podcast Episode 21 With Chris Ferdinandi: Are Modern Best Practices Bad For The Web? — Smashing Magazine
I really enjoyed this interview between Drew and Chris. I love that there’s a transcript so you can read the whole thing if you don’t feel like huffduffing it.
Some good blogging advice.
Building a blog for the long run? Avoid Medium.
Monday, July 27th, 2020
This is an interesting project to try to rank web hosts by performance:
Real-world server response (Time to First Byte) latencies, as experienced by real-world users navigating the web.
Friday, July 24th, 2020
A heartfelt look at progressive enhancement:
Some look at progressive enhancement like a thing from the past of which the old guard just can’t let go. But to me, progressive enhancement is the future of the Web. It is the basis for building resilient, performant, interoperable, secure, usable, accessible, and thus inclusive experiences. Not only for the Web of today but for the ever-growing complexity of an ever-changing and ever-evolving Web.
This is great! Ideas for allowing more styling of form controls. I agree with the goals 100% and I like the look of the proposed solutions too.
The team behind this are looking for feedback so be sure to share your thoughts (I’ll probably formulate mine into a blog post).
Wednesday, July 15th, 2020
Google could have approached the “be better on mobile” problem, search optimization and revenue sharing any number of ways, obviously, but the one they’ve chosen and built out is the one that guarantees that either you let them middleman all of your traffic or they cut off your oxygen.
There’s also this observation, which is spot-on:
Google has managed to structure this surveillance-and-value-extraction machine entirely out of people who are convinced that they, personally, are doing good for the world. The stuff they’re working on isn’t that bad – we’ve got such beautiful intentions!
Tuesday, July 7th, 2020
Good point. When we talk about perceived performance, the perception in question is almost always visual. We should think more inclusively than that.
Monday, June 22nd, 2020
But if I were going to bet on a web technology, it’s HTML. Always bet on HTML.
Saturday, June 13th, 2020
I think this a solution worthy of Solomon. In this case, the Gordian knot is the
select element and its inevitable recreation in order to style it.
What if we instead deliver a native select by default and replace it with a more aesthetically pleasing one if possible? That’s where the “hybrid” select idea comes into action. It’s “hybrid” because it consists of two selects, showing the appropriate one at the right moment:
- A native select, visible and accessible by default
- A custom select, hidden until it’s safe to be interacted with a mouse
The implementation uses a genius combination of a
hover media query and an adjacent sibling selector in CSS. It has been tested on a number of device/platform/browser combinations but more tests are welcome!
What I love about this solution is that it satisfies the stakeholders insisting on a custom component but doesn’t abandon all the built-in accessibility that you get from native form controls.
Monday, June 1st, 2020
If you’re in a group of people being chased by a bear, you only need to be faster than the slowest person in the group. But that’s not how websites work: being faster than at least one other website, or even faster than the ‘average’ website, is not a great achievement when the average website speed is frustratingly slow.
Friday, May 29th, 2020
This is excellent news for sites that were strong-armed into creating AMP pages just to get into the Top Stories carousel:
As part of this update, we’ll also incorporate the page experience metrics into our ranking criteria for the Top Stories feature in Search on mobile, and remove the AMP requirement from Top Stories eligibility.
This update doesn’t arrive until next year, but the message is clear: fast websites will be rewarded in search. I’ll be glad to see an end to AMP’s blackmail tactics.
Chris has put together one of his indispensable deep dives, this time into responsive images. I can see myself referring back to this when I need to be reminded of the syntax of
Saturday, May 23rd, 2020
Scott is brilliant, therefore by the transitive property, his course on web performance must also be brilliant.
Tuesday, May 19th, 2020
- Opted out experiences are ~35% faster
- Opted in repeat views are twice as slow as opted out
Monday, May 18th, 2020
Hard to break
I keep thinking about some feedback that Cassie received recently.
She had delivered the front-end code for a project at Clearleft, and—this being Cassie we’re talking about—the code was rock solid. The client’s Quality Assurance team came back with the verdict that it was “hard to break.”
Hard to break. I love that. That might be the best summation I’ve heard for describing resilience on the web.
If there’s a corollary to resilient web design, it would be brittle web design. In a piece completely unrelated to web development, Jamais Cascio describes brittle systems:
When something is brittle, it’s susceptible to sudden and catastrophic failure.
That sounds like an inarguably bad thing. So why would anyone end up building something in a brittle way? Jamais Cascio continues:
Things that are brittle look strong, may even be strong, until they hit a breaking point, then everything falls apart.
Ah, there’s the rub! It’s not that brittle sites don’t work. They work just fine …until they don’t.
Brittle systems are solid until they’re not. Brittleness is illusory strength. Things that are brittle are non-resilient, sometimes even anti-resilient — they can make resilience more difficult.
Kilian Valkhof makes the same point when it comes to front-end development. For many, accessibility is an unknown unknown:
When you start out it’s you, notepad and a browser against the world. You open up that notepad, and you type
<div onclick="alert('hello world');">Click me!</div>
You fire up your browser, you click your div and …it works! It just works! Awesome. You open up the devtools. No errors. Well done! Clearly you did a good job. On to the next thing.
At the surface level, there’s no discernable difference between a resilient solution and a brittle one:
For all sorts of reasons, both legitimate and, as always, weird browser legacy reasons, a clickable
divwill mostly work. Well enough to fool someone starting out anyway.
If everything works, how would they know it kinda doesn’t?
Killian goes on to suggest ways to try to make this kind of hidden brittleness more visible.
Furthermore we could envision a browser that is much stricter when developing.
This something I touched on when I was talking about web performance with Gerry on his podcast:
There’s a disconnect in the process we go through when we’re making something, and then how that thing is experienced when it’s actually on the web, which is dependent on network speeds and processing speeds and stuff.
I spend a lot of time wondering why so many websites are badly built. Sure, there’s a lot can be explained by misaligned priorities. And it could just be an expression of Sturgeon’s Law—90% of websites are crap because 90% of everything is crap. But I’ve also come to realise that even though resilience is the antithesis to brittleness, they both share something in common: they’re invisible.
We have a natural bias towards what’s visible. Being committed to making sure something is beautiful to behold is, in some ways, the easy path to travel. But being committed to making sure something is also hard to break? That takes real dedication.
Monday, May 11th, 2020
I’m at the point where you look at where the field is and what the alternatives are – taking a second look at unloved, unpopular, uncool things like Django, Rails, Laravel – and think what the heck is happening. We’re layering optimizations upon optimizations in order to get the SPA-like pattern to fit every use case, and I’m not sure that it is, well, worth it.
Spot-on analysis of what React is and isn’t good for. And lest you think this is blasphemy, Dan Abramov agrees.
Friday, May 8th, 2020
Trys describes the backend architecture of the excellent Sofa Conf website. In short, it’s a Jamstack dream: all of the convenience and familiarity of using a database-driven CMS (Craft), combined with all the speed and resilience of using a static site generator (Eleventy).
I love the fact that anyone on the Clearleft events team can push to production with a Slack message.
I also love that the site is Lighthousetastically fast.