Defensive CSS - Ahmad Shadeed
This is a smart collection of situations to consider and the CSS to resolve them. It’s all about unearthing assumptions.
Link tags: assumptions
14
How To Build Resilient JavaScript UIs — Smashing Magazine
The opening paragraphs of this article should be a mantra recited by every web developer before they begin their working day:
Things on the web can break — the odds are stacked against us. Lots can go wrong: a network request fails, a third-party library breaks, a JavaScript feature is unsupported (assuming JavaScript is even available), a CDN goes down, a user behaves unexpectedly (they double-click a submit button), the list goes on.
Fortunately, we as engineers can avoid, or at least mitigate the impact of breakages in the web apps we build. This however requires a conscious effort and mindset shift towards thinking about unhappy scenarios just as much as happy ones.
I love, love, love the emphasis on reducing assumptions:
Taking a more defensive approach when writing code helps reduce programmer errors arising from making assumptions. Pessimism over optimism favours resilience.
Hell, yeah!
Accepting the fragility of the web is a necessary step towards building resilient systems. A more reliable user experience is synonymous with happy customers. Being equipped for the worst (proactive) is better than putting out fires (reactive) from a business, customer, and developer standpoint (less bugs!).
Two articles on SPA or SPA-like sites vs alternatives — Piper Haywood
On framework-dependency and longevity:
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.
Listen To Me And Not Google: HeydonWorks
We have to stop confusing the excesses of capitalism with the hallmarks of quality. Sometimes Google aren’t better, they’re just more pervasive.
cough AMP cough
The Web is Made of Edge Cases by Taylor Hunt on CodePen
Oh, this is magnificent! A rallying call for everyone designing and developing on the web to avoid making any assumptions about the people we’re building for:
People will use your site how they want, and according to their means. That is wonderful, and why the Web was built.
I would even say that the % of people viewing your site the way you do rapidly approaches zilch.
I Used The Web For A Day With JavaScript Turned Off — Smashing Magazine
Following on from Charlie’s experiment last year, Chris Ashton has been assessing which sites rely on JavaScript, and which sites use it in a more defensive, resilient way. Some interesting results in here.
A good core experience is indicative of a well-structured web page, which, in turn, is usually a good sign for SEO and for accessibility. It’s usually a well designed web page, as the designer and developer have spent time and effort thinking about what’s truly core to the experience. Progressive enhancement means more robust experiences, with fewer bugs in production and fewer individual browser quirks, because we’re letting the platform do the job rather than trying to write it all from scratch.
Another Lens - News Deeply x Airbnb.Design
Little interventions for designers in the form of questions designed to challenge assumptions. Kind of like Brian Eno’s oblique strategies.
The Fallacies of Distributed Computing (Applied to Front-End Performance) – CSS Wizardry – CSS Architecture, Web Performance Optimisation, and more, by Harry Roberts
Harry cautions against making assumptions about the network when it comes to front-end development:
Yet time and time again I see developers falling into the same old traps—making assumptions or overly-optimistic predictions about the conditions in which their apps will run.
Planning for the worst-case scenario is never a wasted effort:
If you build and structure applications such that they survive adverse conditions, then they will thrive in favourable ones.
Performance and assumptions | susan jean robertson
We all make assumptions, it’s natural and normal. But we also need to be jolted out of those assumptions on a regular basis to help us see that not everyone uses the web the way we do. I’ve talked about loving doing support for that reason, but I also love it when I’m on a slow network, it shows me how some people experience the web all the time; that’s good for me.
I’m privileged to have fast devices and fast, broadband internet, along with a lot of other privileges. Not remembering that privilege while I work and assuming that everyone is like me is, quite possibly, one of the biggest mistakes I can make.
kdeldycke/awesome-falsehood: Curated list of falsehoods programmers believe in.
A collection of assumptions programmers often make.
“Dates and Times” is tied with “Human Identity” for the most links.
The tough truth of reality by Chris Taylor
Progressive enhancement is not about “what if users turn JavaScript off” but “what happens when the page is loaded in sub-optimal circumstances”.
Thriving in Unpredictability - TimKadlec.com
This is the way to approach building for the web:
I want to make as few of those assumptions as possible. Because every assumption I make introduces fragility. Every assumption introduces another way that my site can break.
It’s progressive enhancement, but like Stuart, Tim is no longer planning to use that term.
susan jean robertson » Assumptions
Susan pushes back on the notion of the mythical mobile user.
The Mobile context
Yes! Yes! Yes! Mark nails it: just because someone visits a site with a certain kind of device doesn’t mean you can make assumptions about their intentions.
- Mobile != low download speed
- Context != intent