校对 | 原子武器果汁、Tina
“2022 年已经来临，他们是时候深思 Web 合作开发中的诸多落伍应用软件、炒断章取义和荒谬趋势了。把握住这一年，他们也该再次著眼于性能与控制技术运用，把手段和目的再次统一起来。当然，我不是劝大家用编订或者 C 语言搞 Web 合作开发，但有关 JavaScript、Ruby on Rails、Python、Django 以及 PHP 架构的狂热观点也该停息一下了。”
这是一则充满著愤慨的博客。作者是一位出生于 70 年代的“控制技术公知”unixsheikh，并用“保守”的方式放出了一个观点：“Web 合作开发者应该耗费更多时间来进行强化”。
很显然，把难题归因于 Web 合作开发很多片面，但他的观点也确实高喊了许多人的心里话。该文发出后，有反对者给他发送信息说：“有关该文的难题，我也一直在跟自己的同学和伙伴们争辩。布季谢过一个项目工具，里面包涵 1786 个包、存有 69 项安全漏洞——45 个中信用风险、20 个高信用风险、4 个严重信用风险。其‘重约’432 MB，而且内部有如难以预料。更荒谬的是，用它甚至足以输入‘hello world’，因为还另外须要原则上的路由器包和状态管理包。这一切太狂热了，但每个人都在那条路上狂飙，还说白了‘当代方式’。”
还很多网民在 Hacker News 上该文说，“它包涵了许多让人无法接受的假话”。同时也有批评者说，“很多人都认为 Web 合作开发是一件不言而喻的事，不须要后端技师，他们的存有只是为了增加 JavaScript 的复杂程度，中文网站的 100% 功能都可以使用纯 HTML + HTTP 配置文件处理。但事实上 (IMO) 是：应用程序是‘新作业系统’。对于大多数消费者和应用应用软件，在应用程序中运行是不言而喻的选择。不管你喜欢它还是痛恨它，这就是当前的实现方式。”
相同的人协进会增添相同的观点，有争辩不一定是坏事，他们将 unixsheikh 的这首诗译者出来，希望可为听众增添许多思索。以下是他的撷取内容：
不是应用程序的错
谷歌 Chrome 正在主导当下的全球网络应用程序市场，新的难题也由此而来——作为一家实际意义上的广告商，谷歌正在不断推进极具欺骗性与威胁性的 Manifest V3 计划。
很多朋友天真地把 Mozilla 火狐看作挑战 Chrome 霸权的救世主与替代品。没错，火狐当初确实把他们从微软 IE 的魔爪下拯救了出来。但如今的 Mozilla 管理能力极为低下。2018 年，Mozilla 从各大搜索引擎厂商处获得了 4.357 亿美元收入，这笔钱主要用于在世界各地的火狐应用程序上强推默认搜索引擎选项。花钱的主要是谷歌，此外还有 Yandex 和百度。虽然形势还行，但 Mozilla 在 2022 年还是裁判了全球约四分之一（250 人）的员工，理由是新冠疫情造成的经济动荡“严重影响了公司收入”。但事实真是这样吗？胡扯，2018 年 Mozilla 掌门人拿到了 240 万美元，而且薪酬在过去五年中翻了一番还多。
Mozilla 再也不是那个厚道可靠的老伙计了，要想继续生存下去，他们必须得来一轮高管大换血、叫停那些没人想要的产品，再次回归以捐赠为基础、以客户需求为依托的发展道路上来。当然，以上都是闲话，只为引出第一个真正重要的难题。
他们为什么须要这些应用程序供应商？如果没有他们，不就没有这么多屁事了？我认为难题出在所谓“当代 Web 合作开发者”身上，他们才是罪魁祸首！
正是这帮所谓的“当代 Web 合作开发者”一直在用臃肿且毫无必要的 JavaScript 搭建中文网站，不断在并不适合的平台上进行 Web 合作开发。这相当于逼着用户使用大厂出品的应用程序，否则就没法正常访问互联网内容。
如果没有所谓的“当代 Web 合作开发”，他们根本不须要这些体量有如怪兽般庞大的应用程序。他们只须要简单的轻量化应用程序就能访问中文网站上的所有功能，且只有少数非常专业的中文网站才须要特殊解决方案。而即便如此，其中大部分特殊中文网站也完全不必依赖于大型应用程序。
Web 合作开发须要一场革新
我知道，很多 Web 合作开发者并不了解这些更靠谱的合作开发方式，但这不该成为理由。对于任何一位应用软件合作开发者来说，大家都应该在所用知识之外多学习、多接触新知识。他们须要了解什么时候适合用这款工具、什么时候适合另一款。我觉得是时候来一场 Web 合作开发大革命了，即除非绝对必要、否则尽量不在中文网站上使用 JavaScript。
在我看来，这应该是互联网中文网站未来发展的必要条件。特别是在“Web 3.0”概念正如火如荼的当下，我认为去 JS 化应该成为除去中心化之外最重要的探索目标。
之所以提出这样一个战斗目标，不只是因为他们对少数应用程序合作开发商的过度依赖引发了大量现实难题，更是因为整个过程正在白白浪费能源。臃肿的中文网站让每位访问者的电费飙升，从服务器端和客户端两方面增添了双输结果。
由于应用程序中 JavaScript 代码过多（看起来所谓的「当代 Web 合作开发者」根本不懂怎么在不用 JS 的情况下合作开发后端），所以用户即使是打开最简单的网页也会增加设备功耗。另外，由于采用不适合的服务器端架构（例如 Rails 和 Django），服务器的功耗也存有浪费。另外提醒大家，虽然互联网上运行的大部分中文网站由 PHP 编写，但其成本同样不低。PHP 本身自 v7 版本以来已经解决了内部与外部的一系列重大性能难题，也让功耗变得相当友好；但“当代 Web 合作开发者”们仍在使用 Larave、Symfony、Codelgniter 或者 Yii 等低效架构，这些架构的存有让 PHP 的改进变得毫无意义。
事实上，目前流行的所有架构都糟糕透顶。它们的合作开发大多基于抽象理论与设计模式，包涵不少跟现实应用完全无关的噪声元素。更重要的是，我呼吁大家直接放弃这些架构——因为性能强化离不开原始代码。他们应该远离混乱，而不是添加更多混乱变量。如果某款应用软件输入个“Hello world”都须要 75 个类或者模块时，它是绝对没有任何性能强化可言的。回归简单、小型和高度强化过的专用库，告别架构，好吗？
过去他们讨论 Unix 的时候，常常会想“还有哪些可以丢弃？为什么会存有这个选项？”这是因为基础设计协进会包涵缺陷，完美的设计点是个永远无法达成的目标。所以与其匆忙添加选项，不如想想哪些选项是真正的“不能没有”。― Doug McIlroy
就 Rails 和 Django 而言，项目组明显不理解上面的观点。Ruby 和 Python 就不该被用于 Web 合作开发，因为它们太慢了、根本不适合。大家甚至可以用 Bash 创建并运行中文网站，行是都行、只是不明智。
很多人认为合作开发者的时间比计算资源更宝贵，而 Rails 和 Django 的目标就是帮助人们快速完成工作。但这也正是难题所在：如今整个互联网面临的过度臃肿难题，就是由这些不负责任且短视的观点所引发。快就一定对吗？显然不是。
作为个人建议，如果您正是一位“当代 Web 合作开发者”，强烈推荐您使用 Go 语言进行 Web 合作开发，但后端不要使用 JavaScript。最重要的是，尝试在不用 Go 标准库的情况下进行 Web 合作开发。这不仅是一段学习经历，也会给您增添宝贵的提升和启发。
给 Web 合作开发者的建议
如果您身为 Web 合作开发者，希望能认真考虑以下几点：
如果您在大学或者培训机构里学过“当代”Web 合作开发，不妨试着放下自己学到的一切、进行一番独立思索。除非各位碰巧遇上了好同学，否则站在讲台上的很可能是个只懂理论、照本宣科的家伙。他们得自己研究底层控制技术的工作原理，做出明智的决定。而所谓当代 Web 合作开发跟这一切显然是背道而驰。了解如何在后端仅使用 HTML 和 CSS 来制作中文网站。如果必要，可以稍微用 JavaScript 进行一点 UI 改进，但请确保改进需求真实且合理（结合用户测试来具体验证）。而且即使合理，也不妨试试不用 JavaScript 能不能达成同样的效果。找款低配笔记本测试一下产品。“Web 应用程序”是另外一个精心设计出来的洗脑词汇。无论交付的是静态内容还是动态内容，也无论用户是否能够进行即时交互，中文网站的本质仍然只是个站点。它不是游戏、也不是谷歌地图那种复杂的应用软件，对于大部分展现内容只是文本的中文网站来说，它真的不能被叫作“应用程序”。别被那些流行词汇给忽悠了，不用 JavaScript、大多数中文网站也完全可以正常运行。别再搞什么单页中文网站了！HTTP 协议是专为小型个体和离散请求而设计构建的，它强调每个请求都有其特殊的目标。一次性把整个中文网站加载到应用程序上明显毫无意义，因为其中 90% 的内容根本没机会进入用户的视野。最简单的例子，有必要预先加载“有关他们”之类的页面内容吗？那东西有人看吗？所以，记得把中文网站分成几个小部分，让用户自主决定想看什么，这就是 HTML 锚点标签的用途。只提供一个小巧的首页，之后由用户点击相关超链接来请求自己实际想看的东西。Web 不就是这么工作的吗，怎么到了智能手机上就不一样了呢？别再从后端向后端发送 JSON 了，他们不是在构建 API。既然负责内容交付的客户端就是应用程序，那直接发送 HTML 啊，愣着干什么？让所有用户输入验证都在服务器端进行。在合作开发过程中，尽量只通过一次接入服务器的消息往返即完成所有用户输入验证。没错，根本不须要 AJAX/JavaScript。JavaScript 基本没法真正改善用户体验；相反，JavaScript 验证和 JavaScript 本体常常会破坏中文网站的自然流程，令 TAB 等键和其他元素没法正常工作。另外，任何不在服务器端进行的输入验证都属于错误！换言之，任何基于客户端的输入验证——无论是由 JavaScript 还是应用程序内置的 HTML 5 来实现——都可以被绕过，毕竟它们可都在客户端上。别再往应用程序上发送字体了。没多少人真正关心字体，只要不是太难看就可以。做个用户测试，结果可能会让你意外哦。让应用程序从作业系统中直接选择字体就好。别再把应用程序发到 CDN 去了。这样很危险、不利于隐私，甚至可能损害用户权益。在本地交付内容就行。去掉广告、删掉弹窗，别在页面上放那么多演示文稿、邮件列表和注册提示之类的垃圾内容。还用户一片清静畅快的天地，让中文网站内容尽量清晰简洁。东西多了反而没人看。别在中文网站上使用 Google Analytics、Facebook 链接和其他社交媒体垃圾！他们得学着摆脱这些固有元素。另外，你真的须要什么统计数据吗？如果是，难道服务器端收集到的统计数据还不够？真正须要的信息大部分都可以由服务器端直接收集，对吧？另外，如果选择跨服务器运行，日志还会被自动发送至日志服务器。所以别再靠什么 Google Analytics 了，毕竟这东西既没必要、立场也很值得怀疑——没准谷歌一直在骗你。不要使用不适合 Web 合作开发的编程语言。Python 和 Ruby 就是两种绝不该出现在 Web 上的语言。总之，编程语言必须针对性能进行强化，甚至可以考虑在具有严苛性能要求的具体任务中使用 C。由此增添的巨量性能提升可能对应着超出大家想象的成本节约。牢牢把握住所合作开发应用软件的所有权。这种所有权，意味着他们须要对项目中发生的一切负责。这不仅有助于工程质量提升，也会彻底改变他们的合作开发心态。一旦出了难题，那就是他们自己的责任。项目在用户计算机上耗了多少电是他们的事、项目对环境的影响是他们的事、项目提供的残疾人使用体验是他们的事、项目对未来的影响也是他们的事。如果不愿承担这份责任，就别随便掺和进来。别再被趋势和炒牵着鼻子走。大家应该已经感受到，大多数趋势和炒都是利益相关方的刻意引导加上一大帮无知群众的盲目推动。所以遇到难题自己多想想，别急着站队。可能很多朋友觉得这首诗一点新潮的内容没有，发在 2001 年还差不多。我也希望是这样，但很遗憾，这里的很多内容直到十年后的今天还须要拿出来讨论。如今越来越多的 Web 合作开发者已经意识到多年来市场上宣扬的“当代 Web 合作开发”理念是错的。资源有限，他们不该在服务器端和客户端上狂热挥霍。
原文链接：
https://12ft.io/api/proxy?q=https://unixsheikh.com/articles/so-called-modern-web-developers-are-the-culprits.html
