前端根本不需要构建！“技术邪教”RubyonRails之父再

　　在近日的RailsWorld大会上，RubyonRails之父、37signals联合创始人兼首席技术官DHH（DavidHeinemeierHansson）发表了观点称，最快的打包工具就是没有构建（NoBuild），有了HTTP2以及浏览器原生支持ESModules，前端根本不需要构建。
　　“复杂性已经堆叠得太高了”
　　“我们正在构建一切，一切的一切。”DHH说道。目前，市面上正不断涌现种种令人兴奋的新框架和新库。“新生的事物太多了，可能我们必须得依靠AI提供的建议才能想明白该怎么应对。”
　　DHH认为，人们似乎获得了越来越多能够创建出略好一点新版本的工具，但投入却一路飙升。这不是正确的方向、也不是理想的发展状态。
　　DHH以自己当时开发RubyonRails的经历为例称，团队最初的立项是BaseCamp框架，前后花了约六个月时间，成员只有一位开发者加两名兼职设计师。最终BaseCamp建立起出色的业务，多年间创造了数亿美元的收入。“既然我们在2003、2004年那会儿就能做到，那么2023年我们理应做得更多。”
　　对于企业需要用很长的时间才能做出一点改进的原因，DHH认为其中重要一点是，在生产力低下的时代，取得早期成功的那些企业定下了标准，其他人即使意识到自己需要一点不同的东西，也很难做出实质性的变革：要么效果没有大厂同类方案好，要么就是不具备同样的可扩展性。
　　“根据一位Twitter前员工的说法，他们决定脱离Rails是因为之前的架构设计不好，于是他们决定转向当时认为更好的Java微服务这边。但很长一段时间过去，工作并没有什么进展。他们完成了立项，又雇用了好几千人，但毫无进展。Twitter的例子基本就是生产力黑暗时代的常态，人们认为工作在推进，但增量收益却极其有限。顺带一提，Airbnb那边也有类似的情况，这已经成了一种趋势。JavaScript框架造成的类似问题还有很多，甚至开始拖累整个行业的发展速度。”DHH以Twitter为例论述道。
　　DHH还提到，过去10年到15年间，技术栈分化问题也给开发人员带来了困扰。架构师想要解决的只是他们认为能解决的问题，但未必是真正重要的问题。所以大家需要关注的是能做到哪些以往做不到的事，而每个人都应该努力成为全栈开发者。
　　总而言之，DHH认为，过去10到15年间复杂性已经堆叠得太高了，现在是时候把简单性作为新的目标了。
　　如何实现“无构建”
　　就前端领域而言，某种程度上讲，它已经走进了一种“死循环”虽然它也获得了一定实质性的进展，改变了如今开发Web应用程序的基本预期，但紧跟潮流正变得越来越困难。
　　对于前端的简化，DHH提出了“没有构建”的理念。“只要存在构建，那就只能提速。如果根本没有构建，那速度不就到头了？”
　　“最先进的（打包）技术不再是寻找更复杂的方法来构建JavaScript或CSS，因为前端根本不需要构建。现在可以依靠HTTP2和对importmap的普遍支持来避免打包。”DHH介绍称。
　　importmap直译过来是“导入映射”，可以让开发者直接在页面上管理模块，而不需要通过打包构建。“importmap堪称是Rail7中的一次大冒险。”DHH表示，配合HTTP2一道，importmap就构成了一条加载瀑布流，通过一系列独立的脚本让所有的内容都能同时加载，而不必再将JS拆分成一个个包。开发者可以更轻松、更顺畅地使用esBuild，甚至不再需Bun的协助。
　　“NoBuild”还具备其他一些奇妙的功能，例如用户可以在任何网站上直接查看源，其内容不涉及任何源映射、不需要任何捆绑，它们就是开发出所编写的文件，未必是编译的纯JS文件。一切都能直接交付、不需要经过构建，直接在浏览器端呈现。
　　对于Gamil那种极为复杂且充满交互的产品，DHH认为，HAML可以解决。“HAML为此而生，我们可以借此编写出纯JS代码而且无需任何构建。这让我非常兴奋，也是我们目前的主要开发方式。”
　　没有构建的理念正在迅速普及，如今也已经进入了CSS，并推出了大受欢迎的CSS嵌套功能。现在所有浏览器都支持CSS编译，所有浏览器都支持自定义属性即变量。
　　DHH透露，现在37Signals的新应用开发中也在运用这两大功能：无需构建JS代码和无需构建CSS。“之前我们就考虑过使用嵌套和变量来回避构建。事实证明没有构建不仅是可能的，而且具有极其重大的意义，我们耗费了约十年时间才破解这种复杂性。”
　　DHH表示，绝大多数静态站点不需要花哨的构建管道。ServerSideIncludes（SSI）被严重低估了。他提出可以将一个Jekyll站点转换为SSI。“一旦将静态站点转换为SSI，我就会将这些简化为一个新工具，让它们变得简单。拥有一种巧妙的石器时代技术，可在5秒内自动推送更新。只需为其提供一个小型虚拟机即可，每月花费应该不会超过5美元。”
　　DHH还表示，这一年半以来，37Signals开始转向propshaft，这个新库用于在Rails侧无需编译的前提下提供资产管道。它的基本功能只有两个：为所有资产提供加载路径，以便在任意视图中访问任意位置上的gem及其他资产；提供摘要标记，从而确保拥有良好的远期动态缓存。
　　在推特上，DHH还展示了公司主站的性能表现，他表示HEY主要应用运行的JavaScript代码没有经过构建。“我认为我们在NoBuild、importmap和大约100个单独的JS文件方面做得很好！我们发送500kb的未压缩JS，而Gmail则发送10mb！”
　　“在es6以及JS世界中一系列基础进展的支持下，如今的前端代码已经做好了跨越复杂性之桥的准备。我知道，现在的方案仍然有点复杂，但从结果上看所有付出都绝对物有所值。”DHH表示，“我们目前最应该做的是：在现代Web应用程序的构建过程中，剔除一切形式的JS捆绑或转译。当然，这样的未来是等不来的，我们应该从现在开始转换自己的开发思路。”
　　真有用还是噱头而已？
　　对于DHH提出的“NoBuild”理念，VercelCTOMalteUbl在推特上表示，他们已尝试过，但结果是行不通。因为在HTTP2中，每个请求的开销仍然非常大，并且存在并发限制，此外还会出现瀑布流和低效压缩。目前，“打包”对于高性能网站来说是无法绕过的。
　　DHH不认可MalteUbl所说的“行不通”。他表示，这就是技术讨论的奇怪之处。即便已经有案例证明项目能完成大规模任务（如Rails之于Shopify），但人们也会声称它不能进行扩展。或者已顺利使用某种方法多年（如nobuildJS之于HEY网站），也会有人说这套“行不通”。
　　还有人觉得这个只是噱头。推特网友“Viking”表示，自从移除TypeScript后，DHH越来越激进了。甚至有网友称DHH散发出令人不安的“邪教领袖”气息。
　　开发者Nander表示，“构建时间并不重要，重要的是FCP（FirstContentfulPaint，从开始加载到页面内容的任意部分在屏幕上渲染出来的时间）。导入映射时间并不比位于同一服务器上的RSC（构建步骤）和最小化捆绑包（构建步骤）快。”
　　“Chrome删除了HTTP2的多路复用，它并不比捆绑更有效率。HTTP3已经解决了这个问题，并且可能证明捆绑已经成为过去。但据我所知，还没有人尝试过HTTP3多路复用esm服务器。Node、Deno和Bun甚至还没有支持HTTP3。”JoePea说道。
　　还有开发者指出，不打包把开发细节暴露给用户，浏览器原生支持不等于高效。build是快了，但运行时慢了的话还划算吗？前端工程化的一个重要里程碑就是引入了build步骤，让开发体验和用户体验分离，特别是几百个不同版本的、不同浏览器的用户体验完全分离，这才让开发者真正解放了。
　　有开发者很喜欢这个主意。Rails开发者NiklasHusele表示，“我喜欢用‘NoBuild’的方式进行本地开发。无需等待即可刷新，这就是最高的生产力。我甚至删除了tailwindcssrails并将其替换为tailwindCDN，以避免必须在本地运行任何内容。对于tailwindcssrailsgem来说，这将是一个有趣的默认值。”
　　对于DHH“没有构建”的理念，你有什么看法？欢迎在评论区留下你的想法。
　　参考链接：
　　https：www。youtube。comwatch？viqXjGiQDA
　　https：twitter。comdhhstatus1713615147393323408
　　https：twitter。comcramforcestatus1712265070213050390
　　https：twitter。comcramforcestatus1712265070213050390
　　https：world。hey。comdhhyoucantgetfasterthannobuild7a44131c
　　本文转载来源：
　　https：www。infoq。cnarticle9k37mArAJlY708eGOkVP