前几天有人让我做一个关于这个问题的小型讨论。我认为我自己并没有资格回答这个问题，任何一个人都不具备。如果您真的需要对这个问题的明确答案，您可能需要查看来自许多开发人员的调查结果的汇总数据。
不过我确实有一点资格。除了运营这个网站，这要求我每天思考前端开发，并让我接触到关于前端开发的大量对话，我自己也是一名活跃的开发人员。我参与了 CodePen 的开发，那里是前端开发人员的集中地。我还每周与各种各样的嘉宾在 ShopTalk Show 中讨论这个问题，我经常去参加以前端开发为主的会议。
所以，让我尝试回答一下。
再次声明
- 这并不全面
- 这些只是松散的猜测
- 我只是一个人
用户期望不断提高。
这奠定了基础
人们对网站的要求越来越高。开发人员被要求以非常快的速度构建非常复杂的东西，并且需要这些东西运作良好且速度很快。
新的 JavaScript 已经到来。
jQuery 对我们来说非常棒，但它不再适合新的开发。我不只是说 ES6+ 已经可以满足我们的需求，事实上确实如此。我们通过直接操作 DOM 并将其视为状态存储而陷入了困境。正如我开头所说，用户期望以及随之而来的复杂性正在上升。我们需要管理这种复杂性。
状态 是一个重要的概念，正如 我们讨论过的。网站将通过思考需要管理哪些状态来构建，然后为这些状态构建合适的存储。
新的框架已经到来。Ember、React、Vue、Angular、Svelte 等等。它们适应了使用状态、组件和为我们处理 DOM 的理念。
现在它们可以竞争速度、功能和 API 的友好性。
TypeScript 似乎也是一个长期赢家，因为它可以与任何东西一起使用，并为开发人员带来稳定性和更好的编辑体验。
我们不是在构建页面，而是在构建系统。
风格指南。设计系统。模式库。这些东西正在成为网页项目流程的标准组成部分。它们可能会成为主要交付成果。一个系统可以构建任何需要的东西。“页面”的概念正在消失。组件被拼凑在一起，构建用户看到的东西。这种拼凑可以由 UX 人员、交互设计师，甚至市场营销人员完成。
新的 JavaScript 非常适合这种情况。
原生和网页之间的界限正在变得模糊。
Sketch 和 Figma 哪个更好？我们根据它们的功能来判断，而不是它们是原生应用程序还是网页应用程序。我应该使用 Slack 或 TweetDeck 的原生应用程序，还是打开一个标签页？这两种方式的效果都一样。有时一个网页应用程序非常好，我希望它能成为原生应用程序，这样它就可以成为我 Dock 中的图标并具有持久登录功能，所以我使用 Mailplane 来访问 Gmail，使用 Paws 来访问 Trello。
我经常使用看起来需要原生应用程序的应用程序，但实际上它们在网页上表现得一样好甚至更好。仅查看音频/视频应用程序，Skype 拥有功能齐全的应用程序，Lightstream 是一个完整的直播工作室，Zencaster 可以录制多轨高质量音频。所有这些都在浏览器中。
这些仅仅是在网页上做得很好 的例子。网页技术本身也在大幅提升。Service Worker 为我们提供了离线功能和推送通知等重要功能。Web Audio API。Web Payments API。网页应该成为构建应用程序的主要平台。
用户会使用好用东西，而不会考虑或关心它是怎么构建的。
URL 仍然是一个杀手级功能。
网页在这方面做得很好。有一个通用的方法可以直接跳到查看特定内容，这是不可思议的。URL 使搜索引擎成为可能，这可能是人类最重要的创新之一。URL 使共享和书签成为可能。URL 为市场营销创造了一个公平的竞争环境。任何人都可以访问 URL，没有守门人。
性能是一个关键因素。
对性能不佳的网站的容忍度会降低。每个人都期望一切都能立即完成。性能不佳的网站将令人尴尬。
CSS 将变得更加模块化。
当我们编写样式时，我们始终会做出选择。这是一个全局样式吗？我是否故意将这个样式泄漏到整个网站中？还是我正在编写特定于这个组件的 CSS？CSS 将在这两者之间被分成两半。特定于组件的样式将被作用域化并与组件捆绑在一起，并在需要时使用。
CSS 预处理将逐渐消失。
预处理器的许多杀手级功能已经进入 CSS（变量），或者可以通过更高级的构建过程（导入）更好地处理。我们最终用于模块化和作用域 CSS 的工具在某种意义上仍然是 CSS 预处理器，因此它们可能会接管预处理必要性的剩余部分。在当前预处理器的标准集合中，我认为我们会错过的是 mixin。如果原生 CSS 能够实现 mixin（可能是 @apply）和 extends（可能是 @extend），这将加速当前预处理器的弃用。
精通 HTML 和 CSS 仍然至关重要。
HTML 的构建方式以及它最终出现在 DOM 中的方式将继续发生变化。但您仍然需要了解好的 HTML 看起来是什么样子。您需要知道如何以一种对您有用、对用户可访问且适应样式的结构构建 HTML。
CSS 在浏览器中的呈现方式以及它的应用方式将继续发生变化，但您仍然需要了解如何使用它。您需要知道如何完成布局、管理间距、调整排版，并保持良好的品味，就像我们一直以来做的那样。
构建流程将变得更具竞争力。
由于性能至关重要，并且在性能方面有很大的改进空间，我们将看到将代码库推送到生产环境中的创新。像 webpack（树摇、代码拆分）这样的工具已经在做很多事情，但仍有很大的空间让自动化工具对最终如何将代码交付到浏览器进行魔法般的优化。优化首屏加载。按重要性顺序交付资产。决定哪些内容发送到哪里，以及如何发送。不发送任何未使用的代码。
随着 Web 平台的演进（例如客户端提示），构建流程将进行调整，最佳实践也将随着它不断演进，就像它们一直以来那样。
你说
“页面”的概念正在消失。
然后你说，关于 URL：
有一个通用的方法可以立即跳转到查看特定内容，这太棒了。
如果页面正在消失，我们跳到什么地方呢？
一些组件的组合。如果你想称之为“页面”，没问题，但我认为你明白我的意思。任何给定的视图不再是某个固定在位置的 Photoshop 合成文件（并且被这样描述）了，尤其是在展望未来时。
扩展这个想法，你可以看到 URL 如何成为状态的标识符。如果状态定义了组件的组合，而 URL 则原则上必须指向我们特定的信息。
抽象地，你可以称之为“节点”（如 JJG 的《用户体验要素》中所述）或“视图”。
我相信 Web 的根本目标是共享信息。
我发现人们在手机上主要消费信息（除了分享图片和短评）。
人们在电脑上主要创建内容。
根据你的上下文，你可以在页面和视图之间更改术语。
但从定义上来说，页面是可搜索的，而搜索视图毫无意义。因此，你倾向于为每个页面生成的 HTML/CSS 代码是不同的。
我认为你上面提到的大多数要点都适用于 Web 应用。
你跳转到体验的特定状态。它应该是静态的页面式界面还是在线应用程序的状态？关键是你不会将一个东西（=== 页面）添加书签，而是将你希望稍后在浏览器中重新创建的信息（=== 状态）添加书签。
我们将跳转到一个资源。资源不必是页面。我想这就是它的意思。:)
我认为 Chris 谈论的是 RESTful URL 结构，其中系统状态以 URL 表示。这实际上是一个非常好的做法。
看看https://www.slideshare.net/landlessness/teach-a-dog-to-rest，了解一些非常有趣的见解和启发。
很棒的问题。我个人很喜欢 PJAX 如何融入以上所有内容：构建一个扁平的 CSS + HTML 网站，然后 JavaScript 处理内容的动态加载，同时更新 URL 和历史记录。有时间试试 Barba.js 吧！
好点！感谢你的提示
我认为，“系统”的迷恋会损害很多项目/人员。玩玩玩具很有趣，但最终你必须现实地看待你发布的东西。
如果你正在构建 *一个可查看的网页*，你可能不需要系统。你可能只需要一个 HTML 文件和一个 CSS 文件。
我认为重点是你不应该每次构建页面时都构建一个系统。就像每次你想构建一辆自行车时都要重新发明轮子一样。
这些“系统”应该存在，以便在你需要发布一个可查看的网页时，以及在你或其他人用修订、更改、更新等重新发布该网页时使用。
这是对每个人来说 Web 的最终民主化，而且已经持续多年（参见任何 CMS、GUI 或网站构建器）。
就像 Squarespace 和类似公司通过模板来管理基本网站的设计和开发一样，将会有新的产品为更复杂的 SaaS 产品做到这一点。我认为我们正走向一个未来，在这个未来，会有设计师和 UI 工程师在 GUI 中工作，而软件工程师则构建构建事物的东西。
因此，我认为我不赞同 HTML 和 CSS 知识将至关重要（从长远角度考虑）的结论，但设计感将是至关重要的。对于混合型设计师/开发人员的需求可能减少，因为随着 UI 层的抽象，对这种技能的需求会减少。工程师将需要更加专业化，以理解在规模上处理 AI 和庞大互联基础设施等复杂性的复杂性。
你写道
“用户期望不断提高。”，以及
“对网站的要求越来越高。要求开发人员快速构建非常复杂的东西，并且使它们能够很好地运行，速度很快。”
我认为 *用户* 并没有要求所有这些。客户可能会 *认为* 用户想要脚本繁重的多功能“系统”，但我对此持怀疑态度，这并非基于经验证据。
我只想阅读新闻报道或查找一些信息。我不想要花哨的弹出菜单、形状变化的视频窗口和几十个基于脚本的跟踪小部件。我相信人们也这么想。
哎呀！我的意思是“我相信很少有人这么想。”
你想错了。
几年前，如果你查看一个网站购买演唱会门票，例如，你可能会找到拨打票房电话的信息。但是现在，你希望看到座位图、关于哪些座位可用的实时数据，并能够在网站上结账。
几年前，你的银行可能允许你登录并查看你的余额，但现在你想搜索这些项目并按日期过滤，或者在你的储蓄和支票账户之间进行即时余额转账，订购一张新的借记卡，与可以告诉你 *为什么* 一项给定费用被拒绝的人实时聊天等等。
我想，这就是 Chris 想要表达的复杂性。不仅 UI 会变得复杂，而且甚至为这些东西提供动力的所有后端服务和数据也会变得复杂。
如果你把上下文限制在信息网站，这个观点是合理的。
我认为，Chris 这里主要谈论的是 Web 应用开发的增长，而不仅仅是 UI 技巧。
人们对整合用户生成内容的需求不断增长，使用前端堆栈完全为复杂的渐进式 Web 应用提供动力的能力是一种越来越受欢迎的方法。
不，人们不会仅仅上网然后说“我想要用最流行的 JavaScript 库/框架编写的单页面应用”。我完全同意你的观点… 但是…
人们，无论承认与否，都期望这些东西。人们期望即时加载。人们期望应用程序以特定方式运行。这是真实的数据。这是真实的证据。转化率会根据网站的速度而增加（或减少）。UI/UX 变得越来越重要。你可能只想阅读新闻报道，但大多数人想要更多。他们想要实时体验。他们想要浏览器中的 AR/VR。他们想要快速和即时。如果你认为事实并非如此，你就没有足够深入地研究这个话题。
“jQuery 对我们来说非常棒，但它在新的开发中已经结束了。”
jQuery 的流行程度可能超过了它应有的程度，或者在它不是最佳工具的情况下被使用，但这并不意味着它会或应该“结束”。正如你在开头所说，数据总是最好的。
https://trends.google.com/trends/explore?date=all&q=jquery,ember,react,ember,vue.js
https://insights.stackoverflow.com/trends?utm_source=so-owned&utm_medium=blog&utm_campaign=trends&utm_content=blog-link&utm_term=state-of-mobile&tags=jquery%2Cember.js%2Creactjs%2Cangularjs%2Cvue.js
jQuery 的早期主导地位确实有所下降，但我认为未来将是各种框架/库的混合。我认为 jQuery 将在其中占有一席之地，这不是一件坏事。
虽然我非常喜欢 jQuery，但 Chris 所说的是，未来将涉及采用与 jQuery 本质上不兼容的开发模式。
jQuery 就像一台可靠的旧录像机：它可能仍然是市场上最好的录像机，但现在人们使用蓝光光盘了。即使是最好的录像机也无法播放蓝光光盘。（注意：这个比喻可能对于那些太年轻而记不起录像机……或者 jQuery 的人来说不适用；）
“jQuery 就像一台可靠的旧录像机：它可能仍然是市场上最好的录像机，但现在人们使用蓝光光盘了。”
根据谷歌趋势和 Stack Overflow 的洞察，jQuery 目前仍然非常流行。我认为，预测 jQuery 在 10 年内会像 Vue 或 Ember 一样规模庞大，这不是一个冒险的声明。如果有什么不同的话，它对 Vue 和 Ember 的乐观程度要高于 jQuery。除了会议和播客圈之外，人们仍然使用 jQuery 做了很多很棒的事情。
此外，我已经近 10 年没有使用蓝光光盘了，流媒体可能是一个更好的比喻；）
在 URL 方面，你完全说对了。
这就是我认为像 Google AMP 这样的东西如此令人沮丧和倒退的原因之一（还有其他几个原因）。为了追求一个值得的目标，他们破坏了已经正常工作的东西——而且，当我戴着锡箔帽的时候，这看起来像是出于想要更彻底地控制对网络的访问和在网络中的流动。
没有守门人 FTW！URLs4eva！
Chris，我知道你只是一个普通人：但我认为你是绝对正确的。特别是关于用户期望、状态和模块化。
我很好奇你是否担心 React、Vue 等 10 年后会成为我们后悔建立在它们之上的东西之一？
……我说这话是因为我真的很享受使用这些系统。
就像 Jeremy Keith 的“弹性 Web 设计”那种感觉吗？
我有点怀疑。它迫使我们以基于 JSON 的状态进行思考和工作，在我看来，这种状态应该会持续下去。它还鼓励从 API 获取数据，这似乎也是一个应该持续下去的好计划。
React、Vue 及类似技术只是对未来 Web 开发的快速尝试，即使没有框架，Web 开发也应该成为这样。随着 Shadow DOM 和 Web Components 的所有部分在 Web 平台上得到正确实现，可以说这些系统是未来 Web 开发的未来。
我认为区分构建 Web 应用和 Web 网站很重要。显然两者之间有很多重叠，但如果你为公司构建营销网站，那么你的工具集就会变得小很多。例如，构建工具和预处理器仍然非常重要和有用，但状态管理在很多情况下就不那么重要了，甚至完全没有必要。
似乎大多数创新都是由 Web 应用开发者推动的（这很棒），而 Web 网站开发者需要更加谨慎地选择任何新技术和方法，以避免最终得到一个过度设计的最终产品。
我认为“过度设计”不好的说法站不住脚。如果“过度设计”一个项目只需要 2 个小时，并且可以提供很多不错的功能（随着时间的推移，这些功能可以加快开发速度），为什么不过度设计呢？
一旦你学会了在 React 等框架中工作，并了解了 Webpack 的工作原理，实现工具链就会变得微不足道。
所以我说，继续过度设计。
@Jared
但是过度设计永远不会只花费你两个小时。你需要最初的时间来设置好所有东西（最初的东西让你在两个小时内完成任务成为可能）。
如果你要雇用新开发者，就会有额外的入职时间，学习曲线会更陡峭，找到合适候选人的障碍会更多等等。当然，这会根据你的公司而有所不同（你是否作为独立的自由职业者工作？一个拥有几名到十几名工程师的代理机构或创业公司？一个拥有数百到数千名工程师的企业公司？
在我目前的工作中，我们大约有 20 名工程师共享组件。即使是像额外工作一个小时这样微不足道的事情，也会有 20 倍的乘数，因此必须始终权衡利弊。
话虽如此，我并不是说工具不好。（我们个人将一个非常复杂的构建系统换成了一个非常容易的开发周期，这效果很好……直到构建系统遇到问题，几个开发者花了好几天才弄清楚，然后不得不与所有其他 UI 工程师分享结果）。
我只是说，你不能天真地认为更多的工具和系统总是好的，并且认为某件事总是只需要 2 个小时是一种错误的心态。:)
我不认为我暗示了这一点。我认为你错误地假设现代工具“永远不会只花费 2 个小时”。当然有培训和入职。我已经使用 React 和 Webpack 一段时间了，我可以花 30 分钟搭建一个静态网站。
当然，你为你的团队制定了培训预算？我们定期举行会议来讨论我们的技术栈并听取意见。这无疑是开发成本。
将“新颖且比我目前接受的复杂”与“过度设计”混为一谈是错误的。
当然，一家商店仍然可以运行一个 SASS 支持的 Gulp/Grunt 系统，并生产出很棒的产品，但停下来问一下工具是否可以改进并不坏。
一旦你理解了 Webpack 和 HMR 的概念，并体验过它们，你会感觉自己像一个新手开发者。
即使 Web 每天都在快速变化，但令人欣慰的是，基础的 HTML 和 CSS 仍然是今天制作网站的关键，跟上这两种语言至关重要。
不过，JavaScript 正在统治 Web，我很好奇会有什么东西取代 jQuery。总有一天，总得有东西取代它。
我认为构建处理正在消失。ES6 类可以正常工作。
CSS 有变量。
不能进行服务器端渲染的东西。
所有这些对我来说都很奇怪。我学到的是 HTML 代码放在 HTML 文件中，CSS 代码放在 CSS 文件中。类名应该描述元素而不是属性。好吧，使用所有这些前端框架，似乎不再是这样了。即使你使用像 p50 这样的 CSS 类来表示 50 像素的填充。这就是为什么很多人回到根源，或者只是使用 Susy 的原因。
模块化 JavaScript 的炒作也是如此，比如 React。将 CSS 从这些文件再次分离，即使一开始听起来不错，但也很可怕。
我认为所有这些都应该回到它们的根源。是的，使用最终产品的人并不关心它是如何完成的，但那些将继续维护产品的人会关心。当那些制作了这种高端垃圾的人离开公司，或者这种技术过时了——向客户解释这种情况。
仅仅因为某件事现在很流行——稍微思考一下。
我认为 Ben 说到了点子上。Web 应用是一回事，Web _网站_是另一回事。我认为这篇文章的大部分内容都适用于 Web 应用，而不太适用于 Web 网站。例如，一个干净的、几乎没有插件的 WordPress 网站，加上一点 jQuery 来实现一些滑块和其他交互式组件，仍然是为非技术客户构建简单宣传册网站的最简单方法之一。React、Angular、Vue 和所有其他“当前”Web 应用技术很少适用于这样的网站（如果适用，它可以仅加载在网站的特定区域，例如使用 Angular 构建一些可视化应用程序在一个否则为静态的网站上）。
我同意。这篇文章需要在顶部进行大规模澄清，说明这些评论是针对 Web 应用的，而不是针对 Web 网站的。
我发现，在构建了大约 18 年的网站之后，我需要做的工作 _更少_ 了，我想要的东西比过去 _更简单_ 。
我使用使 HTML/CSS/JS 更易于编辑、更易于访问的框架，而不是更难。React、Anglular 等……是针对应用程序的。我可以一键启动一个全新的网站。我无需编译任何东西。网站只是 URL 上的内容。它们 _就是_ 页面。
Web 应用与 Web 网站完全是不同的动物，网站的未来肯定与 Web 应用不同。
SASS 会被取代，jQuery 会被一个更小的、完成相同简单任务的库取代（或者 jQuery 会被精简）。滑块和画廊不需要专门的 React 程序员来构建。但最有可能的是，会使用组件。
我将扮演一个唱反调的角色，预测 React 会把自己局限在一个角落，以满足 Facebook 的需求，而损害了其他人的利益，它将成为框架中的 Prototype.js。Google 会像对待 Angular 一样对待 React。
但是，网站在很长一段时间内仍然会是 HTML、CSS 和一些 JS，用于增强网站的趣味性。也许会有一些新的东西出现，但我怀疑它会改变基本原理。
网页仍然是网站的 URL... 尽管可能不是 Web 应用程序。
相关：https://css-tricks.cn/poll-results-sites-vs-apps/
我发现自己对您的大多数敏锐观察表示赞同，除了两个。
CSS 预处理器本身不会消失。它们只会逐渐融入通用的构建管道，这些管道将不同语言的通用语法树抽象为一个高效的流程：想想 Babel，但不仅仅用于 JavaScript。一旦开发人员问自己为什么要运行多个引擎来完成基本相同的任务，很快就会找到解决方案。此外，未来的构建流程将更加关注产品性能，而不是开发人员体验。
从用户的角度来看，原生和 Web 之间的界限只会变得模糊。对于开发人员来说，为了运行 2MB 的代码而发布一个 40+MB 的运行时（以 Electron 为例）是没有意义的，而不是一个 5MB 的原生应用程序，它将比 Web 应用程序性能更高。只有当移动和桌面操作系统都同意 Web 应用程序的通用格式，允许在任何地方简单安装时，Web 应用程序才会取代原生应用程序。
像 Foundation 和 Bootstrap 这样的框架在这一切中扮演着什么角色？它们会被 jQuery 抛弃，还是会适应这些框架？
我发现，由于 Flexbox、Grid、CSS3 以及移动设备接管（使用现代浏览器）和自动更新浏览器（常青树）等因素，这些框架不像以前那样有用。
Bootstrap 之于 CSS，就像 jQuery 之于 JS？这不是一个完美的类比。但我确实看到很多网站使用 Bootstrap，我认为这是一个有用的技能，但在我的工作中，我们放弃了 normalize，几乎所有的 shim/shivs，并创建了我们自己的兼容 CSS 框架，适用于所有现代浏览器。
它干净、轻便、易于使用，我们可以随着时间的推移进行扩展和修剪。相比之下，其他框架现在已经成为一个巨大的开销。
但我发现，只需要专注于一个网站（比如一个大型公司网站）的开发团队更有可能使用和获得 Bootstrap/Foundation 的价值，而不是那些定期构建新网站的网页设计师。
主要是因为如果你雇用/解雇员工，人力资源部门很容易说“你会使用 Bootstrap 吗？”
... 但你仍然需要（知道）如何使用它。
WebAssembly 在未来前端开发中扮演着什么角色。
我认为，它将发挥巨大的作用。看看 TJ 在下面对此的看法。请记住，TJ 是 Node.js 的核心贡献者，并创建了我们今天使用的许多库/工具。这家伙简直是个天才。此外，只需忽略 Go 与 Node 的争论。他在这篇文章中谈到了 WebAssembly。
https://medium.com/@tjholowaychuk/go-blows-away-node-in-pretty-much-every-way-3b412b5050d8
“扩展这个想法，你可以看到 URL 如何成为状态的标识符。如果状态定义了组件的组成和 URL，原则上，必须将我们指向特定的信息。”
如果你仔细想想，这正是 URL/URI 的作用。它们是统一资源定位器/标识符。
人们不能只是在服务器端运行他们的应用程序，通过 WebSockets 传递它们，然后就完事了？或者更妙的是：使用 X11 协议传递它们，完全绕过浏览器。因为这不是“网络”，而是“通过 HTTP 传递的 JavaScript 程序”。
开个玩笑：在我看来，网络开发者及其直接客户似乎生活在一个虚幻的宇宙泡泡中，在那里每个人都拥有高速连接，并且每年都会升级到一台新的高端电脑。（从而导致全球电子垃圾的产生。）与此同时，普通的 Joe 和 Jane 则抱怨那些缓慢、无响应的网站。
仅仅将一张图片发布到一个所谓的最先进的网站，是否真的需要比运行 Photoshop 更多的系统资源，包括处理器时间和内存消耗？
这让我梦想着一个新的运动：我希望它被称为“回归网络！”运动。在这个运动中，人们如果只是提供一家公司的联系方式、产品信息和订单表格，就会称之为“网页”。人们通常会坚持这种模式：“HTML 用于内容，CSS 用于展示，JavaScript（适度地）用于交互”。
我同意，我们正在构建系统。但这些系统应该在编译时将模块组合在一起。因此，结果是一个快速、精简、流畅、美丽的网页。Sass（或更强大的继任者）将继续存在。在未来，它将被用于编写完整的 CSS 编译器。像 True 这样的库将在这方面提供帮助。
是的，拜托。人们怎么能接受一个只有文本段落的页面需要 1.5MB 的 JS？令人难以置信。 “回归网络！”运动是我 https://radogado.github.io/natuive/#showcase 的一部分。
此致。
你确实总结了很多！设计系统、客户期望——我最近一直在深入思考这两点。设计正在走向工程领域，在某种程度上可以实现半自动化。这既令人恐惧，又非常解放，因为它可以让设计师更加专注于系统的整体设计，而不是界面。
设计领域让我真正担心的一点是，现在大多数设计都集中在产品和应用程序上，而不是我们认为的传统“店面”网站。我们是否正在为传统网站复杂化流程？我不这么认为，但值得考虑。
这就像“流行音乐”，很少能有很长的生命周期。几年前是“延迟加载”，“只加载你需要的”。现在是 Webpack（和其他），“一次加载所有东西”。然后你只需要手动下载一个 CSS 和 JS 文件并放入文件，现在需要初始化一个项目，安装依赖项，下载依赖项，转译-编译-
缩小-注入-等等... 依赖项。想想吧 :) “React”现在很流行，就像几年前的“Angular”，就像几年前的 jQuery... 好吧，有时候（就像 Phil Nelson 的回答）你只需要一个带有 CSS 的 HTML 文件。
温馨提示
这是一个 该死的网站。
作为一名设计师，我一直参与一个使用 React 制作的大型 Web 项目。
我对这个框架炒作仍然不明白的是
为什么突然每个人都在炒作这些框架，而它们在分离标记/内容/样式方面做得非常糟糕。多年来，所有的网页大师一直宣扬分离是关键。但现在不再是了吗？
既然我们在这里预测，我预测 React 将成为一项让人深深后悔的技术，因为它在 JavaScript 和普通 HTML 之间造成巨大的混乱。
我同意你关于 React 的评论，即使这会激怒其他开发人员。我喜欢使用它，你可以用它实现一些非常酷的东西，但对我来说，将所有标记、内容和样式放在一个地方感觉很脏…
这个领域的一个论点是，当你将代码库沿着 HTML/CSS/JS 线分开时，你实际上并没有进行解耦，你编写的 CSS 仍然依赖于 HTML，而 JS 可能影响 HTML 和 CSS。因此，即使你的代码被拆分为不同的文件，它们在功能上仍然紧密耦合，相互依赖。
React 抛弃了这种模式，提出了一个新的概念，即一个“组件”的所有代码都存放在同一个文件中，这些组件很小且可重用，因此关注点的分离理念仍然存在，但“关注点”不一定是标记、样式、行为，而是完整的 UI 和功能的各个部分。
我理解这个想法，当你开始使用 React 时，它会让你感觉很恶心，但一旦你习惯了，它就开始变得有意义了。
也就是说，我认为这个想法在未来几年还有更大的发展空间，我们可能会看到一些更合理的模式出现。
我还要补充一句
HTML/CSS/JS 的拆分本质上只与随着时间的推移简化代码库的维护和添加相关（因为它们在功能上仍然相互依赖）。
React 的组件组合方式看起来和感觉起来很奇怪，但可以说它使这项工作变得更简单，因为我们不需要在三个不同的地方来编写一个东西，也不需要在三个文件中交叉引用类名，因为与我们正在处理的内容相关的一切都在一个地方。
感谢你的回答，你关于不同文件之间关联性的说法绝对正确。
这仅仅是逻辑上的分离；当我构建 HTML 或 JS 时，我不关心样式，只关心名称。
当我构建 JS 逻辑时，我不关心 HTML 结构，等等。
我只关注当下需要的部分。
我手头上还有像你描述的 React 逻辑一样构建的 Knockout 项目（我承认我对 React 了解不多），所有内容都在一个文件中，双向绑定与 HTML 混杂在一起；一开始很奇怪，后来变得非常简洁和短小；然后，维护起来越来越困难。
哦，调试也是一场噩梦。
我可能会在以后再尝试，至少等到某个库成为市场上的明显赢家，就像多年前 jQuery/MooTools/Yui/etc 那样。
目前看来 Angular 占主导地位，但情况变化很快。
这就是你需要渐进式设计的原因。
如果你的 HTML 依赖于 CSS 和 JavaScript，那么就说明哪里出了问题。
每个都是增强用户体验的层级，但不是必需的。
将代码拆分为不同的文件肯定会增加一些开销，但你也会将组件拆分为单独的文件。
我发现组件层次结构比你可能想到的 HTML/CSS 组织更加严格。
没错，我完全同意它非常严格。别误会我的意思，React 的做事方式非常有指导意义，并不是任何东西的替代品，它只是以一种不同的方式处理关注点分离问题，这看起来很有趣。我目前更倾向于在传统网站或 WordPress 网站中将 React 或 Vue 用于更小、更不重要的东西，比如“小部件”。
在我看来，称 jQuery 为过去是完全错误的。
它只是一个工具，在很多情况下是最好的工具。
我尝试过并使用过 Angular、React，还有几年前的 Knockout，我在一些小项目中使用它，它们确实加快了开发速度；但是，当项目变得庞大而复杂时，根据我的经验，没有什么能比得上对高质量的基本 JavaScript、类和模块以及简单约定（没有外部库依赖关系）、内容分离（page.html、page.css、page.js）以及 jQuery 工具（用于 DOM 构建和交互）的清晰理解更胜一筹。
哦，还有用于 CSS 的 Less/Sass。
我个人认为，HTML、CSS 和 JavaScript 正在越来越成为更好语言的编译目标。多年来，这种情况一直存在，例如 TypeScript、CoffeeScript、LESS/SASS 等等。在我目前的前端工作中，我已经很久没有编写过一行纯粹的 HTML、CSS 或 JavaScript 代码了，因为我们使用更好的技术（比如 ClojureScript），这些技术只是编译成浏览器可以理解的这些语言。
我同意这篇博文中几乎所有观点，但我认为唯一不足的是，JavaScript 作为从其他语言编译的平台或目标将会非常重要。我们已经看到像ELM、ClojureScript、Scala.js 等语言已经成功做到了这一点。我认为这将非常重要，因为尽管 JavaScript 随着每个版本的发布而变得越来越好，但它仍然是一种相对脆弱的语言，许多人因此不喜欢它，因此，像我们一直以来在后端开发中拥有的替代方案一样，这绝对是一个巨大的胜利。
我发现了一个错别字：“但你仍然需要知道如何使用它”