Some great ideas for view transitionts in here! Also:
If you look at any of the examples on a browser that does not support them, the pages still function just fine. The transitions are an extra that’s layered on top if and when your browser supports them. Another concrete example of progressive enhancement in practice.
- Start with mostly static HTML.
- Progressively enhance the dynamic parts.
- Pick small, focused tools.
I have a very simple rule that serves me well: Don’t think too much about your life after dinnertime.
Ahmad runs through some of the scenarios where text-wrap: balance could be handy.
Even though it’s not well-supported yet in browsers, there’s no reason not to start adding it to sites now; it’s classic progressive enhancement.
After admiring the loveliness of the homepage for Enhance, try reloading it with JavaScript switched off.
Spot the difference? Me neither.
So, if progressive enhancement is no more expensive to create, future-proof, provides us with technical credit, and ensures that our users always receive the best possible experience under any conditions, why has it fallen by the wayside?
Because before, when you clicked on a link, the browser would go white for a moment.
JavaScript frameworks broke the browser to avoid that momentary loss of control. They then had to recreate everything that the browser had provided for free: routing, history, the back button, accessibility features, the ability for search engines to read the page, et cetera iterum ad infinitum.
Oh no! My claim has been refuted by a rigourous scientific study of …checks notes… ten people.
Be right back: just need to chat with eleven people.
An entire generation of apps-that-should-have-been web pages has sprung up, often shoehorned into supposedly cross-platform frameworks that create a subpar user experience sludge. Nowhere is this more true than for media — how many apps from newspapers or magazines have you installed, solely for a very specific purpose like receiving breaking news alerts? How many of those apps are just wrappers around web views? How many of those apps should have been web pages?
Instead of doing what the competing browsers are doing (and learning from years of experience of handling Web Push), Apple decided to reinvent a wheel here. What they’ve turned up with looks a lot more like a square.
A very astute framing by Ted Chiang—large language models as a form of lossy compression for text.
When we’re dealing with sequences of words, lossy compression looks smarter than lossless compression.
A lot of uses have been proposed for large language models. Thinking about them as blurry JPEGs offers a way to evaluate what they might or might not be well suited for.
Write meaningful HTML that communicates the structure of your document before any style or additional interactivity has loaded. Write CSS carefully, reason your methodology and stick to it, and feel empowered to skip frameworks. When it comes time to write JavaScript, write not too much, make sure you know what it all does, and above all, make sure the website works without it.
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.- If your site doesn’t work without JavaScript, your site doesn’t work.
- Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing.
Styling a list of nested details elements to create a beautiful lokking tree view, all in CSS, all nicely accessible.
It is not an exaggeration to say that modern frontend is so enamoured by post-scarcity fairy tales that it is mortgaging the web’s future for another round of night drinking at the JavaScript party.
Strong—and true—words from Alex.
This isn’t working for users or for businesses that hire developers hopped up Facebook’s latest JavaScript hopium. A correction is due.
I concur.
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.
A look at back at what wasn’t in the headlines this year.
But you can’t have a web app without a web-app-compatible browser, and you can’t get a web-app-compatible browser in Apple’s App Store. The only browsers permitted in the App Store are those based on WebKit, the browser engine behind Safari. This means that every browser on iOS, from Firefox to Edge to Chrome, is just a reskinned version of Safari.
It sounds like Remix takes a sensible approach to progressive enhancement.
What happens if the ‘pace layers’ get out of sync?
A very thoughtful post by Miriam on how tools can adversely affect the pace of progress in the world of web standards.
When tools intervene between you and your access to the web platform, proceed with caution. Ask not only: How well does it work? But also: How well does it fail? Not only: What features do they provide? But also: What features do they prevent?
I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.
But Brad makes the interesting point that, because they were incubated when profligate client-side JavaScript was all the rage, web components may have ended up inheriting the wrong mindset:
So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.
There are two JavaScripts.
One for the server - where you can go wild.
One for the client - that should be thoughtful and careful.
Yes! This! I’m always astounded to see devs apply the same mindset to backend and frontend development, just because it happens to be in the same language. I don’t care what you use on your own machine or your own web server, but once you’re sending something down the wire to end users, you need to prioritise their needs over your own.
It’s the JavaScript on the client side that’s the problem. What’s given to the visitor.
I’d ask you, if you’re still reading, that you consider a separation of JavaScript between client and server. If you’re a dev, consider the payload, your bundle and work to reduce the cost to your visitor. Heck, think progressive enhancement.
The primary benefit of Progressive Enhancement is not that “your app works without JavaScript” (though that’s a nice side-benefit) but rather that the mental model is drastically simpler.
I think that’s the primary benefit to developers. The primary benefit to users is that what you build will faster and more resilient.
Anyway, this is a really good deep dive into different architectural choices for building on the web. Although I was surprised by this assertion in the first paragraph:
The most popular architecture employed by web developers today is the Single Page App (SPA)
Citation needed. Single Page Apps do indeed dominate the discussion, but I don’t think that necessarily matches the day-to-day reality.