前言
新一代大前端利器 iofod 开放公测！应用开发领域的 Photoshop，专门为攻城师们打造的低代码开发平台，应用开发毫不费力。本文将从多个方面切入快速介绍 iofod 独特的地方，同时分享设计上的思考，希望能抛砖引玉。正文开始前先通过一段小视频感受下 iofod。
视频
布局系统
人类以自身为量尺，为万物规定了尺度，类似地，一个应用被我们分解成一个个场景（屏幕，窗口，页面），下文我们统一称之为页面。
我们把范围锁定在当前的主流媒介：屏幕。一个页面承载了当前屏幕肉眼可见的一切对象，为了更好地管理这些对象，我们发明了视图，树，层，容器等概念，按空间位置，属性给对象分类，划分范畴，在日常中我们不会直接去操作屏幕的像素，甚至使用类似操作画布的绘图原语的情况也少之又少，更多是使用更高的抽象（组件，控件等）来描述页面的内容，这更贴合人脑认知。
iofod 对大量的场景和用户界面进行分析，设计了跨平台兼容的布局系统，为布局容器提供了绝对，相对和弹性布局三板斧，结合对页面的分层管理，理论上所有的界面视图，均可以转化为这一布局系统的表达，同时具备良好的维护性，一图胜千言：
原子组件
还记得 jQuery 年代，市面上DIV+CSS一把梭到底的产品比比皆是，如今2022，iofod 用可视化这时髦的方式将其重新包装并推到舞台上（手动狗头）。根据前文所述的分层理念，层级内的容器可以再次嵌套容器，构成子布局，布局完成后，往容器内填充原子组件或者封装的组件，完成真正的界面内容，这种以层级结构来组织管理界面的方式与传统并无不同。思路虽一致，然而实现路径可谓千差万别，iofod 结合通用布局系统的三板斧，在不限制界面表现的前提下对实现方式进行剪枝，将用户的可能实现路径数压缩到可数的范围。
可以说原子组件和容器可嵌套保证了封装复杂组件以及实现任意视觉界面的可能性，抹平了界面维度与传统编程的能力差，配合有限的声明式状态表达式，实现路径甚至成为了无关要素。
JS in CSS
前端 Web 领域的 CSS 对比其他领域的CSS，其表达形式无疑是最为自由的，自由带来强大的同时，也带来了稳定性和性能问题。浏览器用大部分代码来支撑其自由度，技术团队制定规范来限制成员编写维护性或性能差的代码，许多跨平台框架通过阉割实现 CSS 子集以获取更快的渲染速度，业内出现预处理器、后处理器来弥补稳定性，模块化CSS，CSS in JS...这一切无疑在宣告 CSS 存在极大的改进空间。iofod 对此的解决方案是：摒弃命令式修改，用更纯粹的函数式与声明式来兼顾自由与稳定。
用户与界面交互，会产生指针或触控点的输入流，输入流作用于可交互的组件上如按钮，按钮接收输入流，切换自身状态为被点按的状态来响应用户反馈，此时可能还需要根据实际业务去请求后台数据，获取新的输入流，更改页面几个组件的模型数据，按钮可能要变更自身的内部状态，切换为不可点击状态...一个再平常不过的场景，命令式可以很容易翻译出有味道的代码，读者请自行尝试。在 iofod 里，按钮用一个文本组件表达，配置 disabled 分别表示按钮点按和禁用状态，配置交互点击修改变量值，根据需要新增交互步骤，这案例很直接表现声明式 UI 以及 JS in CSS 的优点。
基于该设计，我们获得优良稳定性的同时，也获得动态 CSS 的能力，表达甚至更加灵活。我们通过一个轮播效果演示下进阶的用法：
案例具体细节可参考这里
跨平台
跨平台开发的需求一直存在，不考虑性能与原生能力，Web 是目前最为强大的跨端跨平台的解决方案，并且对比原生其开发的简易程度和速度也是最高的，但开发体验终归是要让步于更好的用户体验，业界早已进行过大量探索和实践，从Cordova，React Native 再到如今的 Flutter，我们跨平台的方案更加成熟且用户体验更上一层。
在 iofod 搭建的项目，我们的目标是实现导出各个平台的代码，目前 Web & H5 支持导出 Vue2，Vue3 代码，小程序方面支持导出 Taro 代码，借助 Taro 生成国内各小程序平台应用代码，原生应用方面支持导出 Flutter 代码，借助 Flutter 生成安卓，iOS和桌面端应用代码。
极致的复用
每个技术团队对 DRY 原则的理解与实现存在差异，有类似于行政单位的划分，将代码的复用分级成片段，函数，模块，类库，框架，进行分层治理，也有观察代码在时域的变化，分离代码变化的部分与固定的部分，对固定的部分进行封装复用。我们对已有的方案综合自身情况进行考量，权衡利弊之下得出最合适的价码，两种方案中，前者对变化的判定标准很低，随时间累加会产生大量低保值的复用，甚至由于变化太快，封装完成之日就是入土为安之时，而后者，重依赖于制定代码变化标准的这个人，存在不稳定因素。
我们不妨从第一性原理出发，解决提出问题的人？（手动狗头） 假设采用前者封装的复用是高保值的资产或者低保值的同时低成本，则前者的产出是蕴含后者的，前者在 AI 时代甚至是能用机器来代替，我们把使假设条件成立的因素定义为复用成本（心智成本，维护成本，使用成本，重新生产成本等），那么复用的成本越低，则越趋近理想状态，最终达到复用之极致。
那么 iofod 采用哪些策略来降低复用成本呢？第一，抹平了平台与端的差异，原子组件在不同的宿主环境下视觉与交互统一，一次开发，到处运行，终生复用；第二，体系下封装成本，使用成本几乎没有，任意组件交互组合、业务模块，一键保存为可复用单元，所有项目可一键导入使用，无需繁复的使用手册；第三，定制成本极低，原子化组件的独立性与可组合性保证复用组件的依赖最小化，各司其职，对比同类产品，在定制化层面简直一骑绝尘；最后，复制粘贴光荣，行走的 Dockerfile，像设计师找素材一样所见即所得，社区项目零成本借鉴。
拓展体系
iofod 带来了通用界面设计开发的能力，为了最大化利用该能力创造更多价值，为开发者开放拓展能力的功能必不可少，因此拓展能力是 iofod 面世前就具备的能力。通过调研大量市面插件拓展的方案后，发现VSCode 的拓展设计理念最接近我们的理想状态：独立进程，逻辑与视图隔离和有限拓展组件。
在我们的设定中，拓展通过 Web Worker 运行于独立的线程，隔离拓展逻辑，通过 SDK 与 iofod 编辑器主界面通信，可拓展编辑时能力与导出能力，借助 SDK 提供的组件拼装拓展界面：
为了带来更好的拓展开发体验，我们提供了TS版本的 iofod-sdk，内部包含大量文档注释与代码示例，借助编辑器的智能提示，可做到无需对照文档开发。另外，可通过 CLI 脚手架工具快速创建拓展开发工程模板，感兴趣的小伙伴还可以学习下已发布的开源案例，快速上手。
实时协同
劳动分工提高了生产效率，这是工业社会的共识，而有分工的地方就有协同。20年新冠黑天鹅极大催生远程协同办公需求，成为很多企业的必需品，协同的重要性不言自明。iofod 基于 WebRTC 实现多人实时协同编辑，借助 CRDT 保证数据同步的强最终一致性，再利用 OT 算法保证数据合并能最大程度符合用户预期。
工作流的融合与重塑
瀑布流模型是古老的软件开发流程之一，相比混沌状态，它最大改进是要求开发者先思考，然后才是编码，需求和设计先于编码，相信这也是大多数技术公司采用的流程，一环扣一环严格分工，但这只在特定类型的软件开发上是有效的，涉及用户界面的应用或软件上并不合适。
首先，我们不知道产品在推出前能否最终取得成功，也就是说产品的最终形态不会是一开始就确定下来，需求是会变的；其次，在瀑布流模型中，用户只出现在需求分析和验收测试两个阶段，这意味着中间环节出问题，会等到瀑布流走完整个链条才被发现；最后，需求变动会影响链条上的所有人，过程资产可能无法复用。这是传统的瀑布流模型与快速变化的现实世界的冲突，难道我们不想改变这低效的现状吗？
实时协同的理想状态是多角色协同，假如产品经理，设计师，开发者都能参与进来，那么项目开发的整个生命周期，是从串行改并行的，中间过程资产可以复用，比如开发者无需对着高精度原型或者UI稿重新用代码实现一遍；降低上下游沟通成本，比如用户界面的变动，若只涉及视觉部分，那么设计师直接调整即可，无需重新出稿以及代码调整；前期需求还不是很明确的时候，开发者无需提前抽象封装业务组件，仅实现当下固定的部分，以及支撑当前需求的部分，减少无效编码。
iofod 提出了应用开发的新范式，无论是直接改线上文件的作坊式暴力美学，还是追求高效精简工作流的中小团队，或者是注重稳定性的大教堂流水线，都能无缝衔接融合。
结语
随着科学发展，第一类和第二类永动机相继被判死刑，人类收敛自己生物链顶端的傲慢，紧接着又从各个角度打破幻想：数学的哥德尔不完备定理，量子力学的测不准原理，机器学习的没有免费的午餐定理，区块链的FLP不可能原理...人类花费大量的努力去破除因果迷信，认识客观规律，为前进的方向定界，但即便当下我们的思维依然囿于大情节的迷恋，对不可能的事物一厢情愿。软件开发同其他社会生产活动一样，本质上属于耗散结构，唯有不断重构优化才能保持不腐败，从写下第一行代码开始，它的复杂度就天然存在了，无Bug只是临时的，所以我们努力的方向不该是要求人不会犯错。
iofod 编辑器开发完成后，公司所有网站和应用都是通过它来构建，我们再也回不到从前，如果说“自己会用”是对 iofod 最基本的要求，那么“少部分人离不开它”则是我们接下来的目标。iofod 作为一个低代码平台的意义之一，就是将相似的生产成本转移到工具内部，工具内部去处理这部分成本，再结合全新的开发范式，让应用开发生产力达到一个新的水准。
都看到这了，不来试试？