Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

喷一喷前端项目的自动依赖分析

  最初的 Web 开发中,所有依赖都是直接丢给 html 文件来管理的。比如一个项目使用了 jQuery,那么就在 html 文件中通过一个 SCRIPT 标签,把 jQuery 引进来。后来人们希望有一套自动管理组件的机制,比如当页面引入了一个依赖于 jQuery 的组件时自动把 jQuery 也加载进来。
  后者看起来显然更智能,但我一直都很排斥这种模式。为什么要关心谁依赖了谁?把所有需要的组件平行地加载进来不好么?
  其实最初人们希望自动管理组件依赖是因为多入口的需求。比如在同一个站点下有 A、B 两个完全独立的页面,如果手动去分别维护 A、B 页面的所有依赖会很麻烦而且容易出错。使用自动化工具分析 A 页面的依赖,自动为 A 页面加载所有所需的资源,而且不会把 B 页面的依赖也加载进来。这才是自动管理组件依赖对于前端工程的初衷。
  后来人们更倾向于一次性加载所有资源,并且对资源打包、压缩。也就是说,我们根本不需要关系页面内组件的依赖关系,只要关心最终都有哪些东西需要加载即可。那么自动管理组件依赖还有什么卵用么?当然,这个神奇的状态仅限于前端工程。对于后端项目,比如 nodejs 的依赖不存在为了节省请求数而合并文件的需求,所以每个组件自己管理自己的依赖是最好的。
  我觉得现在的一些前端开发模式变得很奇怪。从一个入口文件开始,分析代码中的 require、import 之类的东西,然后在递归地分析这些依赖。这完全是后端的开发模式,为什么要把这种模式生搬硬套给前端呢?下面是我对这种开发模式的两点不满:
  第一,入口文件无法直观地展示出整个项目到底加载了多少依赖。对于前端项目而言,代码量是一个与性能有关的重要指标,如果开发者都不知道自己的项目加载了多少东西,那不是很蠢么?
  第二,当使用某些依赖分析工具来打包项目时,无论是生产环境还是开发环境,总是在每次文件变化时候执行一次打包操作(Common JS 很难在浏览器上实现)。这个过程对于开发环境而言完全是多余的!直接通过 SCRIPT 标签在 html 中加载所有依赖的模式就不用那么纠结地去 watch 所有 js 文件的变化来不断地打包。
  我觉得一个完整的前端项目不应该基于自动依赖分析这样的工程化模式。注意这里强调的限定,如果开发一个前端的库,那么自动依赖分析确实是目前最佳的模式。
网名:
34.203.213.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^