There are two opposing views on using non-polyfillable new web features that I find are both equally common in our industry:
- Websites don’t need to look the same in every browser. The concept of progressive enhancement helps with that. There are tools, even native language features, that help with this.
- If browser support isn’t where I want it to be, it’s just exotic eye candy for demos and not to be used.
I’m not sure I’d say either one of these is more or less correct than the other.
I also imagine it doesn’t come as much of surprise that I support the thinking behind #1. It’s perfectly possible to design and implement things that behave differently in different browsers and conditions. That’s essentially what responsive design is, and that’s pretty much the entire internet now.
The backbone of progressive enhancement is starting with a working foundation that works everywhere and layering design and functionality on top of that, when possible. There are even native language features to support the idea. @supports rules allow us to write CSS that can do something if a feature is supported and do something else if it isn’t.
This is the entire use case for Modernizr and it has 22,804 stars.
I don’t want to argue against progressive enhancement. Remember, I just said I support that thinking. But I do have some empathy for people and teams that choose not to go there, and end up developing more of a #2 attitude.
It is a bit more work to develop and design features that work in different ways. It might be work that is absolutely worth doing. Or it might not. Either way, it does complicate things. It’s more code, it requires more attention and testing, and it’s a bit harder to reason. It’s technical debt.
Let me be preemptively defensive again: technical debt can be fine, and even intentional. We all incur it in everything we build. My point is that it is helpful to be smart about it and take on an amount of technical debt that is feasible for you to look after in perpetuity.
You might argue that building on a progressive enhancement foundation is, in a sense, less technical debt because you’re building on such a sturdy foundation that less testing and constant tending to is required. Perhaps!
I do get behaving like a #2. It feels safer. It feels like you’re being cautious and responsible. “Hey that’s neat,” you think. “I’ll revisit it in a few years to see if I can use it for real.” I might argue that 1) that’s no fun and 2) almost counter-intuitively, it means you aren’t willing to take a progressive enhancement approach which may make your code ultimately more frail.
It depends, I suppose. It depends on what exactly you’re trying to do. It depends on the weight of that techinical debt. It depends on the team and the rate of developer churn. It depends on documentation. It depends on testing and QA.
You do you.
The post Nobody is quite wrong. appeared first on CSS-Tricks.
