对于最近的读者,截至2013年1月,我评估了:
通过“评估”,我所做的不仅仅是阅读文档。我创建了一个原型应用程序。
我开始使用Fabric是因为它似乎拥有最大的社区,并认为这将是我的解决方案。但是,由于以下原因,我放弃了Fabric:
- 怪异且未记录的API不一致不必要地消耗了我很多时间。
- 不一致的指针事件支持。具体地说,Fabric不会将“路径”视为是可选且可观察的真实形状对象。这不能满足我的需求,因为交互式路径是我应用程序的主要要求。
- 在幕后添加了对“画布”的翻译,以定位对象。对我来说,Fabric试图在这方面过于机灵,而开发人员却无法清楚自己在做什么。
- 关于如何移动,调整大小和旋转交互性的意见过于强烈。从很多方面来说,将此功能内置到框架中是很棒的,但就我而言,我不同意它的实现方式,这意味着本质上无论如何我都必须重新实现它。
- 稀疏文档-方法文档的格式为:“ setX(Y)-将X设置为Y”的情况很多:-)
我看了看Paper,并没有走太远。在我看来,这似乎太过迟钝,而且还落在IMO的大便之内-它太多了,无法作为Canvas的简单对象模型的可视化库,但还不足以与D3竞争。另外,该文档再次不是特别可访问。
如果您具有Flash / ActionScript背景,我认为Easel可能很有意义,但我没有。另外,对于我的要求而言,它似乎过于注重游戏。棺材上的钉子再次是文件资料-不够用,以非标准格式显示。
因此,我最终选择了Kinetic,因为:
- 真正丰富而清晰的教程和示例
- API函数可以实现所谓的功能,而且在很大程度上可猜测-生产率更高,学习曲线更浅
- 对它的作用和不作用的认识很明确-它不像其他的那么丰富,但这是有好处的;它做的事更少,但是做得更好
- 路径是一流的公民形状,就像其他任何形状一样,这对我的需求至关重要。
Kinetic无论如何都不是完美的,并且有好几次我不得不深入研究源代码来弄清楚幕后的实际情况。另外,我想念Fabric的SVG解析和输出。