断断续续想了一个多星期, 想不下去了, 索性写成文章看看对别人是否有用吧.

中间有好多我不知道怎么解决的问题, 工具链不成熟, 特别是个人能力不够.问题是, 下一代的前端框架的是怎样的, 我如何实现出来?我原来在想 Facebook 搞 ReasonML 了, 新语言很重要, 那么我应该努力学,然而仔细想想, 问题没那么直接, 我们真的需要那么强大的语言吗?Haskell 甚至 Idris 已经把问题研究到那样的强大了, 可是对于前端用得着吗?

需要解决的问题

翻看公司局部的业务代码, 我注意到逻辑代码的比例很小, 需要类型验证的并没有那么多,

一个页面当中大部分的代码实际上是 CSS, 样式代码, 样式的细节很多,而且由于 CSS 天性上抽象能力不够, 加上业务确实有大量的不同, 细节很多,结果我们有很多手写的样式. 然后是的 HTML 部分, 或者说是 DOM 的描述,相对而言, 定义组件状态, 访问请求, 同步数据到组件状态, 花费的代码很小,而且 UI 需要调试, 从设计稿到最终网站上线存在不小的重复工作.

抛开前端代码, 当你想要做个简单的手机页面, 首先需要的是设计,

先用设计规范好页面每个细节, 然后增加交互的能力. 最后提交给用户.或者说就像是做一个海报, 打印很多份然后贴出去, 没有大的区别,而现在的问题是有交互, 直接打印是不够的, 就需要人力一点点堆出来了,人力嘛, 毕竟远远比不上机器来的可靠和高效. 但是现在毕竟机器做不到.

极端理想的网站上线流程, 也就是去掉所有重复的机械工作, 只留下需要人做的部分才投入人力,

需要人力的有:

• 定义需求

• 优化视觉(某种程度上未来人工智能也可以完成一部分)

• 增加基本一些交互

• 增加复杂的交互

• 验证网站的可用性(部分 UI 测试可以由测试方案完成)

设计师完成了界面, 然后再程序员用代码写一遍, 这是最明显的重复劳动.

所以自然目标就是用软件生成界面, 也就是类比之前问题到的 Lottie,用交互软件制作好动画, 导出 JSON 文件, 然后在平台上用代码重现出来,某种意义上网页上我们需要的也是如此, 用一个软件去编辑出来,然后导出 JSON, 最后页面上根据 JSON 直接生成网站. 界面做好就好了.

难点: UI 能力有限

这个思路大家都知道, 但顺着这条路想下去, 难点也会很明确,

总有不能用图形直接描述的部分. UI 很容易, 但涉及到逻辑怎么办?编程当中的问题往往是用数据类型和操作模拟问题本身, 然后用计算解决,也就是说用来模拟的方案必定包含和问题本身那么大的复杂度.所以那些包含了复杂逻辑代码, 用 UI 表示出来依然会一样地复杂,真正用了 UI 而简化, 只是原本抽象不方便调试的 UI 部分.

明确这一点之后, 那些网络相关的逻辑代码, 或者状态相关代码, 比如剥离,

或者说跟状态和操作相关的功能, 不应该用界面去生成, 还是要手写,那么混杂在 HTML 当中的逻辑了, 比如 if, each 这之类的?当然还有的 filter 之类的, 说起来可能比较含混, 但是跟 MVVM 多少可以对应.MVVM 当中大量概念都抽象到类似 HTML 的语法上去了, 貌似很简单.在内部, 相当于重新定义了功能. 和 React 那样严谨的方案有很大差别.

顺着想下去, HTML 当中逻辑少不了, 那么结果面对的是类似模板引擎的写法,

或者说类似 Vue 的 template 部分的写法, 这是适合用图形界面来表示的.同时样式部分自然而然很容易对应到图形编辑的属性操作工具上去.最终剩下的就是 data, computed, method, filter 这些概念的逻辑定义.由于 UI 表达能力有限, 那些逻辑最终还是代码的形式去表述更为合适.

所以在这个阶段面对的问题就是如何, 这个 template 用界面去编辑,

用图形界面的方式来编辑图形界面, 显然是设计师惯用的解决方案,在此之外, 我们要引入屏幕尺寸和 Store 相关的代码, 以便工具能够被使用,也就是说, 即便是生成的, 它最终得到的就是前端制作的网页的渲染效果,能够响应屏幕的尺寸, 能够根据 Store 内容不同渲染不同页面,也就是用图形工具来编辑模板引擎, 最终生成代码可用的模板引擎及其样式.

难点: 如何组件化链接 UI 和代码

思考到模板引擎这一步, 可以认为用图形工具是可以替代模板引擎的功能了,

但是对于真实的程序来说, 特别是面对状态管理, 当然是不够的,比如说子组件的菜单选择后, 修改父组件状态, 从而实现菜单选择的功能,这里就会遇到状态管理, 而且在实际应用当中难以避免, 甚至会有更复杂的场景,我们可以做到的复杂组件由开发人员制作, 然后用图形工具使用, 但状态管理少不了,特别是还会存在表单和页面组合使用的情况. 表单当中的状态更不会少.

除了之间内部的状态, 另一部分是全局状态. 也就是需要 dispatch action.

其实处理 dispatch 相对较容易, 因为 action 已经很好地进行了解耦,解耦之后代码可以独立出来开发, UI 部分和 reducer 或者说 updater 是分开的,这里的问题主要在于如何模块化. UI 部分是一起开发的, 逻辑又是在一起开发的.注意我并不是想在图形工具当中强行写代码, 那么弊大于利,写逻辑代码还是应该用文本编辑器, 目前没有特别合适的其他选择.而这样代码和逻辑实际上的是分开的, 需要想办法分析出来, 进行模块化.

所以某种程度上我们需要很强大的编译器, 来分析代码的, 处理模块之间的关系.

我理想化的目标是界面需求用图形工具完成, 大致对应设计或者产品的角色,然后由比如 API 开发人员来绑定 API 等操作, 相当于服务器开发人员,然后中间依靠强大的编译方案, 保证两方的合作能够衔接到一起.同时, 方案需要组件化, 因为有些组件必然靠跨越业务共用的, 否则也损害到效率.这样推演下来, 强行脱离代码首先导致了组件化方案不能灵活使用的问题.

难点: 调试

不方便调试这个问题应该比较好理解了, 设计的方面太多, 定位问题也就更难.

Vue 出现过这样的问题, 由于设计了很多 DSL 需要自行解析, 细节很繁琐,相对而言, 纯粹代码的描述的 React 可以直接借助 js debugger 定位问题,如果为了实现图形化工具引入更多的抽象层级, 调试势必会成为大麻烦,我们可以想办法说打印更多规范化的 log, 增加自己实现的 validation 之类的,但是调试的麻烦对于效率的伤害还是很不小的. 肯定不会轻松了.

结尾

整个方案核心的想法是用图形工具来修改一个模板引擎之类的 DSL,

这个 DSL 可以被用在生成 HTML 和更新 DOM 操作, 也就包含一些简单的逻辑,理论上做个图形工具来对于其功能, 也不是多大的问题, 模板引擎本身并不难,难的地方在于状态管理难以用图形工具完成, 最终还是依赖代码编辑器,而这样之后, 组件化和文件链接等方案面临重重困难. 同样也影响到后续的可靠性.所以结果呢, 卡在这个地方不知道怎么办了. 暂时就想到这里.

为什么说是"下一代前端框架"呢? 比前端这一代好在哪里? 为什么好了一代?

...当然这个东西造不出来的话连可比性都没有, 现在不就没造出来么.只是从推演上说, 前端要解决的问题主要就是网页的开发效率,从早先的服务器渲染, 到前端模板渲染, 到声明式渲染, 到同构渲染,这一路走下来改变了很多. 重点就是在开发速度使用体验上交替改进.而微调界面一直都是前端开发当中的麻烦事, 而且阻碍了设计师独自发网页.我认为, 如果能用图形工具直接生成出来, 对前端开发来说是有巨大的跨越的.届时设计师/前端/后端之间的分工也将会发生一些变化. 有点意思.