关于下一代前端框架的一些我的想法

断断续续想了一个多星期, 想不下去了, 索性写成文章看看对别人是否有用吧.
中间有好多我不知道怎么解决的问题, 工具链不成熟, 特别是我的能力不够.
问题是, 下一代的前端框架的是怎样的, 我如何实现出来?
我原来在想 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 操做, 也就包含一些简单的逻辑,
理论上作个图形工具来对于其功能, 也不是多大的问题, 模板引擎自己并不难,
难的地方在于状态管理难以用图形工具完成, 最终仍是依赖代码编辑器,
而这样以后, 组件化和文件连接等方案面临重重困难. 一样也影响到后续的可靠性.
因此结果呢, 卡在这个地方不知道怎么办了. 暂时就想到这里.

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