前几天，我在 Sparkbox 进行的一场研讨会上，收到了来自 Bryan Braun 的一个非常棒的问题。他问，这些年来，我是否有过一些关于网页设计和开发的强烈观点，而现在我已经不再坚持了。
当时我并没有很好的答案，尽管如果我能倒带我的大脑，肯定会在其中找到一些令人尴尬的观点。
冒着自我吹嘘的风险，这正是我努力保持开放心态的原因。如果你不这样做，最终就会自食其果。为了什么？当你贬低一个想法时，当时听起来像个傻瓜，而且可能造成的危害大于好处。如果你最终是对的，你仍然是个傻瓜。如果你最终错了，你就是个傻瓜加蠢货。
我喜欢“网络是一个很大的地方”这句话。这是一种快速的方式来说明，在一个如此庞大、规则宽松、多样性十足且受经济巨头控制的游乐场中，并没有绝对正确的答案。
不过，我不想完全回避这个问题。
我听 Trent Walton 说过很多次，尽管他现在完全投入了响应式网页设计，但起初他觉得这是一个非常糟糕的想法。
我记得自己很晚才接触到 CSS 预处理的世界，因为我花了数年时间对它嗤之以鼻。我认为这是后端极客把鼻子伸到不该伸的地方，把编程带到了不需要它的地方。回想起来，这主要是因为我害怕学习将它融入工作流程所需的工具。
现在已经不太容易看到行业范围内的圣战了，在这些圣战中，人们持有坚定的观点，随着时间的推移，这些观点最终会互相妥协。
但是那些内心的个人斗争呢？我非常想听听大家对此的看法……
你过去对网页设计和开发有什么强烈持有的观点，但现在不再坚持了？
应该尽可能地使用原生标签样式，并使用最少的简单类名，例如
.button和.menu是的，我认为对我来说最大的一点是几年前的反类名主义……总是为实际的 HTML 元素（如
<h1>）设置样式，谨慎使用类名……完全干净的标记。现在几乎完全相反了。在设计层 CSS 中（主要是）看到 HTML 元素选择器会让我尖叫，而 BEMITCSS/命名空间类名/模块化设计使我的标记变得杂乱无章！
我曾经非常反感推送通知。当一个网站在我不知道内容是否好的情况下弹出窗口询问我是否要接收通知时，我发现这非常烦人。
我仍然非常反感这一点，但这仅仅是推送 API 的糟糕实现。
在我的 NSFW 宠物项目 Naughty dot Audio 中，我想出了如何正确实现它，因此除非用户在页面上专门点击订阅按钮，否则不会弹出窗口，然后它使用客户端中的 Ajax 和后端中的 DB 允许用户控制他们接收哪些通知。
这提高了用户隐私，因为他们可以订阅以获取特定艺术家的更新，而无需透露他们的电子邮件地址。并且，只有当用户已经决定要订阅并点击一个普通的按钮表示他们确实想要订阅时，才会出现烦人的弹出窗口询问他们是否想要通知。
可惜我还没有看到其他任何网站以不烦人的方式实现它。
我对推送通知的看法也完全一样……目前它们对我来说更烦人而不是有用。:/
我想说的是，我年轻的时候对编码和开发有很多强烈持有的观点。我总是“完善”我的代码，学习最新最好的工具，最终我认为，会想出一个完美的架构。年轻的我，以及我强烈的观点，非常擅长探索各种复杂的解决方案，但不太擅长完成任何事情——完美的架构是已完成项目的敌人。
我想说的是，年长的我对于代码和开发几乎没有强烈的观点。我从这些经历中学到，无论我多么努力地完善我的代码，6个月后我回头看看，就会发现我早就以不同的方式做事情了。尽管错过了很多截止日期，也进行了无数的争论，但我从未达到完美。几年后，我回过头来看，一些工具甚至语言已经逐渐消失，我曾经对它们的所有强烈观点都不算什么了。
今天的我仍然希望变得更好，学习更多，但对工具、语言和架构有了更务实的看法。我当然仍然有自己的观点，但它们更容易受到挑战。
许多年前，一位导师对我说
“一旦你写完一行代码，它就变成了遗留代码”
我有。应用程序缓存。
伤心 :(
永远不要使用 JavaScript 光标轨迹。
这种观点源于它们在 2000年代初期 的样子。
事实证明，我的问题更多地与执行有关，当我遇到更微妙、更优雅的使用方式时，这一点变得更加明显了。
Lorenzo Bocchi
Nurture Digital
我唯一坚持的观点是，ID 不用于样式设置。它们太强大。随意将其用于 JS，但当我在 CSS 文件中看到它们时，我会变得挑剔，因为我知道在某些时候我必须处理它，而且处理起来不会很漂亮。
我嘲笑用 BEM 命名类名的想法。所有那些愚蠢的下划线。现在我在每个项目中都使用它，并且非常喜欢它。
在任何类型的编辑器中选择它们当然有助于推动使用 BEM 的决定 :)
尽管我仍在继续使用我的“前时代”BEM 样式。在预处理器时代，它很难做到，因为预处理器生成的代码看起来非常丑陋。
再见，w0lf。
网站在禁用 JavaScript 时能够正常显示和工作非常重要。我现在认为，只要网站在禁用 JavaScript 时能够正常运行就足够了，因为禁用 JavaScript 的用户通常很少，而且永远没有足够的预算来编写所有复杂的回退。
实现至少在 1.5 年内由现代 Web 浏览器正式支持的功能
正如 Davide 提到的，使用简短的类名
倾听自己的内心，只考虑别人的意见
不要在不深入了解和阅读文档的情况下使用现成的框架
速度仍然以毫秒为单位很重要，除此之外，我们从奔腾 333mhz 发展到 8 x 2.4ghz 内核
不要听取工匠开发人员 <> 程序员的意见
对我来说，它是编码风格。我对制表符与空格、括号的位置等等有非常强烈的看法。然后我回顾了自己的代码，发现随着时间的推移，我的风格一直在微妙地变化，并且发现它比我看到的许多代码示例更难以理解。答案是抛开我的自负，采用我的 IDE 可以执行的编码标准。我的代码现在非常容易阅读，并且我成为了代码审查的布道者。归根结底，空格/制表符/括号/换行符并不像一致性那么重要。
告诉我更多。
HTML 中的类是神圣的，不能用于实用程序类或表现类。
所有网站都应该在 JavaScript不可用时正常工作。
构建单页应用程序改变了我对这个问题的看法。不过我仍然认为，如果一个网站主要是为了阅读内容，那么在没有 JavaScript 的情况下提供这些内容，在大多数情况下可能会让你的开发生活更轻松，并为所有用户提供更好的体验。
连字符与下划线。我来自 PHP，所以下划线占主导地位。此外，我喜欢它们在 URL 中，因为它们就像假的空格（可以自动替换普通用户输入的空格）。我仍然在我的类中使用它们，因为 JS/PHP 兼容性很好，但我现在看到了连字符的真正价值，例如类名中的连字符分隔选择器。并且我看到了尽可能遵循行业标准的价值（在行业做出明智决策的情况下）。（此外，无需按 Shift 键，很懒，但这算是一种安慰奖）
关于强烈意见的一点评论。我从老前辈那里学到了很多关于如何做事和不做事的方法。我始终避免的一件事是在所有事情上都追求最新技术。硬件（总是使用去年的 CPU 或更旧的 CPU，RAM - 只有 8GB 哈哈，等等…），软件 - 我很少使用 Adobe 的最新和最棒的软件，甚至强迫自己学习开源软件（GIMP、Inkscape），在软件方面，我避开了过去 20 年里所有 CSS/HTML/JS 的技巧。所有这些的原因都是因为我一开始是一个贫穷的学生，这对我很有帮助。
因此，当行业每年都在变化 20 年时，很难坚持某种信念或方法。由于我没有使用技巧或流行框架，因此我从未不得不重做我的任何网站*。我错过了基础的剧变，并且由于我可以看到浏览器更新即将到来，这些更新将取代这些技巧，所以我一直没有使用阴影（尽管我确实做了一段时间很糟糕的图片处理），没有花哨的字体（Flash 字体，恶心），没有圆角（像阴影一样，我尝试了一段时间，真是乱七八糟），等等…因为很明显，这些都是锦上添花的东西。
现在，行业已经发展，浏览器支持也非常好。
因为我在时间和金钱上都很贫乏，这让我免于浪费我仅有的一点资源。现在，我牢记这些概念，以帮助我远离下一个浪费大量时间/金钱的陷阱…
Prototype.js
（忏悔 - 全屏 Flash 开场动画…*叹息*但我们讨厌它们，即使我们制作了它们）
这句话我赞同无数次。这样做不仅可以让你编写更好、更精简的代码，还可以避免在 3000 美元的 27 英寸视网膜 iMac 上使用光纤进行代码开发，而在工作完成后，80% 的访客将使用 250 美元的宏碁笔记本电脑通过不稳定的 ADSL 连接访问网站。
我过去很喜欢单行 CSS 类。我用于完整网站的样式表只有 140 行长！
.header { background: black; color: white; }
.header h1 { font-size: 22px; }
h1 a { display: block; }
WordPress
当然，尽管许多人已经接受了它（我怀疑主要是出于底线的原因），但仇恨仍然像以前一样强烈。
我经常评论说，许多 PHP 开发人员对 WordPress 的厌恶与 Ruby/Java/等开发人员对 PHP 的厌恶一样强烈。告诉 PHP 开发人员这一点，他们就会有点不高兴。
我曾经是我团队中最好的开发者，所以我的所有知识都像圣经一样。然后我换到了另一个团队，在那里我只是一个普通的开发者，突然间，我的绝对规则被比我更优秀的人动摇了，很快就被拆除了，我不得不承认我错了，但我有了新的圣经信息，所以我可以确信它们。
我又换了工作…时间告诉我，观点可能会改变，环境可能不同，技术会发展，你必须准备好改变…
我想说，今天，我仍然对某些事情有强烈的看法，但我已经知道它们可能会改变，我已为此做好了准备，我只是等待一个好的理由。
一句可能的格言：如果你与某人长时间争论后最终获胜，他改变了主意，这意味着你输了：你什么也没学到。
CMSmadeSimple、WordPress、非特定 CSS、不喜欢应用程序、认为 Firefox OS 会成为主流、用 jQuery 而不是原生 JS 解决所有问题、认为 Linux 太复杂、让客户自己选择主机、认为意大利面条式 PHP 比框架中的代码写起来更快、使用 phpMyAdmin 而不是 Adminer、远离图形设计、不关心字体、它们的许可证和它们的实现、加载外部资源、认为 Google 是一家伟大的公司、喜欢 Facebook……我可以一直说下去。
似乎仍然是一个普遍的观点。显然，所有人都认为它只有命令行界面；而且这个谣言已经流传了很久。不过，我从未理解过这一点。从大约 2000 年开始，我就一直使用 Linux 作为我的辅助（和备用）操作系统，并在 2006 年完全切换到它。到目前为止，我还没有回头（除了 Photoshop 和 IE；那是为虚拟机准备的）。
甚至我的妹妹，她以不是真正的科技爱好者而闻名[1]，也发现日常使用的 Ubuntu/Debian 非常易于使用，并且奇怪地（？）非常喜欢（并且熟练地）使用命令行。
再见，w0lf。
[1] 她不是一个在技术方面笨手笨脚、无能的人（恰恰相反），但她只是不喜欢过分依赖它，尤其是电脑。
Linux 太复杂？嗯。
我一直认为它太简单了，无法实现复杂的功能。或者认为强大功能是以冗长和大量输入为代价的。但这只是一个短暂且非常愚蠢的假设。
简单的事物中蕴藏着优雅和力量。
作为电子商务零售商的前端工程师
我过去一直坚信，特定页面组的每一部分 JS 都需要被捆绑、管理并为该组中的所有页面提供服务。
直到我发现很多代码都在为特定产品提供特定且独特的用例和场景，所以我现在坚信后端应该负责通过数据库包含这些代码片段。
同样有趣的是我们抵制的事情，结果证明它们和看起来一样毫无意义。
需要指出的是，拥有强烈意见与思想开放是完全兼容的。我坚信每个人都应该拥有有充分理由的强烈意见。我们的世界在强烈意见的推动下前进。这适用于所有事物，包括技术。
但这并不意味着意见不应该改变。当有人用论点证明另一种意见比我们的意见更好，或者当时间推移，昨天客观上正确的事物不再正确时，它们应该改变。
如果你今天问医生服用什么药来治疗发烧，她必须给你目前已知最好的药。当然，如果一个 Web 开发人员没有使用“最好的”工具，没有人会因此而死亡，但这并不意味着我们不应该知道什么是最好的工具（始终在特定环境下）。
我曾经认为可访问性是一个不错的附加功能，但在构建网站时最终是一个次要的考虑因素。直到我参加了一个可访问性会议，并且不得不面对那些网络因像我这样的人而变得无法使用的人。如今，我认为我有责任尽可能地使我构建的一切都易于访问，即使特定项目没有将可访问性纳入范围。