I'm a huge fan of @csswizardry, but is this a hot take or no? #HTML

https://csswizardry.com/2025/02/html-is-not-a-programming-language/

This post by @csswizardry is a great variation on the « Always bet on the web platform » theme

https://csswizardry.com/2025/01/build-for-the-web-build-on-the-web-build-with-the-web/

🧠 Yesterday’s thread now has a permanent (and expanded) home: https://csswizardry.com/2025/01/build-for-the-web-build-on-the-web-build-with-the-web/

I’m not against front-end/JS frameworks, but if you’re going to use a front-end framework, I shouldn’t be able to smell it.

.@nolan said it best when he said ‘the best SPA is better than the best MPA; the average SPA is worse than the average MPA’.

Each layer of abstraction made in the browser moves you further from the platform, ties you further into framework lock-in, and moves you further from fast.

The web as a platform is a safe bet. It’s un-versioned *by design*. That’s the commitment the web makes to you—take advantage of it:

💡 Opt into web platform features incrementally;
💡 Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context;
💡 Write code the leans into the browser, not away from it.

The saddest part of it all is that these were ex-clients who had to re-hire me because with the ‘upgrades’ came severe site-speed regressions. As good as it may be for business, I hate going through the same work with the same client more than once. After all, you should never need to call pest control twice.

In the last year alone, I have seen two completely different clients in two completely different industries sink months and months into framework upgrades. Tens, if not hundreds, of thousands of dollars rewriting entire projects just to maintain feature parity with the previous iteration. This is not meaningful or productive work—it is time sunk into just keeping themselves at square one. A form of open-source vendor lock-in.

🌐 If you’re going to build for the web, build *on* the web.

If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.

@zachleat div-onclick

📺 A cautionary tale about JavaScript, LCP, and reading the spec: https://www.youtube.com/watch?v=WJHzuIBab2U

🔮 Want to maximise the impact of your Speculation Rules? Get the lowdown right here: https://csswizardry.com/2024/12/a-layered-approach-to-speculation-rules/

Last night, I made some purely cosmetic changes to my Contracts Starter Pack. Existing customers should get the updates automatically, new customers should get them immediately: https://csswizardry.gumroad.com/l/contracts-starter-pack

@scottjehl @wesbos and it’s fast in spite of itself, not because of. I was gonna do a response but I’m not sure I have the energy 😅

🚀 I’ve often joked about a website so fast it turns up before anyone even asked for it. Well guess what… https://github.com/csswizardry/csswizardry.github.com/commit/77285ba766bf94aed2a9fc66e10c91cef57d9f0a?diff=unified

@argyleink @Kilian A little too similar… can you choose not-pink as the colour? My ‘logo’ predates even the JS logo.

⏱️ The CrUX report has recently begun including RTT (latency) data. What can we do about it? It turns out, quite a lot! https://csswizardry.com/2024/09/optimising-for-high-latency-environments/?utm_source=mastodon&utm_medium=social

🧭 With CrUX now including navigation information, what kinds of optimisations have we been missing out on? And how do we fix them? https://csswizardry.com/2024/08/cache-grab-how-much-are-you-leaving-on-the-table/

🚧 I wrote a primer on blocking resources and how to hack around them. The last tip is actually one of my favourite bits of webperf trivia: https://www.linkedin.com/posts/csswizardry_blockingness-a-primer-i-just-published-activity-7229469512662745088-2GBT?utm_source=share&utm_medium=member_ios