Mat has written this free course for you all about images on the web. Covering image formats, responsive images, and workflows, this is one to keep on speed dial.
Thursday, February 2nd, 2023
- Make the right thing easy
- Always answer “so what”?
- Close the gap between “something is wrong” to “we fixed it”
A person seeking help in a time of crisis does not care about TypeScript, tree shaking, hot module replacement, A/B tests, burndown charts, NPS, OKRs, KPIs, or other startup jargon. Developer experience does not count for shit if the person using the thing they built can’t actually get what they need.
Wednesday, February 1st, 2023
Imagine the web is a storefront, React is a hot dog car, and here’s Create React App dressed as a hot dog:
HTML is the cornerstone of the web — so why does creating a “React app” produce an empty HTML file? Why are we not taking advantage of the most basic feature of the web—the ability to see content quickly before all the interactive code loads? Why do we wait to start loading the data until after all the client-side code has finished loading?
Tuesday, January 24th, 2023
I quite like this change of terminology when it comes to making fast websites. After all, performance can sound like a process of addition, whereas efficiency can be a process of subtraction.
The term ‘performance’ brings to mind exotic super-cars suitable only for impractical demonstrations (or ‘performances’). ‘Efficiency’ brings to mind an electric car (or even better, a bicycle), making effective use of limited resources.
Tuesday, January 17th, 2023
Over the past 10 years or so, we’ve slowly but very surely transitioned to a state where frameworks are the norm, and I think it’s a problem.
The whole article is great, and really charmingly written, with some golden nuggets embedded within, like:
- You’ll find that spending more time getting HTML right reveals or even anticipates and evades accessibility issues. It’s just easier to write accessible code if it’s got semantic foundations.
- In my experience, you will almost always spend more time overriding frameworks or compromising your design to fit the opinions of a framework.
- Always style from the absolute smallest screen your content will be rendered on first, and use
@media (min-width)queries to break to layouts that allow for more real estate as it becomes available.
- Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing.
Wednesday, December 21st, 2022
Strong—and true—words from Alex.
Frontend’s failure to deliver in today’s mostly-mobile, mostly-Android world is shocking, if only for the durability of the myths that sustain the indefensible. We can’t keep doing this.
If you disagree, I encourage you to dive into the data that Alex shares.
Wednesday, October 19th, 2022
But just because it’s the same language doesn’t mean you should treat it the same in both circumstance. As Remy puts it:
One for the server - where you can go wild.
One for the client - that should be thoughtful and careful.
To me it seems obvious that there should an entirely different mindset for writing code intended for a web browser. But nothing’s ever really obvious.
I remember when Node was getting really popular and
npm came along as a way to manage all the bundles of code that people were assembling in their Node programmes. Makes total sense. But then I thought I heard about people using
npm to do the same thing for client-side code. “That can’t be right!” I thought. I must’ve misunderstood. So I talked to someone from
npm and explained how I must be misunderstanding something.
Wednesday, September 21st, 2022
Spoiler: the answer to the question in the title is a resounding “hell yeah!”
Scott brings receipts.
Monday, September 19th, 2022
But is it always the case that faster websites are greener websites? We reluctantly have to consider another facet: if making a website for a car manufacturer faster leads to an increase in the number of cars sold, can we really say that our website is greener?
This is very timely for me, given that Clearleft is currently engaged on a project that’s making me decidedly queasy for this exact reason—the success metrics of the project would be net negative for the world.
Thursday, September 8th, 2022
A no-nonsense checklist of good performance advice from Karolina.
Thursday, August 18th, 2022
Following on from that excellent blog post about removing jQuery from gov.uk, here are the performance improvements in charts and numbers.
Thursday, August 11th, 2022
This is a great thorough description of the process of migrating gov.uk away from jQuery. It sounds like this guide was instrumental in the process—I love that they’re sharing it openly!
Thursday, June 30th, 2022
While I’ve always been bothered by the downsides of SPAs, I always thought the gap would be bridged sooner or later, and that performance concerns would eventually vanish thanks to things like code splitting, tree shaking, or SSR. But ten years later, many of these issues remain. Many SPA bundles are still bloated with too many dependencies, hydration is still slow, and content is still duplicated in memory on the client even if it already lives in the DOM.
Yet something might be changing: for whatever reason, it feels like people are finally starting to take note and ask why things have to be this way.
Interesting to see a decade-long perspective. I especially like how Sacha revisits and reasseses design principles from ten years ago:
- Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.
It’s since become apparent that you often do need to send HTML over the network, and things seem to be moving back towards handling as much as possible of your HTML compilation on the server, not on the client.
Monday, June 27th, 2022
At the risk of grossly oversimplifying things, I propose that the core of the debate can be summed up by these truisms:
- The best SPA is better than the best MPA.
- The average SPA is worse than the average MPA.
Tuesday, June 7th, 2022
WebPageTest just got even better! Now you can mimic the results of what would’ve previously required actually shipping, like adding third-party scripts, switching from a client-rendered to a server-rendered architecture and other changes that could potentially have a big effect on performance. Now you can run an experiment to get the results before actual implementation.
Wednesday, May 11th, 2022
Broadly, these are websites which are still web pages, not web applications; they’re pages of essentially static information, personal websites, blogs, and so on, but they are slightly dynamic. They might have a style selector at the top of each page, causing a cookie to be set, and the server to serve a different stylesheet on every subsequent page load.
This rings sadly true to me:
Also, I never thought about “serverless” like this:
Recently we’ve seen the rise in popularity of AWS Lambda, a “functions as a service” provider. From my perspective this is literally a reinvention of CGI, except a) much more complicated for essentially the same functionality, b) with vendor lock-in, c) with a much more complex and bespoke deployment process which requires the use of special tools.
Friday, May 6th, 2022
We’re all LARPing on LinkedIn.
Thursday, May 5th, 2022
This is very convincing.