当我们在讨论可视化布局的时候，到底在讨论什么？是低代码吗？是表单生成器？还是Dreamweaver?好像这些都跟可视化布局有关，但是产品形态差异又很大。那么，为了讲明白可视化布局，我们先从可视化布局的分类开始。
可视化布局的分类
既然是分类，那就得有依据和标准，按照现在市场上已有的产品从目标用户和核心产物来对形形色色的可视化工具分类是最为妥当的。
目标用户，分两种：
- 非开发者
- 开发者
目标用户为非开发者的可视化布局，一般会提供详细的配置项和一些逻辑表达能力。而目标用户是开发者时，配置项则会较为精简，而且大部分不提供逻辑表达能力。之所以出现这种现象，是因为用户诉求不同，非开发者的诉求是更强大的交互体验，而开发者的诉求则是更高的编码效率。
核心产物，分三种：
- 可直接运行的产品
- json
- 可维护的代码片段
核心产物并不是一个严格的界限，因为有的产品会同时提供这三种产物，所以我的依据并不是根据平台是否提供这些产物，而是哪种产物对于这个产品来说是核心。
低代码
低代码开发是指无需编码或通过少量代码就可以快速生成应用程序的开发平台。通过可视化进行应用程序开发的方法。毫无疑问，低代码的的目标用户是非开发者，核心产物是可直接运行的产品。
大部分的开发者经常会吐槽低代码是‘毒瘤’，如果你是从开发者的角度去看低代码提供的能力，那么它确实是个‘毒瘤’，因为毫无效率提升可言，通常用低代码平台配置出一个页面，熟练的前端开发者都可以完成好几个页面。但是，从非开发者的角度而言，低代码有其自身的价值，例如能降低编程门槛，更好地协调运营，开发资源等等。
低代码有很明显的瓶颈，用编程语言来进行逻辑表达和用可视化布局进行逻辑表达这本身就存在着巨大的鸿沟，有些产品为了不断丰富可视化布局的逻辑表达能力而变得异常臃肿，导致系统复杂性不断提升。最终这些复杂性会反映在系统的稳定性，用户操作复杂度上，从而逐渐演变为‘很难用的产品’。所以，因为逻辑表达能力的限制，市面上的低代码大部分都是用于配置简单的h5营销页面。
可视化表单生成器
form generator 是一个很典型的表单生成器。目标用户是开发者，核心产物是json或可维护的代码片段。由于表单生成器的实现方式不尽相同，有些核心产物是json，你可以引入它的组件，然后传入配置出的json就可以得到一个功能完备的表单，这类产品的核心产物是json。而另一类直接生成代码的表单生成器，核心产物则是可维护的代码片段。从侵入性，以及性灵活的角度考虑核心产物为代码片段更容易让开发者接受。
另外，还有一些表单生成器的目标用户是非开发者，核心产物是可运行的产品。例如问卷这类产品，由运营人员配置表单，分发给普通用户进行填写。所以。这类产品称为低代码更合适。
可视化编辑器
Dreamweaver，winform等可以归类为可视化编辑器。可视化编辑器的目标用户是开发者，目标产物是代码片段。这类产品的主要用于静态界面的生成，提供逻辑表达能力的较少。这一部分我只想讨论一个问题：‘为什么可视化编辑器在有强烈的市场需求和足够的技术支撑下，最后却都凉凉了呢？’
我认为最重要的一点是：核心产物变化太快。虽然这里的核心产物都是指可维护的代码片段，但是不同的时间点对于可维护的代码片段定义是有天壤之别的。十年前，可维护的代码片段是指纯净的css,html,js。五年前，可维护的代码片段你至少得用上一些库了吧，用jquery，bootstrap这类库写出来的代码才称得上可维护。而今天，可维护的代码片段必须是组件化，模块化的。由于核心产物变化太快，导致这类产品最后只能成为一个美好的愿景，被淹没在历史的洪流里。
物料体系
物料是可复用的代码片段。提到物料，你可能会联想到飞冰。大家经常把飞冰归纳到低代码，但实际上，飞冰的目标用户是开发者，核心产物是代码片段，从百科所描述的低代码定义上看，飞冰基本不沾边。而且，它只是帮你管理代码片段，甚至都不属于可视化布局。但是，由于这类产品经常被误解为是低代码，所以我觉得有必要解释一下。目前没有很好的分类，所以就叫它物料体系吧。
由于物料体系较少，所以这一部分我们介绍一下飞冰是如何实现物料体系的。可视化编辑器中我们提到，由于核心产物变化太快，导致生成的代码很难具备可维护性。飞冰的做法是，那我就不生成代码了， 你自己传代码片段自己用好了，我只帮你管理这些代码片段。不管飞冰的文档中有多少让你摸不着头脑的概念，本质都是解决两个问题，如何上传代码片段以及如何使用代码片段，仅此而已。
那你说，这玩意儿提升效率吗，每次写页面还得把一些复用性较高的代码片段传到飞冰上面。从你当下的开发来说，确实没有效率提升。但是，随着物料库的沉淀，后面一些重复的界面和布局就不需要手写了，直接用以前的代码片段就好了。
但同时，它的缺点也很明显，第一，没有预览。只能靠截图辨别物料的样式，由于不同的代码片段运行环境可能是不同的，靠物料的截图来告诉使用者具体的样式，在使用的时候是有心理负担的，我引入的代码片段在我的这个环境里能不能展示出跟截图一样的样式，使用者心里是没底的，这在你使用别人的物料时尤为明显。
第二，物料之间是孤立的。在飞冰中，把物料按颗粒度分为组件，区块，页面。我们假设一个页面由三个区块组成，我们现在要完成这个页面，不管你是用gui还是cli的方式，你得到的都只是一个个孤立的代码片段，至于我这三个物料是横着摆还是竖着摆，得靠你自己去实现。文章的开头我们就讲到，对于开发者而言，效率提升是第一位的。如果是用表单生成器这种需要做一堆配置才能生成界面，确实没有效率提升。但是如果能对物料做可视化布局则会有相当的生产力提升，首先对于物料来讲基本没有配置项了，其次你不需要自己写布局了，最后你不用分别去引入三个区块，直接引入最后可视化布局生成的代码即可，操作更加便捷了。
为什么没有预览？
我们通过 iceworks CLI 这个工具提供物料的开发与管理，其本身不耦合任何前端框架或工程体系，这意味着基于 iceworks CLI 可以开发 React/Vue/Angular 等各种前端体系的物料
上面这段话摘录自飞冰官网，对于这段话，我的理解是不管你传的代码片段是什么，它都只是一个文件而已，我们压根儿没打算做个runtime出来支持这些文件的运行。做一个支持不同应用层框架，不同UI库，不同插件的runtime的确是一件极为复杂的事情，这也就是为什么飞冰不支持预览了。
为什么物料之间是孤立的？
我觉得飞冰的开发团队肯定也想到过，做物料的可视化布局。不过还是那个问题，由于没有预览，你拿着截图做可视化布局，对于使用者心理负担就更大了。其次，由于物料没有环境限制，不同的物料运行环境不同，也是无法做可视化布局的。
物料体系和可视化布局
基于上面的这些思考，我尝试做了一个物料体系和可视化布局结合的产品，我叫它 fuep ，希望通过构建物料库，来帮你减少在开发者中后台系统时重复的工作。现在已经有相当不错的完成度。它的优点是，可以预览，并且物料是支持可视化布局的。
你可以上传一个单文件组件的代码，点击预览，它会在服务端进行complie，然后传给前端利用runtime渲染出来，以保证样式是符合预期的。
物料之间可以进行自由组合，你可以选择任何你希望的布局，最后会将物料包裹在一个flex布局中，生成最后的代码。
客观地说，fuep也有自己的缺点，由于我们要做runtime，所以物料的运行环境有限制，目前只支持vue3生态的element plus和vant3，而对于一些预处理器的支持，例如less,sass,pug等也还不完善。
可视化布局是‘红海’吗？
如果可视化布局是指低代码，可视化表单生成器，可视化编辑器那它确实是红海。如果是指物料体系，或者基于物料体系的衍生物，那还是一片蓝海，等待探索。
