HTML 和 CSS 通常被视为负担。
这是我在过去与合作过的工程师和设计师身上观察到的感受，也是更广泛的网络社区中更为明显的观点。您可以在 Medium 文章和独立博客中听到这种观点，无论是在 关于 CSS 的讨论、网络性能还是设计工具中。
这种观点认为前端开发是一个需要解决的问题：“如果我们拥有正确的工具和框架，那么我们可能永远都不需要再编写一行 HTML 或 CSS 代码了！” 哦，天哪，那该是多么美好的梦想啊，对吧？
好吧，实际上并非如此。我当然不认为前端开发本身就是一个问题。
这种感觉背后的原因是什么？嗯，设计师希望拥有能够让他们绘制图片并导出批量的 CSS 和 HTML 文件的工具，就像 Dreamweaver 当年承诺的那样。另一方面，工程师不想为可访问性、网络性能或焦点状态等众多问题而烦恼。边缘情况太多，设备太多，浏览器太多，让人难以应对。工作量实在太大。
因此，作为一名设计师/开发人员，我能够理解这些感受，但当我阅读到有人与 Bootstrap 或设计系统、框架或 CSS-in-JS 解决方案（甚至像 Sketch 或 Figma 这样的设计工具）的关系时，我仍然会感到有点恼火。看起来，我们将前端开发视为一种负担，或者说，我们希望通过工具层来抽象它，从而完全避免它。
我们应该将前端开发视为一项独特的技能，对任何项目的成功都至关重要。
我相信这就是为什么像 Bootstrap 这样的框架和工具如此受欢迎的原因；不一定是它们是一组有用的组件，而是一个纠正固有问题的世界性解决方案。而当我开始在多个前端应用程序的简历中看到“Bootstrap”时，我立即会认为，我们在设计和开发方面的方法将会存在差异。
然而，Bootstrap 并不是一项技能——前端开发才是。
这并不是我仅仅在故作老学究……我希望如此。我真心希望能够有工具帮助我们做出更好的决策，帮助我们以推动网络发展的方式构建更易访问、更快速、更漂亮的网站。也就是说，我相信围绕这些工具建立的社区鼓励了一种忽视前端技能和标准的设计和开发方式。
如果最终会被其他工具和语言转译，学习原生 HTML、CSS 和 JavaScript 有什么意义呢？
不要误会我的意思——我并不认为 Bootstrap、CSS-in-JS、CSS Modules 或花哨的设计工具有什么问题。但围绕这些工具的局限性来构建我们的职业生涯却是一场小小的悲剧。前端开发之所以复杂，是因为设计本身就很复杂。将我们的口语转译成 HTML 和 CSS 需要技巧和细致入微，而且永远如此。这不会通过工具来解决，而是需要长期不懈地努力。
我认为 HTML 和 CSS 值得获得更好的待遇，而不是被处理、编译并输出到浏览器中，无论这是通过某些构建过程、应用程序导出还是我们半懂半不懂的庞大框架库。HTML 和 CSS 是两种值得我们细心关注和重视的语言。编写它们是一项技能。
我知道我在这里站在一个隐喻的讲台上，也许我有点戏剧化，但前端开发并非需要解决的问题。它是网络的基石，而且在不久的将来不会消失。
是吗？
说的好！
您比我表达得更好！
也许是因为我从 IE6 还是个问题的时代就开始做前端了，当时网站正在从表格转向语义化 HTML，但现在的前端开发真是太棒了！
我们有 Flexbox、SVG 支持、RGBA、HSL 支持……在所有浏览器上！只有我一个人对这件事感到非常高兴吗？
您不是唯一一个对此感到高兴的人！我当然也是！浏览器技术的进步是因为人们意识到了网络的重要性。由于世界发现了网络，前端开发可能成为一个合法的职业领域。这通常遵循以下步骤：用户研究、认识设计工作、使设计成为现实，并发布！当然，其中还有很多其他细节。
我完全同意。浏览今天的 Stack Overflow 或子版块令人沮丧。前几天我看到一个帖子标题是，“如何在没有框架的情况下制作一个网站？” 当我刚开始的时候，这可是基本的能力要求。现在却成了一个边缘话题，让人好奇。人们表现得好像他们需要与 CSS 搏斗一样，而它恰恰是我们拥有的最直接、最声明式的语言之一。我们过去曾经避开 Dreamweaver 用户，因为他们可以通过拖放操作，导致代码质量低下且缺乏理解。现在我们又回到了原点，新一代人再次依赖他们不完全理解的工具，不必要地使简单的事情复杂化。
好文章！我也看到了同样的 HTML 和 CSS 态度，我永远无法接受“因为 CSS 很烂”作为使用工具或框架的正当理由。
我已经记不清有多少次不得不斥责初级开发人员拒绝创建客户想要的前端，因为 Bootstrap 不允许他们这样做，并且想出一些拙劣的解决方案来避免真正理解 html/css/js 如何相互配合。我希望有一种方法能让开发人员认真对待前端工作。
我真的很感谢这篇文章。我担心有一天我们会拥有“完美”的 HTML 和 CSS 转译器来以“正确”的方式完成所有事情，而网络会变成一片平淡无奇的同质化粘贴内容。
我认为我们将 HTML 和 CSS 视为问题的原因是，这些标准最初并非为我们现在使用它们的目的而设计的：创建丰富的用户界面。每个为了适应我们期望创建的 CSS 小部件而使用的非语义 HTML 标签，每个为了修复这些非语义标签带来的问题而需要的可访问性属性，每个旨在使我们的解决方案不那么“笨拙”但仍然需要支持不支持这些新 CSS 标准的浏览器的 CSS 模块——所有这些都太繁琐、太令人筋疲力尽了。
HTML 和 CSS 的用途是文档标记和样式，但我们几乎不再制作文档了。
我同意 HTML/CSS 的文档导向是问题核心的一部分。对我来说，感觉我们一直在添加 CSS 模块，而从一开始就假设为丰富的用户界面而设计的全新事物可能更好。
我一直都知道 Vim 比 Emacs 好。
谢谢，Robin！我完全赞同您的观点。对我来说，当所谓的“网页设计师”或“网页开发人员”想要绕过处理 HTML 和 CSS 时，这不仅仅是有点烦人。不要让我开始谈论在不首先理解并能够阅读和调试（如有必要）网站或 Web 应用程序的文件和文件夹结构的情况下使用包管理器！这就像一个外科医生走进手术室，希望他/她能够闭着眼睛和对人体解剖结构的粗略了解就完成手术一样。
问题在于行业没有给专业人士机会去热爱它们。不可能找到招聘信息，其中人们期望你关心 HTML 和 CSS。如果你是一位前端工程师，人们更关心性能、算法，而不是它们。如果你想关心，没问题，但这是一个额外的义务，因此感觉它是一种负担。
如果你是一位过去曾制作网站的老派前端开发人员，那真是太可怜了，因为如果你想赚钱，每个人都期望你停止这样做。
问题不在于技术，而在于前端开发的期望和边界。
完全同意。这意味着您知道 HTML 和 CSS。它被视为每个开发人员在某种程度上都知道的“次要技能”。因此，到目前为止，最好的“解决方案”是告诉设计师他们应该学习如何编码。翻译过来就是：“我不想处理 CSS，让设计师为我做这些脏活。”
归根结底，我不在乎谁做这种工作（而且我认为这根本不是脏活），但它必须完成并且必须做好。你不能总是依赖框架。
说得好，Sarah！
你完美地表达了我对这件事的感受。
我同意你的观点！
我完全同意。尤其是在 CSS 中出现了新的工具（主要是 Flexbox 和 Grid）之后，像 Bootstrap 这样的框架变得越来越没有用处了。
我个人从第 3 版之后就没有使用过 Bootstrap 了。不过，确实需要一些 CSS 框架来提供预先样式化的组件，以便快速原型设计。
也许“前端开发人员”这个术语需要重新思考。当我开始工作（作为设计师）时，前端主要包括 HTML 和 CSS 以及一些 JavaScript。一个优秀的前端开发人员需要能够将 Photoshop 布局转换为像素完美的网站。如今的前端发展得更加复杂了。如果你想学习前端开发，人们似乎会先学习 Git、npm、Angular、React、Vue，而所有这些都被称为前端开发。
我自己也是一名设计师，我认为我在 HTML 和 CSS 方面很擅长，但这（现在）不足以成为一名前端开发人员。另一方面，我遇到的许多自称前端开发人员的人（正如你在本文中展示的那样）对 CSS 并不熟悉。当我谈论最终理解 `auto-fit` 和 `auto-fill` 之间的区别或类似内容时，他们并没有感到兴奋。
所以也许我们需要一个介于两者之间的术语。某种职业，思考诸如可访问的 HTML 结构、精心构建的 CSS、流畅的过渡和动画之类的事情。负责让网站在任何设备上看起来和感觉都很好的人。也许这并不是主要对使用钩子意味着什么或是否应该使用 npm 或 Yarn 感到兴奋的前端开发人员。
我注意到 Web 平台专业知识总体上有所下降。人们学习 TypeScript 因为他们不懂 JavaScript。这是对你时间最糟糕的投资之一。但一些顶级公司却鼓励这种做法。我最近在我们其中一个产品团队中亲眼目睹了这样一个真实的例子。但我更喜欢根据结果来判断。比如，向我展示你优秀的组件/库/应用程序，然后我们再谈。
好吧，公平地说，Js 确实很难驾驭。
我正在逐渐精通它，但我仍然认为它没有多大意义……
说得好！
一针见血！
我完全同意。HTML 和 CSS（起初）很复杂，因为存在所有这些边缘情况和其他 OP 提到的内容，因为这些都是需要正确考虑的重要因素。我们不仅不应该抽象掉技能集，而且不应该抽象掉充分利用 HTML 和 CSS 所必需的基本理解。
同意。自从“全栈”这个词出现之前，我就一直是全栈开发人员（我于 1996 年开始了我的职业生涯的这个阶段）。如此多的框架、样板代码集合等等都让新的“开发人员”能够快速上手，但最终他们对 HTML、CSS 以及有时 JavaScript 的了解，就像“吉他英雄”玩家对真正弹吉他的了解一样。
我想让你知道，我和我的同事，他们专门从事前端开发，非常高兴看到有人为这一方面辩护。我无法告诉你，我遇到过多少次后端程序员将 CSS/HTML 视为事后诸葛亮、苦差事、猴子都可以被训练来做的事情……与此同时，他们甚至无法让它在多个浏览器上正常工作。
没错。
“它不会很快消失”
好吧，实际上，使用 Canvas，我们既不需要 HTML 也不需要 CSS。它目前并不流行，因为存在引用和可访问性问题，但一旦这些问题得到解决，它将开启一个全新的世界。
难道人们不是这样评价 Flash 的吗？Canvas 永远不会是可访问的，因为它不是为了可访问性而设计的。
谢谢！终于有人说出真相了。掌握 HTML 和 CSS 后，却意识到每个人都像躲避瘟疫一样避免编写它们，而是通过特殊的框架和工具来完成，这让人很沮丧。现在每个人似乎都想要只使用 JavaScript 来构建完整的前端，哈哈。
完全同意。
成为一名前端开发人员越来越难了，我们仍然有一些开发人员看不起前端开发，就像它是开发领域里不受欢迎的孩子一样。
坦白说：我从未见过一段 CSS 代码并认为，“这代码多么优美”。我的想法更多时候是不适合在礼貌的谈话中出现的……事实上，当我打字时，我就能感受到一些这种敌意正在升起。
也许这是因为编码不是我的工作。我热爱做这件事，这也是我在工作中做的事情之一，但它不是我的工作，甚至不是工作的首要重点。也许如果我能够整天与 CSS 交互，我会感到不同……但另一方面，我对 HTML、Python、Ruby、C# 或……任何你想到的语言都没有这种感觉（尽管我对 JavaScript 可能有点这种感觉）。
不是要煽动日益增长的敌意，但这里还有硬币的另一面 :)
一段 CSS 代码？可能不优美。对我来说，CSS 的美在于你整体看待它的方式。更多的是思考你的设计系统如何以有效的方式组合在一起。你使用选择器来使事情清晰和简单。
它也考虑了那些通常使界面更加愉悦的微小设计细节。这可能不会带来最令人兴奋的代码，但它使应用程序中的体验变得更好。
一些开发人员，不一定是前端开发人员，不仅将 HTML/CSS 阶段视为负担，而且视为任何工程师都可以处理的微不足道的步骤，而无需“专家”，因为在他们自己的理解中，它甚至不需要任何天赋或经验就可以开始。
这让人心寒！我发现这令人沮丧，以至于麻痹了我对这种心态做出回应的能力，虽然你的话语和理由如此有力且很有道理，但我不知道它是否能打动这些类型的心态。
遗憾的是我不得不说，对某些人来说，HTML/CSS 技能甚至不被视为前端的一部分，而是一个“设计师”可以完成的或一个框架可以解决的愚蠢步骤，显然这种情况还会持续相当一段时间。
你写的东西真是“太棒了”
问题在于行业本身，不是吗？创建更多网站。给我更多 Web 应用程序。许多程序员不想与 CSS 或 HTML 打交道，因为让页面完全按照预期的方式运行，不如让它实现其目的更有成就感。我认为，就像设计一样，CSS 和 HTML 将变得更小众。你以一个问题结束了文章。我担心答案是肯定的。Web 可能会变得像普通的报纸一样。大多数网站应该依赖功能和内容，而不是外观。因此，当行业正在寻找前端开发人员时，HTML 和 CSS 排在第二位，不要讨厌玩家，要讨厌游戏。
完全同意。我一直想切换到 VanillaJS，尤其是在现在有了 Service/Web Workers 和 Web Components 的情况下。
两个月过去了，我非常喜欢这种没有构建过程的开发流程，我甚至可能会尝试在 Chrome 开发者工具中进行开发……
首先……我学习并使用过纯原生的代码……就在我开始习惯原生编码方式时，也就是在我创建了一些体面的（在我看来）HTML 和 WordPress 主题之后，Bootstrap 的热潮来了……
所以，我尝试了一下这个叫做 Bootstrap 的东西……哦，天哪，我当时有多么困惑……记住所有这些类和规则太难了，而且（感觉）对于像我这样的人来说限制性太强，我通常在命名元素变得烦人时使用 foobar/abracadabra/iluvgirlwithglasses 这样的类。因此，我放弃了它……认为它不适合像我这样更喜欢纯原生风格的人。
我记得这段时期也是许多自命不凡的“网站设计师”到处冒头的开始。他们展示的基本上是从 Google 找到的第一个 Bootstrap 主题，这里那里稍微改动了几行代码……然后声称设计是他们自己的。
快进到 2018 年底……我仍然在使用原生方法……当然，与使用框架的新手相比，它可能有点慢……但在需要进行故障排除或出现边缘情况时，最终速度仍然更快……可能是因为我比那些使用框架/工具但对其工具不甚了解的人更了解我编写的代码。
TL;DR
使用框架和/或其他工具并没有错……只是确保在出现问题时或需要超越框架为您提供的功能时，您具备相应的技能。
原因：有些人仍然不接受网络的本来面目。一种流畅、互联、互动式的体验。
设计师仍然想要画画布和/或抱怨他们喜欢的设计应用程序，这总是导致一个模拟。
（后端）开发人员不关心显示细节和/或浏览器差异。
客户和项目经理希望价格便宜或至少在预算范围内（“只需使用 X”），这与想要为自己的工作感到自豪的设计师发生冲突。
他们都不了解渐进增强意味着什么。
而前端设计师是最后一道防线，疯狂地测试每个可能的角度、浏览器、视口和状态。试图将所有东西连接在一起，并让每个人都满意。
在我看来，UX 研究人员和可用性专家在设计网络方面做得最好。
您是否使用框架并不是问题所在，也不是问题的解决方案。一个好的系统（现有的框架、其中的一部分或自行创建的）可以解决基本问题，以便您可以处理其余问题，但如何应用它仍然取决于您。
从您的内容开始，然后是您的标记，“漂亮的设计”在我看来是最后一步。
旁注：我毫不惊讶地看到这么多前端人员筋疲力尽。
我完全同意你的观点。很棒的文章。在跳入附加工具之前，先关注基础知识。
Robin，感谢你的这篇文章。我自己两年前开始我的前端之旅，因为我真的很喜欢网站的可访问性和视觉层。我认为所有这些认为 CSS 和 HTML 不必要的想法都是因为很多编程转移到了浏览器端，所以后端开发人员被迫转移到前端部门，他们正在努力学习 HTML 和 CSS，因为后端和前端思维方式的差异。像 Angular 这样的框架也没有帮助学习正确的 HTML 和 CSS，当我看到 CSS/Sass 文件中只有 ID 或 HTML 中只有
我个人感到不寒而栗。
你在为我而战。谢谢
我是一个业余爱好者，并且创建了我自己的库来处理 DOM 操作和前端开发。
我个人不喜欢 CSS 或 HTML，并且使用模板和 DOM API 在 JavaScript 中完成几乎所有操作。我也不喜欢 CSS 布局，块级、内联等。因此，几乎所有内容都是使用绝对定位放置的。这可能有点麻烦，但我知道如何进行计算。
您可以在模板中的标签中包含 CSS，以将 CSS 和受影响的 HTML 保留在同一个文件中。类似于 Vue 如何使用单页面组件设计选项。
我有一种感觉，老程序员，我 52 岁了，不喜欢新的程序员不喜欢按照 20 年前的方式做事。
所以，放松点，构建你自己的 Dreamweaver。我已经做到了，并且在互联网的帮助下，我独自解决了所有问题。
相信我，我可以按照自己的方式，使用自己的流程构建任何我想要的东西，我不在乎其他人是怎么做的。
成为业余爱好者的最大好处是，我可以随时随地按照自己的意愿做事。
我猜你可以整天和我一起待在我的开放空间里，才会这样写！我作为一名集成 HTML/CSS 开发人员为一个拥有二十名开发人员的大型内联网工作。在他们看来，是他们完成了工作，而我修复了糟糕的显示效果！以正确的方式显示内容只不过是一个痛苦的问题。谢天谢地，六个月前项目中添加了 Bootstrap，他们认为将来应该绕过我！
浏览器只是显示 HTML 和 CSS，而不是 Java 或 SQL！他们怎么会认为不需要处理它们呢！
感谢提升我的朝九晚五的工作。
完全同意。当我刚开始成为一名 Web 开发人员时，我只有记事本和一点想象力可用。不要误会我的意思，我非常喜欢 Webpack 和我们现在可以使用的大量转译器，但这不应该以忘记如何在没有它们的情况下工作为代价。
根据我的经验，所有这些不同的工具都会出现和消失，但底层的 HTML、CSS 和 Javascript 保持（大部分）不变。让我们回到任何事情皆有可能的时代，而不是“但 Bootstrap 不支持那个！”
实际上与此相反，我对重复编码感到沮丧……一次在设计程序中，一次在文本编辑器中……我说两次是因为大多数网页设计软件都开始基于网络技术……还记得 Reflow 吗？Adobe XD 最近怎么样？我的意思是，我们不是从纸张到桌面……人工智能可以复制伦勃朗的艺术作品，但不能使用带约束和定义的分层约定来输出一些 HTML 和 CSS 吗？哈哈，这就是问题所在，这是巨大的金钱损失，这就是为什么我们短期内不会看到这种情况的原因。
人们希望这种情况发生，而且不适应和进化是不人道的。CSS Grid 是一个很好的例子，说明新的思维方式可以带来巨大的改变，并为那些每天处理这些语言的人带来解放，而不仅仅是坚持说“哦，拜托，继续使用浮动、定位和 margin auto”因为它们舒适、熟悉且有很好的文档记录。浏览器检查器也让人想起这一点，它真正需要的只是一些绘图工具和对检查属性面板的轻微重新设计，我们就可以开始了。
“Bootstrap 并不是一项技能，前端开发才是”——真相。故事结束。
很棒的文章。一些框架增加了额外的复杂性和混乱。我有大约 15 年的 Web 开发经验，我见过一些人了解 JS 框架，但不能用 Vanilla JS 写任何合适的代码。
这其中有太多真相了，感谢你详细阐述！我目前对像 Webflow 这样的工具感到兴奋，这些工具利用了语义 HTML/CSS 的价值和效率，但更进一步，允许任何对这些语言有基本了解的人从头开始直观地创建创意布局、交互和动画！似乎有时开发团队会过于痴迷于使用不同的工具和组件，以至于忽略了用户体验和网站性能的最基本概念。
我从 90 年代就开始制作网页了。
当时没有 UI/UX，只有我们一群人阅读 Jakob Nielsen 的博客。当时没有前端和后端开发人员，只有 Web 开发人员。
当事情开始专业化时，我转向了前端，因为那里才是所有行动发生的地方。
设计师进行设计，但网站不是静态的东西，有效的网站会测试、迭代和优化该设计，以满足其用户的需求。只有在大规模的情况下才需要优秀的后台开发人员，而优秀的开发人员（以及 UX、文案撰写者和设计师）可以将一个无人知晓或关心的网站扩展到规模。
……仅是我个人带有偏见的一点看法…… :)
我同意所有这些“老式网页”的理念，我认为 CSS 很好，甚至很棒。我可能在这方面有点偏见，但有时感觉人们（不是这篇文章本身）以一种毫无帮助的绝对方式否决来自工程方面的新的工具和技术。我主要想到的是 CSS-in-JS 和框架 + JSX（HTML-in-JS？）。SASS 很好，但 styled-components 是为那些不关心可访问性和网页的 CSS 讨厌者准备的。
我个人觉得，使用稍微复杂的工具（typescript + react-native-web + webpack）编写 HTML 和 CSS 比以往任何时候都更好。尤其是在可访问性方面，我觉得它给了我所需的灵活性，让我不必妥协输出结果，因为从任何数据/状态创建标记、样式或 js 事件从来都不是一件苦差事，这取决于什么能提供最佳体验。玩 CSS 高尔夫（纯 CSS 幻灯片、纯 CSS 太空侵略者、纯 CSS 电子表格）很有趣，但它从来都不是可访问性的理想选择。
总有一些人不想处理细节。他们可能从 Dreamweaver 迁移到 WordPress 主题，再到 Bootstrap，最后到 react-material-UI 或其他什么。但在我看来，我是在 css 中编写样式还是在 tsx 文件中编写样式，这不会成为决定性因素。
也许这些代码的持久性不如真正的 .html 和 .css 文件。我对此有些担心。
我对此不认同：许多小型企业网页设计客户只支付有限的网页设计费用，而使用“花哨的”工具（如你所说）可以节省生产时间。这种效率至关重要，因为这是在这些工作中获得利润的唯一途径。也许如果你有固定工资，并且你的雇主将前端开发视为一项持续的工作，那么你可以负担得起成为 HTML/CSS 纯粹主义者；但如果你是在自由职业，并且需要在一周内以有限的预算交付一个美观完整的网站，那么这些前端工具就会产生很大的影响。
我不得不表示赞同。然而，由不规范的框架创建的最终结果往往让客户和设计师感到失望。这种对期望、预算和无形品质（可维护性、可访问性）的冲突实际上让我暂时放弃了前端工作。
我也完全不介意网页像报纸版面一样变得同质化。这是一个预算问题，但在印刷方面，与报纸相比，10 倍的生产预算会导致在高质量材料上进行独特的精品设计。类似地，惊人的纯 CSS+JS+HTML 网站在更精致的角落蓬勃发展，并将继续蓬勃发展。
好吧，我现在不得不表示反对。即使你的预算有限，当你了解自己在做什么时，你也会变得很快。最后，我编写纯 CSS 的速度比调整和覆盖 Bootstrap 元素以适应给定设计的速度更快。
但我同意你的一点。如今关于网页设计/网页开发的许多讨论似乎只针对大型复杂网站。我很想阅读更多关于总共可能只有 1-10 个页面的网站的信息。
CSS 专家可以比大多数人更快地完成原生 CSS（实际上是模块化、PostCSS 或 SCSS），而不是自定义框架甚至模板。
真正的问题是，行业并不真正关心 CSS 专家。他们要么想要一个“会编码的设计师”，要么想要一个“有设计眼光的开发人员”。这就是真正的诀窍：两者都可以解决问题，但他们都不喜欢这样做，并且都认为这应该是对方的责任。
作为一种声明式、特定领域的编程语言，CSS 需要一种与任何命令式编程语言的开发人员完全不同的思维方式，并且与设计师的“绘图”技能完全不同。
我非常同意你在这里所说的所有内容。作为一名主要的前端开发人员，我一直认为我的技能组合不如后端人员，或者也许我需要更全面地学习更多工具（我的意思是，我们一直在学习），但我也有贬低自己技能组合的过错，因为现在普遍的理论是，一定有办法让某些东西为你做这件事。
我被邀请参加一个项目，他们无法让设计在网页上“生效”并适应不同的设备，我意识到没有任何框架可以做到这一点，它必须由具有创造力和理解力的人创建和思考，在这种情况下，我能够让一些非常酷的东西“活”起来。总之，感谢你的写作，我真的很喜欢阅读这些文章！
AD
感谢你分享你的想法。这句话引起了我的注意：“我认为 HTML 和 CSS 应该得到更好的待遇，而不是被处理、编译并输出到浏览器中，无论是通过某些构建过程、应用程序导出，还是我们半懂不懂的庞大框架库。”我同意，半懂不懂地使用工具是有问题的。但是，我也认为不必理解底层细节是软件工程师工作如此美好的原因。我喜欢知道有人已经解决了令人困惑的底层细节，并在其之上创建了一个抽象层。的确，很多时候框架在抽象方面做得不好，但总有一天它们会做对的。我个人很感激我们不必编写二进制代码，并且我们的[此处插入语言]被“处理、编译并输出”到其中。
看到这么多人同意这种观点真是太棒了！在我的工作中，我们通常只能使用我们从头开始编写的 html、css 和 js；没有任何库、框架或工具。虽然我觉得这让我对这些语言有了更好的基础理解，但我有时担心，在我的当前角色之外，我会被认为“落后于时代”或没有现在被认为是“前端开发人员”所需的技能组合，即使我的 css 和 js 编写能力对于必须用原生 js 编写所有功能来说相当不错。我很高兴听到并非所有人都认为 Angular、React、Redux、Bootstrap 等是如今开发所需的技能。
我的一次经历
30 多岁的工程主管承认自己不懂 css，同时表示自己职业生涯已经太晚，无法学习了。
同一个人在我研究了一些响应式 css 以解决一个前端问题并将其与开发人员分享时，变得沮丧和生气。
感觉像是“保护我的地盘”的问题，而不是每个人都试图推动产品前进。HTML/CSS 被视为一个问题，只有设计师才会关心，但同时，也被归类为仅属于开发人员的职责范围。
很棒的文章。就像任何学科一样，使用工具很好，但你仍然需要能够检查工具是否输出了预期结果。例如，土木工程师会使用工具来计算基础需要使用多少混凝土，但应该能够检测到工具是否输出了错误的结果。我认为 HTML、CSS 和 JS 就像智慧，而框架就像知识。有时，智慧会告诉你正确的工具只是你自己的工艺，你不需要框架，其他时候使用它们是可以的，但你必须能够判断最终结果是否完全错误或违反了网页核心原则。
@Geoff – 要是真正的样式表看起来像你文章中的代码片段就好了！我赞同这一点，但实际上，我们正在查看应用于项目行的 13 种不同的样式，以便在整个站点中使用——有些用于处理标题菜单，有些用于页脚，有些用于处理页面的列表，还有一些用于处理帖子列表……哦，别忘了圣诞节列表，它需要与复活节列表有不同的主题！
当然，这部分原因是人们编写了糟糕的代码，但在我看来，我看到的荒谬 CSS 代码比其他语言（无论是 HTML、JS、PHP、C# 等）中的代码更多……
为什么会这样？我会责怪级联，因为它们总是让我很头疼，但我实际上认为问题更多地在于 CSS 在设计师/开发人员的脑海中很容易与特定元素脱节，因此人们会发现多个规则在单个样式表中应用类似的样式（别忘了，我们可能由于嵌入、插件等原因在页面上加载了 5 个不同的样式表）。
好吧，也许我只是个吝啬鬼……正如前面提到的，这是我工作的一部分，而不是我的工作重点……所以我绝对是从一个不得不深入我几个月前编写的 CSS 或其他人编写的 CSS 并弄清楚事情的人的角度来说话……
@Steven – 也许如果我正在使用你的样式表，我会感觉不同……但平均而言，样式表非常可怕，在我看来，请参阅上面以获取更多详细信息。 :)
哎呀，我激怒了大家！ :)
不过说正经的，我知道我帖子中的示例很小且包含在内，但我仍然认为 Robin 的观点仍然成立。应用于难以导航的元素和文件的 13 种不同的样式听起来像是需要磨练和完善这些前端技能的症状……而不是避免它们。代码诗意是手艺的一部分。
我相信真正的问题是，HTML + CSS 开发与 JS 编码以及设计都足够不同，以至于设计师和 JS 开发人员都觉得他们不应该为此负责。
也许两者都不应该。我完全赞成第三种角色，称之为 UI 工程师或任何你喜欢的名称：HTML+CSS 专家。
我完全同意！
作为一名全栈设计师，我无法割舍对 html、css 和 js 的热爱（jQuery 万岁）。
我无法想象有人自称是前端设计师，却对这些语言没有深入的理解，也没有尝试和学习新事物的意愿。
我承认我经常依赖一些框架（比如 Bootstrap 和 UIKit），但这并不是因为懒惰。拥有一个一致的响应式网格系统、辅助类和针对常见问题（折叠、下拉菜单等）的简洁的 JavaScript 解决方案确实很有帮助。但这仅仅是一个基础。我经常看到人们将自己的工具限制在这些框架提供的工具上，而不是将它们视为构建的基础。:)
一个相关的但令人不安的趋势是，一些 Web 应用框架让你编写代码来创建用户界面……Flutter？React？
我们已经“用代码制作 UI”几十年了……Xlib、user32.dll、carbon……这太糟糕了。
HTML 和 CSS 在表达能力、功能以及我想到的几乎所有其他方面都远胜于它们。
我希望我们能尽快度过酷炫技术周期中的这一阶段。也许我们可以通过强制开发人员记录一段时间内的旧 Xlib 或 user32 代码来鼓励这种转变，直到他们理解为什么 HTML 和 CSS 更好。:P
我完全不同意！
这往往会影响那些拥有纯粹心态的初学者，让他们在学习 Web 设计的基本工具时不知从何开始，或者是否真的需要花时间深入学习 HTML 和 CSS 等基本工具，因为他们可以用很少的知识掌握一个框架，并在最后对自己的设计感到满意。
看到其他人也这么想，我感到很欣慰。我**非常**喜欢 CSS 和 HTML。没错，我就是这么说的。而且，基本上，我**不想**用工具或框架帮我写它们。JavaScript 也很有趣且功能强大，但我看不出它为什么应该成为“前端 Web 开发人员”的中心/唯一资格。