如何形成自己的前端思想体系

79 阅读4分钟

有一天, 你对框架很无感. 对 css 预处理也无感时, 而是更关心JS和浏览器本身. 你就已经从一个Vue工程师升级成为前端工程师.

有一天, 当你能很好的使用Ts的类型约束、lint、单元测试去帮你管理你的代码质量时, 你快有了自己的思想体系.

有一天,当你聚焦在如何组织你的代码、时刻注意分离副作用, 在思考如何更好的跨项目复用/更新你的代码的时候, 你快有了自己的思想体系.

有一天, 你把你过往大部分的迭代过程总结出几板斧时, 你快有了自己的思想体系.

有一天, 你能正确的看明白前端在产品中的分工和产生的价值边界时, 你对前端又会有了更上层的理解.

这些都加在一起, 你对前端的了解就上升得到了另一个高度, 并且明白有的东西无法言简意赅的言传. 你以为你已经掌握了较为完整的前端思想体系.

现在回答一下你 leader 说计算机为什么会衍生那么多语言.

上面都清楚之后, 你以为自己已经很了解前端了, 已经是一个新晋的前端小牛, 你感觉自己用什么语言都都可以很好的编写前端代码. 于是你尝试使用其他语言去编写前端.

你首先选择的是 Go, 因为它语法简单, 并且支持WASM, 你用你精湛的BOM和DOM的API理解, 使用 Go 开始编写界面, 你很快就完成了一个Todo List,同时你发现三个问题:

  • 你的Go代码有Runtime, 大概有1.3MB, 同时你哪怕使用了一个go的字符串format, 这个体积还会持续上涨, 你按照正常的理解去用go的标准库里的方法, 你的Wasm文件就已经涨到了近10MB, 你此时对前端技术已经非常吹毛求疵了, 你无法接受这种尴尬的局面, 你想到了 Rust 的 WASM没有 Runtime. 于此同时, 你觉得JS是浏览器内置的语言, 就是好啊.
  • 你的Go代码描述前端的标签, 都是以一个大对象的方式, 和 React的 CreateElement 类似, 不管你如何优化这个绘制界面的API, 它都没有JSX阅读体验好. 你慢慢明白了为什么会有 React 和 Vue, 原来它们是利用类似HTML的描述方式又不失图灵完备的方式让你更好的描述和更新你的界面. 你想到了Rust有宏, 可以自定义类似JSX的描述方式.
  • 你的Go代码有着非常好的类型约束, 但是你发现前端的类型场景非常复杂, 虽然Go已经有了范型, 但是比起Ts这种可以做类型编程的神奇语言, 很多情况还是无法实现, 你无奈的使用了你的Ctrl+C/V大法. 这时你才知道, 原来虽然大家都可以类型约束, 但是 Ts 在约束了你的同时, 还给了你自由.

你知道此时回到JS的怀抱是最好的选择, 但是你不甘心, 你多年摸爬滚打的前端知识让你坚信自己使用其他语言也能完成这个工作. 你又选择了Rust, 你同样遇到了三个问题:

  • 虽然Rust的WASM几乎没有Runtime, 并且有好心人提前把BOM里的方法映射到了Rust中, 此时你心里稍安. 但是你的代码会随着你工程增长, 而Rust无法Split并且懒加载代码块, 也就是说你未来很快还会遇到首屏加载缓慢的问题. 这时候你非常怀念前端这种可以动态加载的脚本语言, 用户只需要下载他当前用到的代码不香么?
  • 你发现Rust这种语言因为没有GC, 所以即便你绑定一个很简单 onClick 事件, 当事件闭包需要捕获state时, 你都可能涉及 UnSafe 语法或者使用 RefCell+Rc 这种需要自己确保安全性的智能指针, 你知道你的前端页面的性能瓶颈远远没到拼GC开销的程度,你怀念你的JS的GC和包容性.
  • 你有一个异步的行为, 你发现在Rust里需要使用Tokio等方案, 它和JS的Promise非常相似, 你不经感慨, JS原来这么好.

你慢慢理解了为什么计算机这么多语言, 最后是一个动态脚本获得了浏览器的天下. 你释然了, 也知道什么情况下使用什么语言. 遇到语言之争的时候, 你笑着说了一句: Php 是世界上最好的语言.

最后点题:

所谓思想体系, 都是你去不断拓宽边界, 尝试过才能慢慢形成。