翻译：没有那个是错的

原文链接： https://css-tricks.com/nobody-is-quite-wrong/

原文：

There are two opposing views on using non-polyfillable new web features that I find are both equally common in our industry:

1. 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.
2. 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.

 

译文：（本人水平有限，英文是渣渣，所以出错希望轻喷）

我发现，在我们的行业中，关于使用浏览器不支持的新web特征,有两种截然不同的观点：

　　1、网站不需要在所以的浏览器中看起来都一样。渐进增强的概念能够对这种观点有些帮助，有一些使用编程语言的工具能够帮助我们实现这一点。

　　2、如果浏览器支持不是我想要的，那么它看上去只是一个异国风情的演示，而不应该被使用。

我不会很肯定的说某一个观点比另外一个更正确。

我认为，我支持1的观点并不另人奇怪。设计和实现在不同浏览器和条件下表现不同的东西是完全可能的。这就是现在互联网上的响应式设计。

渐进增强的基础在于我们可以在任何地方开始工作，尽可能的从设计与功能上进行分离。甚至有一些编程语言特征支持这个想法，@supports规则允许我们写css的时候判断是否支持这个特性，如果支持就执行，不支持，就不执行。

这个是整个使用的上面的例子的库Modernizr，它在github上有22804个星星。（现在不止这个数）

我不想针对渐进增强去争论些什么。记住，我刚才说过我支持这个想法，但我确实对于那些不去尝试渐进增强的人和团队表示同情，最终产生了更多偏向于2的想法。

开发和设计适应不同场合的功能需要花费大量的工作。这些工作绝对非常有用，或者也不太有用。不过，它确实能够使事情复杂化，这表示更多的代码，需要更多的精力和测试，并且很难去理解。这是技术债务。

让我们更进一步去考虑一下：technical debt can be fine，技术债务是好的，甚至可以故意使用它。它存在于我们构建的所有项目中，我的观点是，合理聪明的承担一点技术债务能够在以后更好的维护你的项目。

你可能认为，建立在渐进增强上的技术债务比较小，因为我搭建项目的基础比较牢固，以至于只需要少量的测试和不断的完善就行了。也许吧！

我确实像是观点2。它使你感觉更安全，它使你感觉更加有责任心和谨慎。“嗨，那真是整洁”你会想到“我会在几年后再去看看（渐进增强），看是否能在项目中使用”。我可能和你争辩：1、这个玩笑并不有趣，2、你的想法是错误的。这使你不愿意接受渐进增强的方法，最终会导致你的代码变得脆弱。

这两种观点并没有那个是错的，采用那种观点，依赖于你的想法，依赖于技术债务的重量，依赖于团队和开发者的流失率，依赖于文档，依赖于正确的测试方法！

你写项目的时候有想到这些吗？