Blockly与Scratch3.0的比较分析
原文网址：https://blog.just4fun.site/scratch3-blockly.html
可是时间究竟是什么？没有人问我，我倒清楚，有人问我，我想给他解释，却茫然不解了 --奥古斯丁
Blockly与Scratch3.0的比较分析
在我们分析Blockly与Scratch3.0之前，我们需要先阐述一下，Scratch3.0与Blockly分别是什么
Blockly是什么
The web-based visual programming editor
blockly将自己定位为一个编辑器。这个描述再精当不过
我在之前的文章: blockly入门与介绍里说:
blockly作为编辑器，它的输入为用户的拖曳（拖曳作为一种输入，可以类比为普通编辑器的键盘输入），输出为生成的代码。使用blockly可以快速打造一个特定领域的可视化 块编程 编辑器
至于每个积木（block）如何生成代码，代码用于什么用途，blockly则通通不关心，用户自己掌控。
我们可以简单将blockly视为积木化的编辑器，编辑器的输出只有代码。Do one thing的原则让它成为一个灵活小巧的库，而不是框架，可以轻松与其他工具整合
Scratch3.0是什么
那么Scratch3.0是什么呢，相比于Blockly是什么，这个问题要难回答很多，可能的答案有:
- Scratch3.0是Scratch2.0的下一个版本，使用html5构建
- Scratch3.0是个
低门槛、宽围墙、高天花板的playground - Scratch3.0是一个Blockly APP
- Scratch3.0是scratch-gui + scratch-vm + scratch-render + ...
- Scratch3.0是那种你用过就知道是什么的东西
这几条阐述颇有盲人摸象的味道，我们站在不同侧面去阐述我们看到的Scratch3.0
其触牙者，即言象形如莱茯根；其触耳者，言象如箕；其触头者，言象如石；其触鼻者，言象如杵；其触脚者，言象如木臼；其触脊者，言象如床；其触腹者，言象如瓮；其触尾者，言象如绳
盲人摸象的比喻异常深刻，不盲的我们，看到真实的事物是经过这样一个过程：可见光进入视网膜，经过神经元对光信号的解释和传递，在大脑渲染出一个图景,尽管隔了这么多层，我们坚信看到了所谓的真实
我们可能确实看到了真实，毕竟我们有阐述真实的权利:)
下边我们来逐条阐述Scratch3.0是什么
Scratch3.0是Scratch2.0的下一个版本，使用html5构建
这条侧重在解释3.0，Scratch3.0是对Scratch2.0的升级，3.0基于html5技术构建，可以跨平台运行
这条回答站在Scratch发展过程的视角来看，如果你是Scratch的老用户，这句话也许足以让你醍醐灌顶。但新认识Scratch3.0的小伙伴对这个阐述应该不会感到满意。
学习哲学的一种好办法是学习哲学史，溯本求源常常是个不错的方法，对scratch前世今生的追溯，可以参考我之前的这篇文章:Scratch的前世今生
Scratch3.0是个低门槛、宽围墙、高天花板的playground
这个比喻精彩之极，它阐述了Scratch的设计哲学。
Scratch被设计为一个playground，一个playground应该尽可能提供丰富的基础设施，供它的使用者们嬉戏玩乐和探索。所以我们在Scratch3.0中看到了丰富的积木块和富有表现力的舞台效果，以及强大的可扩展性
关于这点，Learning Creative Learning 第五周的课里里Scratch的创始人做了精彩的阐述
Scratch3.0是一个Blockly APP
就这篇文章而言，这是个不错的答案，它甚至应该放到下文Blockly与Scratch3.0的比较分析的部分里
Scratch3.0是一个Blockly APP这句话的意思是，Scratch3.0基于Blockly构建，就是说Scratch3.0中包含了Blockly。
那么什么是Blockly APP呢，按blockly官方说法，你需要做以下三步：
- 集成blockly编辑器
- 定义你的app里的功能块（block）
- 构建app的其余部分，blockly仅充当代码生成器，你需要决定这些用户生成的代码用于做什么，这也是你的app的核心功能所在
Scratch之前并不是基于Blockly构建的，3.0的版本里，才这样做，为何之前的Scratch不基于Blockly呢，因为Scratch这个项目比Blockly更早诞生，Scratch前几个版本的积木块都是自己造的轮子。现在Blockly几乎是公认最好的积木化编辑器，所以Scratch在3.0里把轮子换成Blockly
说Scratch3.0基于Blockly构建依然显得含糊其辞，Scratch3.0是个庞大的项目，包含了很多组件，只有其中的scratch-blocks基于Blockly，
Scratch3.0是scratch-gui + scratch-blocks + scratch-vm + scratch-render + ...
这条阐述是程序员视角，站在Scratch3.0的项目结构上解释它
Talk is cheap , show me the code
我们直接打开Scratch在github的主页，就可以看到相关的项目细节，源码一览无余都在其中, scratch wiki中对此也有介绍
这也是程序员们理解一个项目最常用的一种方式，这种方式给了你一种安全感，你看到了项目内部的细节，源代码不会骗人，代码也不会给你看一堆有的没的PPT，或像我一样，扯一些有的没的形而上学
代码虽然不会骗人，但庞大的代码，在没有架构描述，没有好的文档的时候，对新手而言，跟读天书也差不太多，它不骗你，它只是让你晕头转向，Scratch团队目前要忙的使其实在太多，限于人力，你不能在短期内指望他们提供文档
尽管没有文档，我们要一窥Scratch3.0的整体组成还是不难的，scratch-gui聚合了其他的组件:
- scratch-vm
- scratch-blocks
- scratch-render
- scratch-storage
- scratch-audio
- ...
构成了完整的Scratch3.0
Scratch3.0是那种你用过就知道是什么的东西
这个阐述比较抖机灵，就像说
诗是那些翻译之后就消失的东西
或者
风景是拍进照片就不见的那些东西
这些阐述有某种禅的味道，或者是对其进行的恶意模仿
但我相信这个阐述会得到让·皮亚杰、Papert和艾伦.凯的赞同，你可以轻松在使用过程中掌握一个概念或工具，而很难在一种概念的文本化阐述中掌握它。关于这点皮亚杰做了精彩的论述，但是他的书真是太难读了。大家有兴趣可以看看：Scratch的前世今生
比较分析
一圈阐述下来，我们对Blockly的理解相对清晰: 这是一个积木化代码编辑器
对于Scratch3.0，我们从很多个侧面试着阐述它。Scratch3.0是复杂的，我觉得没有必要回避这一点，对于复杂事物，相比于下个断言，我更愿意从不同侧面观察它。
现在我们来比较一下这两者，这些比较的视角，是我临时拍脑袋想到的一些方面，有了前边对二者的分析和阐述，你其实也可以写出一大堆的比较分析。
我们可以把Blockly视为一个库，而把Scratch3.0视为一个框架。一个库往往遵循Do one thing的Unix哲则，你可以轻松将它组合到你的项目中，Blockly库只负责从积木中生成代码，怎么去使用这些代码？这些代码是控制虚拟角色还是实际的硬件？它何时被解释运行？是否支持并行？代码运行生命周期是怎样的？解释器在本地还是在另一个硬件上？Blockly通通不关心。Blockly给予你自由，同时你也不得不肩负起自己的责任，你需要去考虑构建一个Blockly APP剩下的部分，当然一个典型的Blockly APP我相信是有最佳实践的，目前我认为这里边存在需要解决的大的问题有且仅有3大类，这个话题与本文关系不大，之后有机会再说。值得提醒的是，你遇到的一些觉得难以绕过困难，可能是一些构建一个解释器会遇到的困难，这个困难和普通的编写程序很不一样，因为大部分时间里，我们都是在使用解释器，而不是构建一个，这可能是让很多开发者不知所措的地方。
相比于Blockly，Scratch3.0则更像一个框架，Scratch3.0几乎开箱可用，它有各个组件，你可以通过修改这些组件来定制它，当然你需要先理解它。你可以通过插件系统加入自己的扩展，无论是软件还是硬件，你都可以进行拓展。如果是对硬件的扩展，你可以考虑基于我们的工作来做，会轻松很多，参考:Scratch3 Lab: 将Scratch3接入开源硬件及AI的实验项目
说Scratch3.0是框架，侧重在强调它的结构完整性和灵活性，它不是vue、django那种框架，Scratch3.0介于框架和项目之间，它给予你的自由度要比一般意义上的框架要小
Scratch3.0的解释器相关部分:scratch-vm 十分强大和灵活，要做到这点很不容易。如果你在做和Scratch3.0类似的事，最后不要重造轮子。已经有大厂试着从Blockly开始，重造一个Scratch3.0，他们确实也造出来了。很难的工作在于重写scratch-vm。在一个典型blockly APP中，大家一般使用官方推荐的interpreter来解释执行代码，但在一个复杂项目中，可能是不够的。如果你准备重写scratch-vm，最好有懂解释器的人。而且最好不要去做这件事，尽管你可能做得到，但它的灵活性很难有scratch-vm那么好。
选型建议
那么我们究竟什么时候选择Blockly，而在另一些时候选择Scratch3.0？
这恐怕是不容易说清楚的问题，我试着给出一些建议。大多时候需要你对自己正在做的事情有清晰的阐述之后，才好给具体建议。认识你自己总是没错的
简单地说如果你才涉足积木化编程这一块，那么从Blockly开始常常是个好建议，因为Scratch3.0很复杂，除非你想原原本本地使用Scratch3.0,否则对它的任何修改，对早期团队来说都是艰难的；你折腾任何积木化编程项目的时候，可能都会遇到一些共性的问题，如我前头提到的那一大串，Scratch3.0在这块探索了很久，也给出了很多优秀的解决方案，但你一来就读Scratch3.0相关组件的源码，很可能云里雾里，你可能先要从钻木取火开始（从Blockly基础项目开始），等你意识到这个问题域的常见困境之后，才会意识到什么好的解决方案。在困境出现之前，好的解决方案会被看作一种过度复杂的设计
也许你最终选择使用Scratch3.0，但Scratch3.0基于Blockly构建，对Blockly的早期投入，总是能帮助到你理解Scratch3.0的
关于如何开始Blockly的旅程的教程目前少的可怜，如果你愿意可以从我之前写得东西入手，源码和文章都有：blockly入门与介绍, 文末附有教程和源码
前边只是泛泛地建议说你应该从Blockly开始，对于你最终应该选择什么，并没有给出具体建议
让我们假设你已经对Blockly和Scratch3.0都有了清晰的了解，这时候的选型问题，就取决于你要做的具体事情了，我们来讨论一些典型的场景
比如你想做一个code.org或者Tynker这类网站，Blockly是个理想的选择，事实上，code.org或者Tynker也确实是这样做的，Blockly+interpreter是这类网站理想的解决方案，简单灵活。code.org和Tynker中的每个关卡都是一个典型的Blockly APP。当然如果你愿意，你也可以使用scratch-blocks来做，深圳已经有公司这样做，你可以将scratch-blocks视为Blockly的定制版（使用scratch-blocks和使用blockly几乎没有区别，我在教程里也写了这部分），只是改了积木的UI风格，但它们依然可以被当作干净的库使用，而不牵扯太多Scratch3.0的其他东西，至于generate代码的功能也完全一样
假如你想做一个机器人控制/教学平台，两者都可选，目前市面上的机器人使用scratch2.0控制的居多(部分原因是Blockly出现的比较迟)。新出的机器人使用两者的都有，使用Blockly的优势，如前边说的：轻量，自由，但也意味着你要去操心更多解释和实现上的细节工作，这是个复杂的工作，有机会单独讨论；使用scratch的话，你只要专心写插件部分就好了，如果你的机器人是交互式的，比如Cozmo（我已经把它接入Scratch3中)，关于代码如何被vm解释运行，如何控制生命周期，如何支持事件和并行，scratch-vm都帮你做了！
关于积木化编程工具与硬件/机器人交互的话题，涉及很多典型问题：代码灌入式的还是服务风格的？通信方式是什么？基于web控制还是基于APP控制？是否支持事件风格编程？值得专门写一片文章谈论
尾声
这篇文章，拖了好久才写完，写这篇文章的时候，我在碧山，阿朱阿碧的碧，满目山河的山，写完后，我下午该从这儿离开了，昨晚下了一夜的雨
我晚上撑着伞，走过村头巷尾，路过一户人家的厨房，很旧的房子，门很小，雨很大，我在门口站了一会儿就走了
上次夜里路过一户人家厨房的时候，你说着彼得潘的故事，我这回在这儿读完了彼得潘
只有一个陌生的小男孩，从窗外向里张望。他的乐趣数也数不清，那是别的孩子永远得不到的。但是，只有这一种快乐，他隔窗看到的那种快乐，他却被关在了外面，永远也得不到