前言
前端近年来始终在尝试如何进步开发人员的效率，从最后的脚手架工具、组件库、继续集成体系、自动化测试、多端适配到当初的全面的低代码平台、前端智能化、在线 IDE，大家都在为将来的新的且高效率的形式做着致力。
前端行业行将要进入到下一个阶段，因为对于如何搭建组件库、脚手架曾经有大量的文章 / 教程，曾经快到了人人能够手撕一个组件库的阶段了，并且随着前端开发人员的技术的普遍提高，干燥机械式地写代码（款式 / 布局）曾经无奈满足开发人员日益增长的追赶技术的心了，因而须要智能化布局来解放这些干燥的工作。
落后就要挨打，我就打算趁着周末打算摸索一下前端智能化。（自己也是老手，纯是感兴趣~，因而不必放心看不懂）
倒退历程
其实要说从设计稿转化为 html 的我的项目，最早能够溯源为 PS(Photoshop) 的导出 html 性能，PS(Photoshop) 堪称是一个老牌的设计产品，从 1988 年首次公布新版本，到当初依然在更新。
咱们来体验一下这个性能。
首先关上 PS，导入一张网上轻易下载的图片，将 图片 拖进 PS。而后依照以下步骤进行操作。
1. 按 command/ctrl + R 关上标尺
2. 拖出辅助线，拖出宰割块
3. 抉择切片工具（裁剪工具那一个图标按右键）
4. 抉择顶部的基于参考线切片
5. 文件 – 导出 – 贮存为 web 所用格局
就能看到导出了以下几个文件。（我这里切的比拟毛糙如果是精密地将一张图片进行切片，应该是十分合乎 web 的所用格局的，毕竟很久以前，设计师就是这么给咱们切片的）
而后咱们关上 html 查看外面的元素。
发现它次要以 table 的形式来布局，然而这样的模式，在日益繁多的设施上是无奈应用的（可能在过后的 PC 上还能有不错的利用场景。）
前端过后正处于萌芽阶段，前端智能化的概念还没有被提出，没有 Vue、React，没有工程化，也没有低代码，一切都是刚刚起步，前端智能化也没有被提及。
直到 2017 年，一篇 pix2code: Generating Code from a Graphical User Interface Screenshot 的论文引起了业界的关注，该论文实现了从一张 UI 截图辨认生成了 UI 构造，并且将 UI 构造形容转化成了 HTML 代码。
随后，基于 pix2code 开发的 Screenshot2Code 我的项目速度进入到 Github 排行榜第一，该工具可能将 UI 截图转成 HTML 代码，该我的项目作者号称 3 年后人工智能会彻底改变前端开发。
2018 年，微软 AI Lab 开源了草图转代码工具 Sketch2Code，一些人认为生成代码成果不现实不适用于生产环境，但也有人认为代码主动生成还处于初级阶段，将来倒退值得设想。
工作流：
成果实现：
始终到 2019 年，D2 前端论坛（Designer & Developer Frontend Technology Forum, 简称 D2）公布了 imgcook，前端智能化这个词正式确立了。
随后 58 团体、CodeFun 等 都相继公布了智能化的产品，然而这个行业是年老的，也是具备挑战的，这些产品的都还在初期，尽管没方法全方面的失去开发者的青眼，然而都曾经有一些不错的落地场景了。
我的项目体验
设计稿：demo.sketch
代码与 sketch 下载地址：https://github.com/nan980914/…
<img src=”https://s3.qiufengh.com/nan/image-20210819200136614.png” alt=”image-20210819200136614″ style=”zoom:50%;” />
这次将别离体验 58 的 Picasso、imgcook、CodeFun 3 款工具的「sketch 设计稿转代码」。
咱们将以平时写代码中比拟器重的几个局部来对这三款软件进行剖析：
- 是否能够还原设计稿
- 布局辨认的准确性
- 代码（css）可维护性（代码量，定宽定高，flex）
- List 自动识别，分组
- 列表循环辨认
其中第一点是最根本的，因为如果一个 D2C（Design To Code）工具，抛开一些布局之外，连根本的设计稿都无奈 1:1 还原的话，对咱们开发的工作量来说太微小了，这就好比某个共事曾经写了一个半成品我的项目了，这个时候他忽然有事销假了，须要咱们去帮忙结尾，这个时候咱们须要去看他人的代码，再去批改。每每这个时候心里都会念叨，还不如本人从新写一个我的项目。
对于第二点来说，布局的准确性，明明是一个左右布局，你给我辨认成了高低布局，那基本上那一块的代码都都从新进行批改。相比第一点来说，略微还好一些，至多不是去拾掇一个半成品，只是去改他人写好的我的项目中 bug 一样，至多还是能用的。
第三点的话，我认为还是很重要的，CSS 代码的可维护性，咱们都晓得设计图上对于模块的大小都是 width 和 height 的标注的，然而咱们真正在写代码的时候，都是不会去定宽和定高的，都是由外部元素去将模块给撑开高度，这样的话，对于挪动端的短适配性会比拟好。
<img src=”https://s3.qiufengh.com/blog/image-20210822181228618.png” alt=”image-20210822181228618″ style=”zoom:33%;” />
对于第四点和第五点，算是写代码的复用小能手，对于一个 list 咱们个别不会去在 html 写死成多个 块，而是会用循环难受，缩小反复代码，也是为了可能和后端进行适配。
58 Picasso(https://github.com/wuba/Picasso)
操作流程：
Picasso 的 Github 仓库上下载其 sketch 插件毕加索，在 sketch 中选中咱们的画板后生成 Web 代码。
<img src=”https://s3.qiufengh.com/nan/image-20210819200538887.png” alt=”image-20210819200538887″ style=”zoom:50%;” />
而后就导出了这样一个文件，让咱们关上 index.html 来看看成果。
<img src=”https://s3.qiufengh.com/nan/image-20210819200724369.png” alt=”image-20210819200724369″ style=”zoom:50%;” />
1. 是否还原设计稿：
<img src=”https://s3.qiufengh.com/nan/image-20210819201050116.png” alt=”image-20210819201050116″ style=”zoom: 50%;” />
怎么说呢，能够看到 58Picasso 这个还原成果其实除了订单的实付价格那里不晓得怎么被挤下去了，和底部 footer 的款式错乱以外看起来还能够，那咱们来看看代码到底怎么样。
2. 布局辨认的准确性：
<img src=”https://s3.qiufengh.com/nan/image-20210819221257782.png” alt=”image-20210819221257782″ style=”zoom:20%;” />
咱们期待的是两个左右构造的块，却被辨认成了这个样子 …
尽管以上采纳了 flex 布局，然而并没有等分布局，并且也被定宽了，咱们心愿的是：
3. 代码可维护性：
index.css 生成 1289 行。
剖析了一下它会生成如此多代码的起因。
1. 累赘的类名
它给每一个 div 元素都设置了一个英文单词，并且与以后的模块的语义化重大不符。
<img src=”https://s3.qiufengh.com/nan/image-20210819223432335.png” alt=”image-20210819223432335″ style=”zoom: 33%;” />
2. 定宽定高
因为它给每个 div 都是定宽定高的，因而也产生了许多不必要的代码。
3. 同类型无奈合并
因为没有方法归类雷同的元素，因而代码也变得更多了。
4. List 自动识别，分组
剖析这个设计稿咱们能够看进去，上面三个订单的块其实是十分类似的构造，咱们心愿生成的代码能把类似的构造辨认进去并分在同一个组内而不是平铺。
<img src=”https://s3.qiufengh.com/nan/image-20210820001248378.png” alt=”image-20210820001248378″ style=”zoom: 33%;” />
连 list 都没有辨认好，那就没有第五步了，总结起来这样的代码，好像就是共事甩的锅一样，难以保护，有这工夫看代码和修复代码，本人曾经写好一个完满版本了。
5. 总结
所以 Picasso 间隔工业化代码还是有肯定差距的，不过 Picasso 的代码是开源的，外面的布局计划是通过图层解析出 DSL，而后再通过肯定的算法生成的代码。
imgcook(https://www.imgcook.com/)
流程：
imgcook 的官网上下载其 sketch 插件，在 sketch 中关上插件的面板抉择导出代码导出到咱们的我的项目，而后就能够去官网咱们的我的项目里查看。
<img src=”https://s3.qiufengh.com/nan/image-20210819224426696.png” alt=”image-20210819224426696″ style=”zoom:50%;” />
1. 是否还原设计稿：
<img src=”https://s3.qiufengh.com/nan/image-20210819224611510.png” alt=”image-20210819224611510″ style=”zoom:50%;” />
由图能够看到，imgcook 貌似都没有把设计稿还原。
订单治理那块的层级如同被下面给挡住了，另外 Button 都被描边了，显得特地粗。
2. 布局辨认的准确性：
<img src=”https://s3.qiufengh.com/nan/image-20210819230618209.png” alt=”image-20210819230618209″ style=”zoom:50%;” />
认真看其布局，其实辨认的比下面 58 Picasso 的精确很多，比拟合乎咱们日常写代码的习惯，然而仍旧被定了宽度。
3. 代码可维护性：
CSS 生成 1870 行 … 冗余代码十分多。
其实这部分还是和 58 Picasso 一样的问题的。累赘的类名，定宽定高，并且同类型没有合并（临时没有找到如何合并），还有些是通过 absolute 来布局的。
<img src=”https://s3.qiufengh.com/nan/image-20210820004007830.png” alt=”image-20210820004007830″ style=”zoom: 50%;” />
4. List 自动识别，分组
这里也和 58 Picasso 有点相似，貌似成果还是不太现实。也是没有很好地将 list 进行辨认。
imgcook 也算是一个做了比拟久的产品了，可见 D2C 的难度还是十分大的，对于算法的要求很高。
5. 总结
Imgcook 比 58 Picasso 改良了许多，退出了 AI 来训练模型，准确度和可用性都比 Picasso 好很多。并且模型训练框架 pipcook 也开源在 github 下面。
CodeFun(https://code.fun/)
流程：
CodeFun 的官网上下载其 sketch 插件，在 sketch 中关上插件的面板抉择上传此设计稿，而后就能够去官网咱们的我的项目里查看。
<img src=”https://s3.qiufengh.com/nan/image-20210816151945487.png” alt=”image-20210816151945487″ style=”zoom:50%;” />
1. 是否还原设计稿：
<img src=”https://s3.qiufengh.com/nan/image-20210819225417335.png” alt=”image-20210819225417335″ style=”zoom:50%;” />
很惊喜，CodeFun 这个还原的比下面两者都要好，和设计稿看起来简直 100%。
2. 布局辨认的准确性：
<img src=”https://s3.qiufengh.com/nan/image-20210819233809695.png” alt=”image-20210819233809695″ style=”zoom: 15%;” />
完满的辨认出了咱们期待的布局，然而这里要提一下的是，CodeFun 不仅辨认除了均分的 flex 布局，而且相比 imgcook 没有定宽，而是应用了flex-grow:1
成果如图：
看代码能够看到，局部公共部份的款式都被翻译到了 equal-division-item 这个 class 外面，几个 box 都共享上了，唯独 flex-grow:1 被独自弄成了group_16 17 18，造成了一些冗余的 css 代码，这么简单的辨认都做到了，这里是不是个 bug 呢？
3. 代码可维护性
css 代码生成 597 + 81 = 678 行（主代码 + 公共代码），比 Picasso 的1289行和 imgcook 的1870行别离缩小了 47% 和64%。
尽管类名还是有些不语义化，然而曾经是去除了写死的宽高，同类型进行了合并抽取出了公共代码。
<img src=”https://s3.qiufengh.com/nan/image-20210819234847486.png” alt=”image-20210819234847486″ style=”zoom:50%;” />
4. List 自动识别，分组
CodeFun 能自动识别出上面三个构造类似的订单模块，并进行分组，将三个块外面包了一个 wrapper，合乎咱们开发人员日常写代码的习惯。
<img src=”https://s3.qiufengh.com/nan/image-20210820002841419.png” alt=”image-20210820002841419″ style=”zoom:50%;” />
5. 列表循环辨认
因为曾经辨认出了上面三个构造类似的模块，于是 vue 代码会主动以 v-for 列表循环 的形式展示。
如果想要抽离数据，能够通过上方的数据绑定自定义字段名（个别咱们会绑定为后端传过来的字段名）。
绑定后的成果如下，其实到这一步，生成出的代码曾经齐全可用了。撒花🎉～～
6. 总结
评测 CodeFun 的时候，还是眼前一亮的，尽管说对于类名上，还是须要本人进行批改（不过对于一些保护不须要这么频繁的页面，也能够不进行批改类名），然而对于以上我列出的 5 点都曾经完满地进行解析了。CodeFun 也是通过 AI 模型来进行智能化训练，但训练的成果比 imgcook 更加弱小。
论断
| CodeFun | imgcook | 58 Picasso | |
|---|---|---|---|
| 反对语言 | Vue/React/ 微信小程序 /Taro(vue)/uni-app | 反对 15 余种 DSL | Html/ 微信小程序 /Reactive Native |
| 是否还原设计稿 | 是 | 否 | 否 |
| 布局辨认的准确性 | 高 | 较高 | 低 |
| 示例 sketch 导出后 css 代码量(行) | 678 | 1870 | 1289 |
| 代码可维护性 | 好 | 较好 | 个别 |
| 数据绑定 | 反对 | 反对 | 不反对 |
| 准确度 | 高 | 个别 | 低 |
| 评星 | ⭐️⭐️⭐️⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️ |
代码量计算：导出所有的代码（html+css+js）- 无用的初始化代码（例如 reset.css）
代码可维护性：节点变动、地位变动、款式变动、属性变动（https://juejin.cn/post/691187…）
将来与瞻望
通过这一次的评测，也理解了一些前端智能化的常识以及现有平台的撑持水平。发现前端智能化在将来的路线上还是能帮忙咱们提高效率的，至多在页面还原度下面，还是十分的完满的，不须要一直地和设计扯皮了，并且也不必当个切图仔了，可能把生产力聚焦于写 JS , 写页面的逻辑（好像和后端工程是差不多了，只须要关注逻辑与数据）。
毕竟 200 年以前你通知中国人当前不会再有皇帝，他们会通知你自盘古开天地啥时候没有过皇帝？只有咱们敢想没有什么不可能。像现阶段，主动驾驶、人脸识别 无论哪项技术的成熟，都对咱们的行业产生微小的影响。
前端也不例外，前端智能化、Web AR/VR、前端低代码、前端跨端每一项的成熟，都会给咱们带来颠覆性的影响。
将来可期！
参考资料
https://stackoverflow.com/que…
https://zhuanlan.zhihu.com/p/…
https://github.com/ashnkumar/…
https://fusion.design/pc/comp…
回看笔者往期高赞文章，兴许能播种更多喔！
- 2021 前端学习门路书单—自我成长之路
- 从破解某设计网站谈前端水印(具体教程)
- 一文带你层层解锁「文件下载」的神秘
- 10 种跨域解决方案（附终极大招）
结语
❤️关注 + 点赞 + 珍藏 + 评论 + 转发❤️ ，原创不易，激励笔者创作更好的文章
关注公众号 秋风的笔记，一个专一于前端面试、工程化、开源的前端公众号