一我的的 ClojureScript 技术栈

时间 2019-11-08

标签我的 clojurescript 技术繁體版

原文原文链接

做者：题叶
连接：https://zhuanlan.zhihu.com/p/24425284
来源：知乎
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

今天(昨天)分享完关于 ClojureScript 的话题, 算是如实重负. 我嗓子很差, 以前分享过 React, 但相比在网上老是差不少, 此次分享也是紧张, 会场的 Keynote 没有按照预想放在挺高的地方, 也没有下一页的预览, 看着大屏幕衔接没作好. 可是说真的内心仍是忐忑的, 提问的同窗很犀利, 几个都在点子上, 关于 Redux 还有深度传递的属性, 以及全局 state 问题, 其实我并无想清楚, 我有本身的方案, 但并无足够说服别人的方案.

实际上个人角色是转述国外社区的方案, 而后加上我本身的理解来强化对于技术的解释. 通过一层转述毕竟是很差的. 提问当中相关的问题, 其实 David Nolen 都提出过方案, 全局 state 和相似 GraphQL 的问题. 我没吃透却是真的. 有机会仍是建议去 Youtube 上刷一遍大会上关于 ClojureScript 的视频.前端

我有信心笃定函数式编程是对的, 首先国外已经有人实践了, 其次我本身使用下来感受可靠. 主流前端不看 Clojure 大会的视频, 其实不多有渠道报道可以获知报道的. 我由于当初挖 React 和 Haskell 的缘由专门去看了, 因此我知道. 显然国外也不是稀罕事. 可是在中文技术社区就不多这方面的声音, 更不用说闲着蛋疼去写 ClojureScript 代码了. 但我须要. 我以前推广 React 结果面对那么多期待以外的复杂度, 我亟需一个解释, 我须要找到本身的支点和方向. 维护和平, 防止本身世界观崩溃.git

个人世界观确实蛮脆弱的, 跟不少从小镇进入大城市上学工做的人同样, 整个过程就是世界观瓦解和重建的过程. 到了编程也差很少, 从最开始 CSS, 到会写代码, 到发现编程范式, 到挖函数式编程的历史, 我花费了好大的力气避免本身崩溃. 我应该是很少的身为 JavaScript 程序员, 却长时间混迹 Clojure, Haskell, Elixir 圈子的人. 按照个人判断, 这三门语言将来会愈来愈重要, 至于会不会进语言榜前十, 我并不在意, 影响力是方方面面的, 好比 Haskell 的研究看似漫无边际, 实际上已经影响到 C# Swift CoffeeScript 等等语言的设计了.程序员

知乎上关于 D2 有同窗提到我很孤单, 其实我一想一想这这么以为. 虽然未必是正确的方向, 可是我真的走了好远好远, 真的有孤单的感受. 平时我遇到 Clojure 问题要去英文社区问 ClojureScript 的维护者们, 这还正常, 可是我用的 Stack Editor 全世界恐怕只有我一我的在用, 而后维护者说你的东西好奇怪, 跟咱们日常的都不同因此帮不了你... 就这样我被一门小众语言的开发者吐槽说个人东西很罕见... 除了 Stack Editor, Respo 的状况也相似, Respo 的功能覆盖不全面, 固然别人是不乐意用到生产环境的. 虽然有几个特性很新奇, 但结果仍是我一我的用.github

我还在 GitHub 上一我的创建团队维护的个人项目, 开几十个仓库, 结果就是我一我的龟速堆代码. Respo, Cumulo, Cirru 是其中最严重的几个. 固然介绍已经很多了. 我对本身的定位原本不是前端, 但这些年在后端和设计方向上我能够说进展微渺, 已经没了信心, 就算说年轻, 光是编程上的坑就能拖着我很久了. 看整个的历史, 好像也应该是这样的, 你们都看到了前面的曙光, 可是走在前面的人会先填了近的坑, 结果累了慢下来, 新人就赶超到前面去了. 我如今作一些乱七八糟的东西, 后面会有不少不少人作比我牛逼不少的事情, 而本来我期待出那种风头的是我.算法

Lisp 在国内缺少声音, 有名气的大概田春的 Common Lisp, 王垠的 Scheme, 其余的不多在社区看到. Clojure 社区咱们固然还有 Lo 姐, 但人家明明在英国过日子. 至于群里其余朋友, 前端圈应该不多听到了. 可是 Lisp 很重要, 宋鸿兵说过, 看一个国家的如今和未来, 就要看他的历史, 原话固然是记不许确了, 我想说对于编程而言, 一样有历史的因素. 面向对象半个世纪, 函数式编程半个世纪, 若是只是面对 JavaScript 这几年的新闻, 实在是窄了一点. JavaScript 也许是迄今发展最迅猛的一个生态, 真是蛮夸张的. 然而面对真实世界的问题, 最终仍是须要寻求依靠, 编程理论和工程经验是知识的重要源头, 也就是半个多世纪计算机理论和工程方面的研究.编程

Clojure 好在哪? 我最在乎的一点是 Clojure 当中的各类功能都是通过深思熟虑肯定的, 我是指语言自己的核心部分, 语言坚持哪些特性, 哪些会作折中, 都作了至关的考虑. 固然这并不意味着 Clojure 没有问题, 可是对比静态类型语言编码的成本和严格, 对比脚本语言的散漫, Clojure 在其中维持了挺微妙的一个状态. 相似的语言固然也还有, 可是在前端使用领域来讲 ClojureScript 是除了 JavaScript 以外生态相对完整的一门语言. TypeScript 因为是静态类型, 因此不拿来对比. 同时 Clojure 也在函数式编程和操做反作用之间努力寻找平衡, 既要借助函数式编程提高程序的可靠性, 又要考虑实际操做状态时如何处理.后端

我微博上发过, 我以为 JavaScript 社区其实归根究竟是大厂博弈的过程. 本来的大厂的竞争, 苹果有 Objective-C 和 Swift 等等, 微软有 .Net 平台大量的编程语言, 微软是开放的, 虽然苹果借助 iOS 再次反超. 但 Mozilla 和 Google 做为后来者在新的领域发起战争, 特别是 Chrome, 点燃了 JavaScript 引擎性能的竞赛, 以及一连串的 Web 平台的战略. Facebook 也想在 HTML5 上寻找突破, 虽说是失败了, 可是以 React, Webpack, Babel 目前在社区的影响力, 简直是开辟了新战场. 用户固然是一个方面, 可是谁吸引和控制了开发者, 谁的话语权依然会很大. 而 TypeScript, Dart, Babel 对开发者的争夺, Angular, React 对开发者的争夺, 某种程度能够认为竞争不会消弭.浏览器

两相对比, 特殊之处, 以前苹果微软能够在语言和操做系统层次进行竞争, 而如今因为 JavaScript 的特殊性, 战场很是狭小, 简直要出现肉搏. ECMAScript 须要有统一标准, 可是不一样的厂商会有不一样的技术点的利益的诉求. D2 期间也听鬼道解释了一遍, React Native 长时间不接受他们某个特性加强的改进的代码, 可能因为涉及较深刻的修改. 但公司利益是公司利益. 当 Google 或者微软强行在自家浏览器增长各类神奇功能时, 也是面临这样的尴尬. Facebook 把编译搞得如此复杂, 由于你们都以为 JavaScript 是语言, 要按照标准作, 分开 stage 功能, 各类配置项. 而后社区当中也是各类风格相互冲击, 套路能很少么.缓存

因此固然我看到 WebAssembly 前两次更新三家大厂一块儿更新博客的时候, 我简直眼镜都要掉下来了. 态度如此一致! 我估计他们是真的想好后招了. 像是 Clojure 那样, 一个公司控制好语言的核心, 按照特定的习惯设计好工具链, 花点时间打磨一下开发体验, 把 VS 的成功经验迁移过来, 难道很差么. WebAssembly 不只仅提升性能, 同时做为汇编, 也让从 CoffeeScript 2009 开始发出的声音, 终于看到了一个清晰的出路, Web 就是须要一门新的汇编, 而不是单单 JavaScript. 以后你们能够各自创建起自家完善的工具链, 稳定的语法和语言特性, 类型推断类型检查, IDE 和各类生成工具, 提供平台 API 等等. 美好的将来.mvc

固然我是心急了. 加上年初有三个月无业游民的时间, 除了总结下 Respo, Quamolit, Cumulo, Cirru 几个项目的思考, 我大把的时间都用在熟悉 ClojureScript 的思惟方式上, 到入职个人 JavaScript 封装仍是原地踏步的状态, 反正公司直接 ESlint. 因而我用 ClojureScript 搭建了整套我在 React Webpack 当初折腾的热替换开发环境除出来, 包含纯粹 ClojureScript 实现的 React 主题功能也就是 Respo, 还有编码方式从 Sublime Text 迁移到了 Cirru Light Editor, 到下半年把 Light Editor 升级成了 Stack Editor, 而这已是别人彻底不熟悉的一套工具链了.

文章标题讲的就是个人技术栈, 后面的篇幅就粗略介绍一下:

Respo

主页 http://respo.site/
GitHub 团队 Respo

我用 ClojureScript 实现的 Virtual DOM 方案. 总体采用 pure render 因此对反作用也就是自定义组件等需求支持有欠缺, 可是在 Virtual DOM 操做和热替换方面舒服不少, DSL 略啰嗦但我以为还算顺手. 性能上我作了很多优化, 整体会比 React 之类框架慢几倍, 大概应该在一个数量级上. 文档方面我整理了 API 和术语的解释, 也编写了纯 ClojureScript 的 examples, 能够在 GitHub 页面找到. 其余 UI 和 router 等经常使用组件由于用到, 也就依照个人 React 经验堆了一些出来, 固然体量是过小了.

Stack Editor

主页 https://github.com/Cirru/stack-editor

其实就是 Cirru 的项目的 Clojure 形态, 在 DOM 上编辑 AST, 后端生成 Clojure 代码. 因为是图形界面的编辑器, 我能够经过前端代码实现简单的跳转到定义, 自动生成变量. Stack Editor 最重要的一个想法是, 侧边栏应该显示函数名或者变量, 并且是根据调用栈显示, 从而方便具体功能的开发. 从实际使用效果看确实比 Sublime Text 手写来得快. 我在微博上常发视频, 有兴趣能够看.

Stack Workflow

项目 https://github.com/mvc-works/stack-workflow

因为 Respo 和 Stack Editor 带来了模板代码, 因此我须要一个项目做为模板项目, 也就是实际意图了. 经过模板代码, 个人开发习惯实际上稳定了下来, 而且能增量得改进. 实际上在这个 workflow 当中项目源码是用 .ir 文件存储的, src 当中的 cljs 代码都是编译出来的. 我想这应该已经超乎不少人想象了.

Cumulo Workflow

项目 https://github.com/Cumulo/cumulo-workflow
核心优化算法 https://github.com/Cumulo/recollect

Cumulo 项目关系到在分享里讲的服务端到前端的数据同步, 最粗暴的办法就是直接用 Diff 了, 固然我不是彻底没优化的那种 Diff, 仍是有基于纯函数和缓存的优化的. 这样我就把 Respo 的 Store 直接搬到了服务端编写. 固然这相对来讲仍是项目很是早期的一个状态, 性能远远不够. 可是搭配 ClojureScript 的服务端热替换功能, 开发仍是蛮顺畅的, 以前我用 Webpack 服务端热替换作到了改修代码 WebSocket 不断开, 而在 ClojureScript 环境当中更简单.

除此以外的小工具还有一些, 但都不如上面几个重要了. 我知道对于别人来讲这些项目会是奇葩, 可是对于我来讲这是一个不错的开始.