所谓“现代Web开发”，都是些什么妖魔鬼怪？

以下内容来自公众号逆锋起笔，关注每日干货及时送达

编译 | 核子可乐、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 能不能达成同样的效果。

• 找款低配笔记本测试一下产品。微信搜索readdot，关注后回复视频教程获取23种精品资料

• “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

逆锋起笔专注于程序员圈子，你不但可以学习到java、python等主流技术干货和N多个源码分享，还可以第一时间获悉最新技术动态、内测资格、BAT大佬的经验、精品视频教程、副业赚钱经验，微信搜索readdot关注！

最佳 Web 编程语言都有哪些？

五分钟了解互联网 Web 技术发展史

将一个纯本地应用移植到 Web 端

一些著名的软件都用什么语言编写的？

为什么我会放弃 Webpack 而选择 Vite