With a Progressive Enhancement mindset, support actually means support. We’re not trying to create an identical experience: we’re creating a viable experience instead.
Also with Progressive Enhancement, it’s incredibly likely that your IE11 user, or your user on a low-powered device, or even your user on a poor connection won’t notice that they’re experiencing a “minor” experience because it’ll just work for them. This is the magic, right there. Everyone’s a winner.
The transcript of a fantastic talk by Stuart. The latter half is a demo of Portals, but in the early part of the talk, he absolutely nails the rise in popularity of complex front-end frameworks:
I think the reason people started inventing client-side frameworks is this: that you lose control when you load another page. You click on a link, you say to the browser: navigate to here. And that’s it; it’s now out of your hands and in the browser’s hands. And then the browser gives you back control when the new page loads.
- Plan your scripts out on paper.
- Stop obsessing over tools.
- Focus on solving problems.
- Maintain a library of snippets that you can reuse.
This is a great little technique from Remy: when a service worker is being installed, you make sure that the page(s) the user is first visiting get added to a cache.
I don’t know about “perfect” but this pretty much matches how I go about implementing responsive navigation (but only if there are too many links to show—visible navigation is almost always preferable).
The Jevons Paradox in action:
Even if folks are on a new fast network, they’re very likely choking on the code we’re sending, rendering the potential speed improvements of 5G moot.
The longer I spend in this field, the more convinced I am that web performance is not a technical problem; it’s a people problem.
This is brilliant technique by Remy!
If you’ve got a custom offline page that lists previously-visited pages (like I do on my site), you don’t have to choose between
IndexedDB—you can read the metadata straight from the HTML of the cached pages instead!
This seems forehead-smackingly obvious in hindsight. I’m totally stealing this.
The way you build web pages—using
IntersectionObserver, for example—can have a direct effect on the climate emergency.
Webpages can be good citizens of battery life.
It’s important to measure the battery impact in Web Inspector and drive those costs down.
I know a lot of people swear by ES6 imports, but this systems worked really well for us. It gave us a simple, modular, extensible framework we can easily build on in the future.
I love React. I love how server side rendering React apps is trivial because it all compiles down to vanilla HTML rather than web components, effectively turning it into a kickass template engine that can come alive. I love the way you can very effectively still do progressive enhancement by using completely semantic markup and then letting hydration do more to it.
I also hate React. I hate React because these behaviours are not defaults. React is not gonna warn you if you make a form using divs and unlabelled textboxes and send the whole thing to a server. I hate React because CSS-in-JS approaches by default encourage you to write completely self contained one off components rather than trying to build a website UI up as a whole. I hate the way server side rendering and progressive enhancement are not defaults, but rather things you have to go out of your way to do.
And if you want to adjust the front-end code, you’ve got to set up all this tooling just to change a
div to a
button. That’s quite a barrier to entry.
In elevating frontend to the land of Serious Code we have not just made things incredibly over-engineered but we have also set fire to all the ladders that we used to get up here in the first place.
I love React because it lets me do my best work faster and more easily. I hate React because the culture around it more than the library itself actively prevents other people from doing their best work.
Did you know about
console.timeEnd()? I did not.
Dave enumerates the things about Vue that click for him. The component structure matches his mental model, and crucially, it’s relative straightforward to add Vue to an existing project instead of ripping everything out and doing things a certain way:
In my experience Angular, React, and a lot of other frameworks ultimately require you to go all in early and establish a large toolchain around these frameworks.
This post was originally written in 2015, but upon re-reading it today, it still (just about) holds up, so I finally hit publish.
Chris succinctly describes the multiple-
iframes-with-multiple-codebases approach to web development, AKA “micro frontends”:
Time to Interactive (TTI) is the most impactful metric to your performance score.
Therefore, to receive a high PageSpeed score, you will need a speedy TTI measurement.
At a high level, there are two significant factors that hugely influence TTI:
When people talk about learning React, I think that React, in and of itself, is relatively easy to understand. At least, I felt it was. I have components. I have JSX. I hit some hiccups with required keys or making sure I was wrapping child elements properly. But overall, I felt like I grasped it well enough.
Throw in everything else at the same time, though, and things get confusing because it’s hard at first to recognize what belongs to what. “Oh, this is Redux. That is React. That other thing is lodash. Got it.”
This resonates a lot with Dave’s post:
React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.
If you ignore the slightly insulting and condescending clickbaity title, this is a handy run-down of eight browser features with good support:
- extra arguments in
- extra arguments in
defaultCheckedproperty for checkboxes,
wholeTextfor strings of text,