SPAs were a clever solution to a temporary limitation. But that limitation no longer exists.
Use modern server rendering. Use actual pages. Animate with CSS. Preload with intent. Ship less JavaScript.
This is a really thoughtful look at the evolution of CSS and the ever-present need to balance power with learnability.
Grrr…
Chrome, Edge and Firefox updates usually reach 95% of users within three months. But Safari updates are tied to a new release of the underlying operating system, so they take around 19 months to reach the same usage, and some updates may even need a new device.
This is so shameful. And glad as I am to see new features landing in Safari, as long as they hobble updates like this it’s all just pissing in the wind.
An excellent appraisal of the importance of the rule of least power.
The joy came flooding back to me! It turns out browser APIs are really good now.
It seems like the misguided perception of needing to use complex tools and frameworks to build a website comes from a thinking that web browsers are inherently limited. When, in fact, browsers have evolved to a tremendous degree
Nice to see Clearleft’s browser support policy get a shoutout from Rachel during her Google IO talk.
A great talk by Matthias on what you can do with web standards today!
This is an interesting proposal for a declarative way of triggering permission dialogs, although it seems to overlap with the work being done on invokers (command and commandfor).
What really disgusts me is to see Google referring to this element as though it’s a done deal. It’s not. It’s a proposal …a proposal that Apple rejects and Mozilla rejects.
Words matter. Call your proposal a proposal, Google.
Update: They fixed it!
I should be using the lh and rlh units more enough—they’re supported across the board!
Here’s a fun account of the early days of the ARPANET.
I really like the idea of unifying some layout values in CSS. If you’ve got any feedback, please chip in!
A handy one-pager for front-end web developers:
Here are ways to keep track of what you can use, of what’s new in web browsers, and ways you can influence the development of the platform by making your voice heard.
About halfway through this talk transcript, Aaron starts dropping a barrage of truth bombs:
I understand the web, whose distinguishing characteristic is asynchronous recall on a global scale, as the technology which makes revisiting possible in a way that has genuinely never existed before the web.
What the web has made possible are the economics of keeping something, something which has not enjoyed “hockey stick growth”, around long enough for people to warm up to it. Or to survive long past the moment when people may have grown tired of it.
If your goal is to build something which is designed to flip inside of ten years, like many things in the private sector, that may not seem like a very compelling argument.
If, however, your goal is to build something to match the longevity of the cultural heritage sector, to meet the goal of fostering revisiting, or for novel ideas to outlast the reluctance of the present and to do so at a global scale, or really any scale larger than shouting distance, then I will challenge you to find a better vehicle for doing so than the internet, and the web in particular.
If you’re roughly 70% happy with a piece of writing you’ve produced, you should publish it.
Works for me!
You’re also expanding your ability to act in the presence of feelings of displeasure, worry and uncertainty, so that you can take more actions, and more ambitious actions, later on.
Crucially, you’ll also be creating a body of evidence to prove to yourself that when you move forward at 70%, the sky stubbornly fails to fall in. People don’t heap scorn on you or punish you.
- Springy easing with
linear()- Typed custom properties
- View transitions for page navigation
- Transition animation for
dialogandpopover- Transition animation for
details- Animated adaptive gradient text
If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.
Excellent advice from Harry (who first cast his pearls before the swine of LinkedIn but I talked him ‘round to posting this on his own site).
- Opt into web platform features incrementally
- Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context
- Write code that leans into the browser, not away from it
I’m not against front-end frameworks, and, believe me, I’m not naive enough to believe that the only thing a front-end framework provides is soft navigations, but if you’re going to use one, I shouldn’t be able to smell it.
Remember when every company rushed to make an app? Airlines, restaurants, even your local coffee shop. Back then, it made some sense. Browsers weren’t as powerful, and apps had unique features like notifications and offline access. But fast-forward to today, and browsers can do all that. Yet businesses still push native apps as if it’s 2010, and we’re left downloading apps for things that should just work on the web.
This is all factually correct, but alas as Cory Doctorow points out, you can’t install an ad-blocker in a native app. To you and me, that’s a bug. To short-sighted businesses, it’s a feature.
(When I say “ad-blocker”, I mean “tracking-blocker”.)
I hold this truth to be self-evident: the larger the abstraction layer a web developer uses on top of web standards, the shorter the shelf life of their codebase becomes, and the more they will feel the churn.