在2020年，我重新发现了用简单的 HTML、CSS 和 JavaScript 构建网站的乐趣——没有转译，没有编译，除了我放在键盘上的双手之外，没有其他构建工具。
鉴于我的个人品牌可以概括为“如此晚于比赛，以至于体育场已被拆除”，我决定在 2020 年开始播客。它是我的代理机构 Clearleft 的播客，并获得了极具想象力的标题The Clearleft Podcast。我对第一季的结果非常满意。我对为它创建的网站也非常满意。
网站并不大，但它会随着时间的推移而增长。我思考了一下该网站的构建过程应该是什么，经过仅仅几秒钟的辩论，我决定构建过程为零。没有。什么都没有。
事实证明，这极大地解放了我。在没有任何中介的情况下，编写将交付给最终用户的实际 HTML 和 CSS，这感觉非常上手。我感觉自己正在接触网站的土壤。
近年来，CSS 已经有了很大的发展——有了像calc()和自定义属性这样的功能——你不需要使用像 Sass 这样的预处理器。而且原生 JavaScript功能强大，功能齐全，并且可以在不进行任何编译的情况下跨浏览器工作。
别误会我的意思——我完全理解为什么复杂的网站需要复杂的管道。如果你是一个大型团队的一部分，你可能需要制定流程，以便每个人都能以一致的方式为代码库做出贡献。代码库越复杂，你就越需要技术来帮助你自动化工作并在代码上线之前捕获错误。
但这种设置并不适合每个网站。而且，所有这些旨在节省时间的工具和流程有时最终会在以后浪费更多时间。你是否曾经在六个月或十二个月后重新访问过一个项目？也许你只想对 CSS 进行一点小小的更改。但你做不到，因为一个依赖项被破坏了。所以你尝试更新它。但它依赖于另一个版本的 Node。在你意识到之前，你变成了 Bryan Cranston 在换灯泡。你应该只调整一行 CSS，但实际上你却在与熵作斗争.
每当我处理前端开发中的问题时，我都喜欢应用最小权力原则：为给定的目的选择最不强大的语言。一个典型的例子是使用简单的 HTML 按钮元素，而不是尝试使用带有多种 ARIA 和 JavaScript 的 div 来重新创建按钮的所有原生功能。今年，我意识到，同样的原则也适用于构建工具。
与其默认情况下使用所有功能强大的工具链，我将从一个无聊的基线开始。如果以及何时变得过于痛苦或笨拙，那么我会添加一个任务管理器。但每次我添加一个依赖项时，我都会限制项目的生命周期。
我 2021 年的新年决心是节食。不再有沉重的node_modules文件夹；只有香脆可口的 HTML、CSS 和 JavaScript。
阿门。
一个问题是，如今很多很酷的东西（比如库、组件等）都使用这些依赖项，因此也会将它们拖入，你可能至少被迫阅读并了解一些内容。比如…“哦，这是一个不错的、轻量级的、适用于我的网站的入门代码库！我想使用它。我的天啊…那是 SASS…我想要的只是 CSS…”
它不必是全有或全无。最近我用 lit-element 做了一个小型的 PWA 应用程序。非常薄的一层，专注于 webcomponents。插值类似于 react。没有运行时依赖项，但开发体验良好。
大多数库和组件都可通过 CDN 获得，因此 npm 仍然可以避免。
我也有同感！
也就是说——当我发现 svelte 时，我重新获得了对前端编码的热爱。
听起来 Hugo 是解决方案。一个单一的二进制文件提供了足够强大的功能来取代整个技术栈和服务器。
HTML+CSS+JS 使用 Markdown 或 HTML 作为内容源。我个人的修改是使用 TailwindCSS 和 AlpineJS 来实现样式和 JS 的优势。此外，我在今天早上看到你的文章之前大约两个小时就提到了 Bryan Cranston 的场景，有人在听。
作为一个游戏新手，我一直想坚持使用默认提供的工具。
主要是因为害怕和缺乏理解。但是现在我已经尝试了构建工具、模块，别评判我…Bootstrap 之类的东西，我发现我对简单的添加又有了新的热爱。
我还没有足够的经验去处理“旧代码，旧项目：依赖项已损坏”，但我知道这即将到来。
由于我对默认值的热爱，我有时只使用标准的 HTML、JS 和 CSS，但 SelectJS 等依赖项的闪烁的眼睛、Vue 的咧嘴一笑和 Svelte 的诱惑以及像 Tailwind 这样的工具…它们 simply 无法抗拒。
我喜欢这篇文章
我一直很想进入 svelte 的世界，但随后我感觉自己会陷入利基地狱，然后选择其他东西。当我意识到设置 typescript 的难度有多大时，我开始害怕，因为我想要静态类型。等等。
CSS 和原生 Javascript 可以让你在单人项目中走得很远，这太美妙了。继续进入无构建步骤的未来！. . . 除了也许 Svelte 的诱惑会让我继续安装 node 模块一段时间
阿门。
还有一点：避免长依赖链不仅有利于避免依赖地狱，对于连接速度慢的用户来说也是一种恩赐。在慢速 WiFi 下，许多使用“现代”构建管道的页面需要 10 秒以上才能加载。
如果你讨厌臃肿的网站，你可能会喜欢这个页面 https://idlewords.com/talks/website_obesity.htm
以前从未听说过“最小权力原则”，但这与我对构建任何 web 作品的唯一有效方法——“渐进增强”——产生了共鸣。可惜 web 开发很快变成了对最复杂工作流程的追求，而不是坚持其最初的沟通目的。
是的。千真万确：是的，请。所谓的现代 web 开发完全毁掉了我的工作。行业群体思维强加给了我太多东西，但其中许多工具我都是自愿采用的，因为一开始我觉得这些功能值得。几年后，我意识到我不再创建用户体验了。我只是在与工具和依赖项集成作斗争。我愿意付出任何代价来回到过去。
我现在深有感触。我一直在努力寻找新的前端方法来替代我一直在使用的旧的 angularjs。所有这些 react、vue、typescript、编译、转译、排查实际上并非我自己编写的代码，让我非常沮丧。回到使用纯 HTML、CSS 和小型 JS 库（我可以直接通过 cdn 链接到它们以实现一些花哨的功能）的基础，似乎正是我一直在寻找的东西。
听起来像是天堂。
我是一名前端 web 开发人员。
鉴于我们工作的最终结果是 HTML、CSS 和 JavaScript，我到底在和 Docker 和 Azure 作斗争？！
听到这些感觉很好
你如何维护导航栏等元素？这样你就不用为每个页面单独修改它们？
谢谢。
现在我可以信任人类了。
https://john-doe.neocities.org/
这对单页网站来说很棒。一旦你有两个页面，你就会重复自己，现在必须对多个文件进行相同的更新。对于大多数网站来说，至少需要一个处理部分模板的流程。
如果我理解错误，Jeremy 可以纠正我，但我认为这篇文章并不是反对部分模板的概念。
就我个人而言，最小的阻力规则是使用绝对基本的 LAMP 栈上的 PHP。
只需几个 PHP 包含，我就完成了——不需要编译，仍然是零构建过程。
服务器端脚本也是如此。
我想知道这是否真的是人们如今的体验？当然，我被坑过不止一次，假设几年前的项目很容易更新，但现在几乎没有配置或很少配置 webpack/rollup，这还是个问题吗？
这种情况仍然存在。
不得不提醒开发团队不要运行
npm update，而只在拉取时运行npm install。一些随机的库更改，你就会追查它半天。
有时我看到一个 100MB 的
node_modules文件夹，我真的想知道现代前端开发到底发生了什么…@Jeremy Keith 正确
终于，我找到了一些更古老的恐龙。我们有一个由 8 人组成的团队，他们总是想出更新、更好的想法和库。一开始，一切都很有趣，但一段时间后，所有依赖项和更新都破坏了我对工作的兴趣。这些工具有时比它们节省的时间花费更多。我很高兴偶尔可以完成一个小的项目，使用一些传统的 HTML、CSS、JS（和一些 PHP）。
太对了！
我完全同意！
我甚至在新冠隔离期间花时间编写了两个开源项目，它们只依赖于代理，因此 JS 代码完全是原生的。
文档仍在开发中，但你已经可以使用它，例如进行双向绑定，而无需更改当前项目的原生代码。
将来，你不会被我的库绑定，你可以随时丢弃它们，而不会破坏你的代码。
https://www.noaml.in/projects
只是我的想法，KISS，仅此而已。感谢你的这篇文章！
对于一个简单的非交互式单页网站来说，完全没问题。添加动态表单、非平凡的 UI，你就麻烦了 :)
完全同意！今年我做了一堆“原生的”项目——我注意到所有这些项目的一个共同点：它们在 Lighthouse 中都获得了“100%”的性能——仅仅因为没有大量未使用的 CSS 和 JS。
哦，是的，web 开发人员发现，即使不使用 50 种不同的技术，也不使用所有系统资源，仍然可以构建强大的 web 网站。
这也意味着没有 eslint、prettier 和 stylint。
直接使用 Dreamweaver 就好了。
自己下载依赖项，并在项目文件中离线包含版本，这样就不需要一直更新了。
添加依赖项不会限制网站的寿命！它只会限制你在项目中使用该库的喜爱程度，但你的手写代码也是如此，当你离开它一段时间后，你可能不喜欢它，然后你会想“我为什么要这样写？！”。
在添加了特定版本的库后，它可以永远保持这样，就像你手写的代码一样，这要归功于稳定的 web API。
如果你担心依赖项可能消失，甚至可以将 node_modules 提交到仓库中。
我同意，但现在我想问：如果我需要做一些事情，比如 CSS 前缀、缩小等呢？
我同意打包程序的臃肿程度，但如果我需要一个外部库，我需要使用 CDN（失去缓存优势）或手动下载东西，这虽然可行，但很繁琐。
另外，请不要告诉我 CSS 非常棒：如果没有像 SASS 这样的东西，CSS 就完全无法维护，除非你做一些非常 KISS 的东西（而且很多设计师不制作 KISS 布局：P）。
也许 snowpack 是正确的方向，但我仍然认为我们需要某种工具。也许是更简单的工具，但总归是工具。
我理解这个概念，即在某些情况下可能需要 npm 你的生活。但是，每次我遇到它的时候，我都会和我的朋友们大声咒骂，因为原本应该很简单的事情却被搞得如此复杂。我真的很讨厌它。也许我还没有遇到过其中任何一种情况，或者也许我太喜欢你最后的陈述，Chris，以至于我不想遇到它们。永远不会。
年轻人知道如何“使用”，但他们中的许多人已经不知道如何“做”。在接下来的几十年里，也就是我的寿命，我认为这将是一个不错的难题……
我使用 jQuery 和原生的 JS/CSS 构建了一个单页 web 应用程序，但我完全可以使用原生 JS/CSS 来编写它。所以我一直想知道为什么每个人都对框架/库如此兴奋。我得出的结论是，对于许多开发者来说，它们可能更容易进行协作，并且像 Babel 这样的工具有助于确保支持旧浏览器。但如果你写代码很好，并且不需要单元测试，那么就没有必要使用框架/库！
我真诚地不同意。一个带有大量 jQuery 代码的单页 PWA 是一场维护和调试噩梦。
你无法确定你编写的代码是否写得好，尤其是在像 JS 这样奇怪的语言中。你需要某种标准。
我认为我们只需要更简单的工具，Svelte 就是一个很好的例子，即使它远非完美。
我正在使用纯 HTML、CSS 和 TypeScript 的方法。该项目主要基于 web 组件、服务工作者，并假设浏览器支持 http/2（因此不再需要打包）。
有一个很小的构建脚本，它调用 tsc、rsync 和 node 来编译 TypeScript、复制文件，并运行额外的构建时脚本（用 TypeScript 编写，用于静态内容生成），到目标目录，或者将 public/ 用于 Gitlab 页面。
仍然存在 node_modules，用于 TypeScript 和 @types/node，但它启用了 TypeScript 和构建时脚本。
我不得不说，我非常喜欢它。主要是因为没有 webpack，也许吧。
所以……使用合适的工具来完成工作。思考，而不是重复相同的模式。总的来说我同意，但有时泛化是错误的。手动编写的代码的一个缺点是，其他人可能难以阅读该代码。毕竟，我们是在为其他人编写代码。
祝你好运，解决你的 CSS 缩小问题，甚至错过 mixin 的想法…
我认为，如果你有一个基本的 Gulp，它仍然是一个不错的解决方案。
我想到的另一件事是：Gulp 会在你的结构很糟糕时责怪你，想象一下与另一个遗漏了逗号的人一起工作……你会浪费大量时间来识别这个问题，而 CSS 会照常加载。
我希望你能回复这些内容，因为看起来你只是一个人工作。
我完全同意。我喜欢传统的纯 HTML/CSS 的效率。它使网站尽可能轻量级。我用这种方式制作了自己的网站。如果它变得更大，我会选择一个 SSG。
喜欢它。我对原生的东西有偏见——从头开始编写自己的东西有一种深深的满足感。
我尽量了解最流行的工具，以便能够与团队合作进行项目，但对于我的个人项目，我喜欢使用原生的 CSS、Vanilla JS 和一些简单的调整。
我非常同意。我认为，我学习的唯一途径[我已经在业余时间学习了大约 20 年]是直接操作代码。我构建的两个网站可能并不花哨，但它们有效，对我来说，这就是最重要的：我可以在此基础上构建。
嗨，Jeremy，
很棒的文章。
我最近在我的一个项目中做出了同样的选择。不过，有一个问题，那就是将页眉和页脚复制到所有 HTML 文件中。
我做了一些调整来解决这个问题
htmlsync.js
这里有很多需要解释的地方，但总的来说，它取决于你的用例。
CDN 非常适合托管库（如果我没记错的话，有一个 CDN 托管所有 NPMJS 库），但也有有效的用例，在这些用例中，在自己的服务器上托管包是一个更好的选择。
隐私是当今世界的一个重大趋势。将库托管在您自己的服务器上，可确保您完全控制访问权限和日志记录（或不记录）。CDN可能会跟踪每个 IP 的使用情况，并且通过巨大的数据量可以推断出用户的互联网模式。
我已经做兼职网页开发人员将近 20 年了，从只有原生 JavaScript 可用的时代开始。jQuery 对于弥合浏览器之间的不一致至关重要。作为一个单人团队，我目前使用 WordPress 构建大多数网站，因为它是一个完整的生态系统，客户可以自己进行简单的维护。性能可能是一个问题，但正如 CSS-Tricks 本身所展示的那样，有一些解决方案。我喜欢我为一位真正需要可靠数据库的客户使用 Django 构建的网站。感觉它提供了最佳的控制和功能组合。
我尝试过 React 和 Vue，但它们的价值似乎针对大型团队项目，或者原生代码不堪重负的复杂项目，或者一个能快速推出大量项目的团队，这些项目可以轻松地重复使用组件。我确实发现 Svelte 很令人兴奋，并且预计它将在一年后 Svelte-kit 稳定后流行起来。
Jamstack 方法似乎提供了一个很好的中间地带，它提供性能、客户使用标记添加或修改内容的能力，以及相对简单的构建过程。
当然，正如 #Mike 所说，“适用的工具才是最好的工具”是第一条规则。