原副标题：“我历经了将近二十年的‘妄想’：当代 Web 合作开发，非 JavaScript 架构不容！”
| CSDN（ID：CSDNnews）
前段时间，网路上广为流传着许多探讨当代 Web 合作开发的文章，我看后很恼怒。
未来是 AngularJS 的四海？
我提过，做为一位专精 Web 合作开发者，第二次觉得自己丧失对现实生活的把握住是在 2010 二十世纪后期。多年来，我融洽地使用 Ruby on Rails 控制技术栈向顾客交货了有价值的应用软件。Ruby 很棒，插件和对外开放互联网国际标准总算显得愈来愈好了，积极响应式结构设计和渐进进一步增强等基本概念也大行其道了，互联网合作开发显得愈来愈有意思了。
不过，忽然之间，我听见很多相关 AngularJS 的传言（第一卷 AngularJS，并非而后全数改写后的那版）。与我以后碰到的很多视Mundolsheim（比如说我对个人最喜欢的 Knockout.js）不同，并并非说你在页面上有录于 AngularJS 标识符，就能赢得许多捷伊可视化潜能。
人们说这是两个后端架构，是Web合作开发的今后。你能用 AngularJS 构筑整座插件，你能将伺服器的基础建设变革为 JSON API，即使无须需要伺服器图形 HTML。在 Java 顺利完成图形以后，你看见的页面整座盲点，这并非严重错误，而要两个机能！
没人即使说我，做为 Ruby on Rails web 合作开发者，我的控制技术已无法在“当代”合作开发中立足。我必须加入 AngularJS 阵营，否则就会被时代淘汰。我提过，当时在从旧金山回湾区的路上，我与一位 Rails 合作开发者进行了长时间的交谈，我们谈到了对于必须成为“AngularJS 合作开发者”并放弃 Rails 的想法，我对个人是非常抗拒的。
多年后，我才发现做为一位 Ruby on Rails 合作开发者，我掌握的控制技术比在 2014 年转为全职 AngularJS 合作开发时更有用。
事实证明，今后并非 AngularJS 的四海
那么，如今掌握编写 React 插件的合作开发者，会不会像 10 年前编写 AngularJS 插件的合作开发者一样，在漫长的控制技术发展史中走入绝境呢？谁也说不好。
但我非常肯定，这完全有可能。
这就是为什么我非常反感下面这样的争论（注意，下面这些言论引自 Laurie Voss 的该文）：
React 节省了合作开发者的 时间：随着时间的推移，React 之类的架构能节省合作开发者的时间，这一点毫无争议。 React 能帮助你解决很多问题：互联网效应是我们选择 React 的部分原因，无论这门控制技术的优点在哪里，目前这是很多基本插件的最佳选择，因为React 生态系统提供的已有解决方案和具有良好文档的样板文件能帮助你顺利完成80%的目标。 你能雇佣掌握 React 的人：React 合作开发者更容易招聘，了解 React 的合作开发者不需要太多入职培训，而且使用自己喜欢的架构能让合作开发人员更快乐，所以 React 合作开发者也不容易跳 槽。 合作开发者的时间比许多顾客更有用：如果网站结构设计需要让每两个地方、每一台设备上的每一 位顾客都有完美的体验，那么合作开发者就需要将全数时间都投入到优化工作上，永远没有时间发布任何新机能。 现状是在合作开发者和顾客体验之间寻求平衡：我们观察到的现实生活是当代 Web 合作开发牺牲了用户的体验，我们的模型解释了为什么：X > Y，其中 X 是“成本” 合作开发时间”，Y 是“顾客流失成本”。 你做得很好：小伙伴们，不要觉得自己很愚蠢。不要被花言巧语所蒙蔽。你一直在为自己和用户的最大利益做出明智的决定，不需要因为使用流行的架构而内疚。这些架构之所以受欢迎，因为它们都很优秀。请等一等，为何这些话听着如此耳熟？你知道我在哪里听过吗？没错，就是 10 年前兜售 AngularJS 的大佬们！
我很恼怒
我很恼怒，因为在过去二十年中，Web 合作开发有很多像我一样的人都觉得我们反复成为煤气灯效应（一种心理操纵的形式，其方法是两对个人或两个团体隐秘地让受害人逐渐开始怀疑自己，使其质疑自己的记忆力，感知力或判断力，其结果是导致受害者的认知失调和其他变化，例如低下的自我尊重）的受害者，而且这些人还拒绝承认已经造成的伤害。
后端 Java 架构吞噬 Web 世界的时代，SPA（单页插件）等等，这些想法的出现并并非因为许多好心的合作开发者发现了很棒的合作开发体验，全心全意地支持并推广了，而要因为我们被欺骗了。
没人大肆宣扬以 HTML 优先、SSR 优先、逐步进一步增强的心态编写插件，使用我们喜欢的语言/控制技术，统统过时了，而且对用户很不利——不过，这不过是个谎言。
没人宣扬说，完全使用后端Java 编写插件会减轻我们的负担——这句话也是谎言。
注意，没没人会因为选择 React 而责备或辱骂合作开发者。
有两个小而强大的“影响者”生态系统在互联网路上兜售一种“流行文化合作开发者抽象”的精神，无论是 React、CSS-in-JS、Tailwind CSS、“无伺服器”还是“微服务”，都是他们为了制造煤气灯效应而编造的以假乱真的谎言。
说到底，这根本并非 React 与竞争对手的问题，即使并非架构的问题，而要两个你是否信任合作开发者社区的问题，因为这些合作开发者社区经常被虚假和误导性信息给淹没。
达尔曼曾说：“信任需要数年时间才能建立，而打破只需要几秒钟，而且永远无法修复。”
停止修正主义历史！
再说一次，本文没有针对任何人，但由于我需要反驳许多人的看法，所以不得不指出下面这条评论：
世上不存在由一群魅力四射的大人物组成、试图摧毁整座世界的秘密团体，也并非说这个世界没有这群人就会显得完美。我们不能因为事态的发展而责怪任何人，是我们共同创造了这个世界。
我们？我们是谁？下面的列表包含了几个主要的 Web 合作开发社区，多年来他们一直在努力对抗后端 Java 带来的恐惧和疑惑，以及基于 NPM 的构筑工具带来的冲击：
Ruby / Rails Python / Django Elixir / Phoenix PHP / Laravel SSG，比如说Jekyll、Hugo、Eleventy以及前段时间的 Astro 等我们并并非要求你一时头脑发热放弃自己最喜欢的后端库，成为一位 Rails 合作开发者、Phoenix 合作开发人员或其他合作开发。我们只希望你们承认，多年来你们霸占并主导了 #WebDev 的话语权，忽视了我们反复尝试指出的 JS/SPA 方法的潜在缺陷和谬误，有时你们即使嘲笑我们在控制技术栈/语言/等方面的选择。
上面的评论说道“世上不存在由一群魅力四射的大人物组成、试图摧毁整座世界的秘密团体”，我真的很想知道平日里你们都与哪些人交流，因为日常与我打交道最多的项目和顾客都认为这个世上确实存在这样一群人。
我们认为，“Tech Twitter”以招揽到控制技术人员。
回事！
所以，恕我无法赞同“我们自共同创造了这个世界”这样的说法。是你们——JS 架构的铁杆粉丝——有意创造了这个世界，并将我们这些对此持怀疑态度的人永远排挤在外，到头来还表现得宛如一切都是自然进化的结果。
Web 过去是、现在是、永远是多语言的
Web 是多语言的。这意味着，构筑网站的语言和工具能由任何语言编写，能在任何类型的伺服器、任何类型的操作系统上运行，能通过任何类型的硬件，在世界的任何角落运行——因为 Web 的构筑基础是协议和国际标准。
没错，你需要了解 HTML 才能从事 Web 合作开发，但 HTML 能由任何工具生成，能由任何平台提供，而且任何插件都能使用 HTTP。
如果想从视觉效果呈现 HTML，你需要了解 CSS，而 CSS 的构筑、编写和提供非常灵活。说到底，HTML 和 CSS 只不过是某个地方的某些文件夹中的某些文本文件，你能利用任何控制技术架构动态呈现。
请注意，以上我没有提到 Java，因为构筑网站其实并不需要了解任何关于 Java 的知识！
构筑简单网站不需要 Java。Java 只是一种“附加”控制技术，是与 HTML 和 CSS 并肩的 Web 后端第三大支柱。我们需要的是 HTML、CSS 和Java，而并非 Java，Java 和 Java。
如果想成为一位 Web 合作开发者，基本上你只需要了解 PHP/Ruby/Java/C#/Python/Go/Rust 中任何你喜欢的语言，再加上 HTML 和 CSS 就齐活了。
如果伺服器端也使用 Java，也没问题。但是，如果你要求 Java 做为唯一的伺服器语言，搭建起两个架构/构筑系统/托管基础建设/模块生态系统的庞然大物，使用的语言是 Java + Java + Java + Java（以及现在的Type + Type + Type + Type），不仅会给全球 Web 合作开发行业带来巨大的负担，还极端排除异己。
这种思想基本上就是在说每一位不了解或不想了解 Java 的程序员都应被排除在当代 Web 合作开发之外！这也太荒谬了。不仅如此，这种思想还违背了互联网做为对外开放控制技术平台的精神。
Web 插件本身就不接受这样的思想，HTTP 不支持，伺服器也不支持。
提供证据的责任应由这些后端架构的铁杆粉丝来承担，而非普通的Web 合作开发者
提供证据的责任不应该落在优先考虑 HTML、多语言伺服器、极简主义后端、独立友好的 Web 合作开发实践的支持者身上。为什么他们要证明其方法应被视为行业的默认方法，并成为常见规模的网站和插件的最佳推荐实践？举证的责任应该由优先考虑后端架构社区身上，他们应该证明自己的架构是合理的。
坦白来说，我们无须信任你们了！我们厌倦了你们将近二十年的妄想。
每当我看见 JS 架构的铁杆粉丝又在我耳边吹风“你应该使用 SSR 以赢得更好的性能”时，我都会翻白眼，因为这样的话我们早在 2014 年就听过了。
每当我看见 JS 架构的铁杆粉丝又开始唠叨，利用“孤岛”来分离不同页面上的库和标识符包时，我都会翻白眼，因为在页面正常显示以后设法避免加载或执行巨大的 Java 包，这是 2014 年炒作的话题了！
每当我看见 JS 架构的铁杆粉丝又开始抱怨：“约定优于配置”、“快速加载时间”以及“伺服器直接访问数据库”以及所有热门的合作开发者经验时，我依然会翻白眼，因为 2014 年的非 Java 全栈架构中早就有了这些机能！
我与 Ruby 社区中的很多人交谈过，后端世界中愈来愈多的人开始尝试使用“普通”的控制技术，回想这些年来 Web 合作开发一直在大量重新发明轮子，我们都会摇头感到沮丧。“Java 疲劳”不仅仅是一小群控制技术宅男中流行的表情符，这是两个实实在在的问题！
所以，每当听见下面这样的言论：
“全球有数以千万计的应用软件合作开发者，他们的工作都相对独立，而且他们会以不同的优先级、资源和权衡谋求最佳利益。结果造就了我们眼前的世界，尽管这并非两个完美的世界，但因为种种理性原因，最终达成了某种平衡。”
对不起，我认为这纯粹是胡说八道。我根本不相信这个世界存在，我认为的世界是这样的：
一群自以为是的 JS 架构铁杆粉（尤其是 React）认为“每对个人”都在使用 React，而且大多数人都喜欢这个架构，所以能有什么问题？！ 与此同时，大多数从事各种其他控制技术栈、语言和插件的人则认为“React 正在吞噬世界”之类的运动很疯狂，而且不利于 Web 的发展。我与多位初级合作开发者交谈过，他们觉得在学习 React 的时候觉得自己像个白痴，与其他更靠近底层硬件的 Web 合作开发形式相比，React 不仅令人倍感困惑，而且毫无意义，而他们还会因为不理解 React 而遭到批评。很多“后端”合作开发者讨厌后端合作开发，但我发现他们不一定讨厌后端合作开发本身，而要讨厌所有荒谬的复杂性。总的来说，这些复杂性是不必要的，只是因为 JS 架构的铁杆粉在背后推波助澜。还有如下 Voss 的这句话：
我绝对不会说大量使用 Java 的单页插件对性能有好处，因为它们确实对性能没好处。这些插件的加载速度很慢，图形速度也很慢，而且还占用了很多资源，通常比普通的 HTML 和 CSS 更脆弱。我认为 JS 架构的合作开发者普遍能够接受这些限制，这就是为什么伺服器端图形是当代架构的重要特性的部分原因。大多数 React 支持者会说你，并非每个网站都需要是 React 插件。我认为合作开发者并不愚蠢，所以他们知道在选择 React 时需要做出这些权衡。
什么？！我认为大多数 React 合作开发者没有做出任何权衡。我认为大多数 React 合作开发者都没有评估这个架构！他们之使用 React 是因为没人说他们必须使用 React，所以他们使用了 React。
如果真的是合作开发者都花了数小时、数天、数周即使数月的时间来评估各种后端架构以及构筑 Web 插件的其他方法（ Ruby on Rails、Elixir Phoenix等），最后得出两个结论，从各种需求和用例以及对个人喜好的角度出发，他们认为React 绝对是最佳工具……
太可笑了，我真的很难相信没人能够做出这样严肃的声明！
我眼中的 Web 世界完全不同。我认为，Web 合作开发的世界充斥着质量低劣的内容，很大一部分都是严重错误的，还有一群有影响力的大人物、教育工作者以及企业中坚力量，他们不遗余力地向每对个人灌输某种特殊的控制技术，或许他们知道这种控制技术本身就有问题，或者他们并不知道，但无所谓，最终结果都是一样的。
我不相信很多使用 React 的团队真的是因为出于控制技术的考虑，而有意选择了这个架构，也不相信选择这种控制技术能够帮助他们更好地构筑系统，还说这种控制技术有广泛的研究、测试以及事实的支持。
说到底，这不过是拼人气，简单明了。而人气随时可能发生变化：10 年前，人气之王是 AngularJS，而如今是 React。明天还不知道是谁呢，因为这是不可避免的。
不过真正的问题不在于 React，也不在于某对个人——问题是这个行业充斥着严重错误的思想，人们严重错误地认为：
流行控制技术之所以流行是因为控制技术本身很好； 即便到了 2023 年，Web 平台仍然很匮乏，因此高度抽象的后端架构仍然是提高程序员幸福指数的必要条件。这两种假设不仅大错特错，还非常危险，因为这样的思想正在引导成千上万的年轻合作开发者走上严重错误的道路。他们没有选择学习应用软件合作开发的基础知识：互联网、HTTP、多语言 Web 伺服器、HTML（包括自定义元素）、CSS（包括自定义属性），以及 Java，而要努力学习 React/Type。
我相信，到了 2033 年，做为一位 Ruby Web 合作开发者，我掌握的控制技术远比学习 React 赢得的任何控制技术更有用。
到时候，我肯定活得好好的，但那些只知道 React 标识符的新手程序员呢？也许他们的工作岗位早就消失了。
