这段小小的 Twitter 交流一直萦绕在我的脑海中。
1997 年：让我们做一个网站吧！
*启动 vi*2007 年：让我们做一个网站吧！
*下载 jQuery*
*启动 vi*2017 年：让我们做一个网站吧！
😵 pic.twitter.com/RT4VVnJjNS— Thomas Fuchs (@thomasfuchs) 2017 年 2 月 22 日
少说废话。2007 年的网站很糟糕。用户体验驱动这一切。 https://#/k2akE8tjTU
— Colin Megill (@colinmegill) 2017 年 2 月 24 日
虽然我认为最好避免在 Twitter 上进行尖刻的争论，但这确实触及了一些有趣的东西，我认为很多人都感受到了。
Thomas 说的没错：网页开发变得越来越复杂了
在开发者大会的任何问答环节中，你都会听到这一点。这就像现在最流行的话题。
这种复杂性不容忽视。人们感受到了。超级聪明且能力强的开发者也因此感到不安，这可以理解。超级复杂的开发设置和构建流程的含义可能还没有完全显现出来。
这对培训新开发者意味着什么？培训老开发者呢？这种复杂性的极限在哪里？
Colin 说的没错：这种复杂性并非毫无意义
首先，如果你不想使用任何新奇复杂的工具来构建网站，你不必这么做。网络是一个很大的地方。任何给定网站成功的必要条件，与生活在这个星球上的人类一样多样。
一个网站的要求可能是，你可以用简单的 HTML 和 CSS 做出很棒的工作。网络在向后兼容性方面也做得相当不错。1997 年和 2007 年的网站，如果它们仍然存在，可能仍然像当时一样或更好，即使显示它们的硬件发生了变化。
那么，这种复杂性到底是怎么回事呢？
与 2007 年，尤其是 1997 年相比，2017 年的网站需要承担更多的任务。做得更好。做得更快。在任何地方都能工作。看起来很棒。
我不仅想看到机场的地址，还想预订我的航班，选择我的座位，然后在三天后更改它，管理我的 SkyMiles，打印我的行程，收到任何更改的提醒，并将其全部同步到我的手机（仅列举了航空公司网站提供的 20% 的功能）。并且请在 3 个月内交付。
开发者们睁大眼睛看着这份需求清单，挺身而出说“我们会做到，但我们会构建和发展必要的工具来做好这件事。”是的，我们正在构建开发者便利工具。如果你愿意，你可以把它们看作是复杂性，而且你并没有错，但这并不是全部。这些工具使我们能够构建您需要的东西，而不会制造难以恢复的混乱。
网络用户想要很多东西。用户体验驱动这一切。
但这种样板代码是否必然会带来更好的用户体验呢？
我在工具和构建流程日益复杂化的过程中看到的不一定是关注更好的用户体验：其中很大一部分是改善某种类型开发者的体验。
我并不是说事情不应该比 2007 年更复杂；我当时甚至还没有做网页开发，所以对任何“美好旧时光”都没有概念。但是，那条推文中提到的初始样板代码象征着一种“用 JavaScript 做所有事情”的心态，这让我非常担心，尤其是在它使开发者能够忽略可访问性和渐进增强问题时。
是的，将那份东西列表视为“样板代码”的事实……不太好。
也许我们可以把事情简化一点
“这些工具使我们能够构建您需要的东西，而不会制造难以恢复的混乱。”
在你理解你正在实施的所有技术之前，很容易制造难以恢复的混乱。这就是为什么像我这样的开发者在向他们的设置中添加工具时更加耐心。
谢谢，Chris。
我的担忧是我们正在将这些节省时间的工具强加到不需要它们的开发项目中。其中一些是很棒的通用工具，每个项目都可以从中受益。有些看起来非常复杂，并且只在某些类型的项目中需要。无论是构建工具还是 CMS，对于每个项目来说，它都不是必需的。
正如你所说，复杂的工作需要复杂的工具来将所有东西整合在一起。我认为真正的问题在于如何判断何时使用更复杂的工具来处理更复杂的过程，以及何时使用更简单的工具。我认为应该从尽可能简单的地方开始，然后逐渐增加复杂性。将复杂性作为起点只会导致许多开发变得过度复杂。许多网站作为无聊的旧 HTML/CSS/JS 网站就足够出色了。当网站发展壮大并变得稍微复杂一些时，可以使用构建工具来提供帮助。如果变得太混乱，可以将网站引入 CMS 或更大的网站构建框架。这是一个渐进的过程。
一个很好的例子是，这么多人将 React 作为万灵药。“一切都会变成 JS，”他们说。“为什么不顺应潮流呢？”好吧，它并不是解决所有问题的正确方案。复杂的工具（通常）是解决复杂问题或流程的答案。但是，它们并不是解决所有问题的方案。
我认为在大公司培训新开发者与许多自由职业者或小型代理商开发者每天所做的工作是不同的。我们应该教授复杂性的工具以及何时使用这些工具的判断能力。你会用吗？很棒。你知道何时使用它吗？我认为这是更大的问题。
有一些应用程序开发者正在为你在文章中提到的航空公司客户创建网站/应用程序。但是，还有很多开发者在营销领域或与小型客户合作，他们实际上只需要一个设计良好的 HTML/CSS/JS 网站。然而，为了跟上最新的趋势，这些开发者和新手正在承担比他们需要更复杂的过程。他们没有意识到他们所做的事情与 Google 或 Apple 甚至 CSS-Tricks 所做的事情大不相同。我认为，为了跟上潮流，开发者感到有压力去使用所有这些新的构建工具。
顺便说一句，我使用 CSS-Tricks 项目 IDE 构建了我们公司的新网站。我真的很感谢你们所做的一切，并想说你们已经处理了很多复杂性，并试图简化创建网站的过程。我认为你们所做的事情很棒，并希望这个项目取得更大的成功。你们的 IDE 是有人试图简化开发过程而不是使其变得更复杂的例子。我认为你们所做的是构建了一个系统，允许开发者在过程中根据需要扩展项目。我们不再需要从过度复杂的构建系统开始，然后创建由构建系统的复杂性决定的过度复杂的东西。
关于培训新开发者的方面，是否可以在正常的开发（HTML/CSS、营销、登录页面）和高端开发（应用程序、企业、长期项目）之间进行更好的区分？我认为，如果开发者能够看到他们在该频谱中的位置，将有助于缓解他们对所有不同构建工具的困惑。我在一家大公司工作，我们有 1-2 个项目需要原始推文中列出的那些技术。对于我在内部处理的许多项目，一个简单的构建加上一些预处理、autoprefixer 和自动刷新就足够了。任何更复杂的东西只会拖慢速度并使事情变得过于复杂。
再次感谢您提请大家注意这个问题。这是一个值得思考的好问题。
Thomas 没有提到 1997 年或 2007 年服务器上代码的数量。我想现在大部分代码都被推送到浏览器上了。
可以接受，但这并不是原始推文的内容——它是关于样板代码的，目标受众是开发者。我的担心是，这并非以用户为中心，而是过度兴奋的以开发者为中心。技术主导，而非用户主导。我承认你的航空公司示例是有效的，但肯定存在自我延续和全面争强好胜的因素，更不用说出于各种原因而有意排除的因素了？
我有点容易被工具的光环所吸引，但内心深处我知道除非按需使用，否则它真的真的真的（rea..好吧，你懂的）没有必要，像这样的帖子帮助我从工具的隧道中抬起头，节省时间并尝试构建出色的 UI，从而带来更好的 UX。
少说废话，用户体验驱动这一切。赞同！
截图显示了一个非常固执己见的设置，如果你正在制作一个简单的网站，你永远不需要它，所以推文中提到的困境不存在。
当然，如果你正在进行高级应用程序开发，你可能需要类似这样的设置，但如果我们要进行苹果与苹果的比较，1997年使用 Windows 框架开发应用程序是否更容易？我不这么认为。
作为一个在2007年及之前构建 Web 应用程序的老程序员，我可以说事情一直都很复杂。
作为这个行业，我们一直以来都使用复杂的工具来交付复杂的基于 Web 的应用程序。仅使用 HTML/CSS/JS 在 Dreamweaver 中构建静态网站的早期时代在 2002 年就结束了。如果有人说 .ASP/.NET 工具比今天的 JS 框架更简单，我会说你在撒谎。
随着 Rails 的发展，这是我们行业第一次真正开始理解构建真正的基于 Web 的软件意味着什么。用户体验在这方面是一个巨大的驱动力，因为人们开始在他们的 Web 应用程序中要求类似桌面应用程序的体验。如今，这已经变得非常普遍，以至于使用一些 jQuery 构建一个简单的 HTML/CSS/JS 静态网站被认为是小菜一碟。
但同时说事情不应该这么复杂，就像说所有汽车都应该像福特 T 型车一样，我应该能够用螺丝刀和锤子修理汽车的任何部件。
这简直是荒谬的。
结论
工具很难用。工具一直都很难用。构建 Web 应用程序很难，而且期望值很高。问题的一部分在于浏览器从未打算成为应用程序存储库，因此我们不得不构建使之成为可能的工具。DSL、框架和各种观点是我们在这个称为互联网的新兴事物中所拥有的一切。
说得很好！增加了关于浏览器最初用途与我们在互联网最初几十年里试图做的事情之间的良好视角。作为一个新程序员，我很感谢听到你的想法！
我认为 2007 年的例子中缺少了一些东西……
我认为问题不在于所有可用工具。如今 Web 开发人员拥有的工具数量绝对令人惊叹。但是将如此多的工具内置到你的唯一样板文件中？这使得复杂性成为默认设置，即使对于那些应该简单的项目也是如此。
任何构建的第一步都应该是确定客户的需求。通常，特别是对于小型客户，他们需要的是 WordPress、几个页面和一个主题。像这样的东西绝对是过度的。
假设你正在构建一个 Web 应用程序而不是一个网站的样板文件没有任何问题，但最好有多个样板文件，并在开始任何项目时选择最合适的样板文件。
这只是真相的一半。这些东西并不是由用户体验驱动的，而是由开发人员体验驱动的。但这并不是一件坏事，因为它允许更快地实现对用户体验有益的功能，因此它是由 UX 间接驱动的。
我发现随着样板文件和工具变得越来越复杂，我们的开发团队变得越来越孤立。我专注于一件事，其他人专注于工具集，其他人专注于用户体验，接下来我就会知道我们有一个巨大的项目，我们大多数人都无法复制……并且处理实际的 UI 部分最终就像在河上踩木头一样，因为基础设施在不断变化。坦率地说，复杂性的一半是因为团队中的大多数人来自 Java 背景……它“需要”一个构建过程。我是团队中唯一的老派 Web 开发人员，我们过去一直构建如此复杂的（可能没有那么大）东西，而无需构建过程，也不需要除我们自己编写的之外的任何库。
抱歉，我有点唱反调，但是……
如果你有一个设置了该样板文件的 DevOps 团队并且它可以工作，或者你是一个构建了该样板文件的独立开发人员/小型团队开发人员并且它可以工作，那么没有任何东西可以阻止你使用纯 HTML/JS/CSS 进行开发，如果那是你的喜好。但是如果需要，这些工具就在那里。
“哦，范围蔓延，我认为这个项目可能最终需要 React/Redux/Webpack……哦，看，它们已经配置好了。赢了！开始开发吧！”
（这基本上就是 CodePen 项目所做的。预先配置好的开发工具，只需点击一个按钮即可部署，但如果你不需要它们，它们就不会妨碍你。并没有真正看到这给开发人员带来什么负担。）
人们说我们今天拥有的这些现代工具只在最复杂的网站中才必要。但是，这些现代工具在最基本的网站中仍然很有用。
对于一个超级简单的 HTML/CSS/JS 网站，我仍然希望使用这样的技术栈来最大化我的生产力
使用 Pug 更快更容易地编写模块化 HTML
使用 Sass 编写 CSS
使用 auto-prefixer 添加前缀
使用 Babel 处理 ES6 JS
使用 Browserify/webpack 构建模块化 JS
使用 ESLint 保证 JS 代码风格一致
使用 Sass Lint 保证 Sass 代码风格一致
SVG 自动雪碧图
使用 Customizr 自动生成自定义的 Modernizr 特性检测文件（IE 不支持 @supports）
使用 Gulp 运行所有任务
抱怨当今网站的复杂性就像抱怨汽车与自行车相比的复杂性一样。
是的，汽车比自行车复杂得多，但汽车也能够让你以比骑自行车快得多的速度到达目的地。
没有人必须自己去造一辆车才能使用这些工具。像 Yeogurt 这样的框架已经为你完成了大部分构建工作。它可能需要一些调整，但除此之外，它基本上就像从汽车经销商那里买一辆车一样简单，只是这辆车是免费的。你不需要知道如何造一辆车，你只需要知道如何驾驶它。
所以，是的，所有这些东西都是可选的，而且比以前构建网站的方式复杂得多。如果你接受了这种复杂性并使用了这些新工具，那么你将能够比没有它们时更快地完成工作。
（在我看来）我们现在面临的一个主要问题是，人们不了解他们正在使用的工具以及这些工具带来的长期影响。
在像 Web 这样的媒介中创建遗留系统几乎是不可避免的，但我们现在看到的是，某个东西成为“遗留系统”的生命周期大约为 3 年——这太荒谬了，并且象征着更大的问题。不久前，Backbone 还是“最热门的”（孩子们现在还这么说吗？），而现在，如果你进入那个代码库，它基本上就是一个遗留系统。
“我想预订航班”的用户目标不能通过 Angular、React、Ember、Backbone、Vue、Flight、Knockout 或（任何其他）来解决。它*可以*解决……在风险不高的场景中，你应该尝试所有新事物，因为你可以随时丢弃或重新调整它们，但在高风险场景中，人们的工作和生活与一个将在 3 年内成为“遗留系统”的产品相关联时，我们应该使用更可靠的技术。
我认为如果我们花一些时间从产品和人员管理的角度考虑这些新系统的潜在长期影响，我们不会那么快地启动这些系统。
我相信其他人也在这里说过（我没有阅读大部分评论），但问题不在于我们拥有更多工具，问题在于人们在不需要的时候使用了这些工具。
停止疯狂吧，人们！为正确的工作使用正确的工具。