Blockly与Scratch3.0的⽐较分析
可是时间究竟是什么？没有⼈问我，我倒清楚，有⼈问我，我想给他解释，却茫然不解了 --奥古斯丁
Blockly与Scratch3.0的⽐较分析
在我们分析Blockly与Scratch3.0之前，我们需要先阐述⼀下，Scratch3.0与Blockly分别是什么
Blockly是什么
The web-based visual programming editor
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前世今⽣的追溯，可以参考我之前的这篇⽂章:
Scratch3.0是个低门槛、宽围墙、⾼天花板的playground
这个⽐喻精彩之极，它阐述了Scratch的设计哲学。
Scratch被设计为⼀个playground，⼀个playground应该尽可能提供丰富的基础设施，供它的使⽤者们嬉戏玩乐和探索。所以我们在Scratch3.0中看到了丰富的积⽊块和富有表现⼒的舞台效果，以及强⼤的可扩展性
关于这点，⾥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 wiki中对此也有
这也是程序员们理解⼀个项⽬最常⽤的⼀种⽅式，这种⽅式给了你⼀种安全感，你看到了项⽬内部的细节，源代码不会骗⼈，代码也不会给你看⼀堆有的没的PPT，或像我⼀样，扯⼀些有的没的形⽽上学
代码虽然不会骗⼈，但庞⼤的代码，在没有架构描述，没有好的⽂档的时候，对新⼿⽽⾔，跟读天书
也差不太多，它不骗你，它只是让你晕头转向，Scratch团队⽬前要忙的使其实在太多，限于⼈⼒，你不能在短期内指望他们提供⽂档
尽管没有⽂档，我们要⼀窥Scratch3.0的整体组成还是不难的，scratch-gui聚合了其他的组件:
scratch编程appscratch-vm
scratch-blocks
scratch-render
scratch-storage
scratch-audio
...
构成了完整的Scratch3.0
Scratch3.0是那种你⽤过就知道是什么的东西
这个阐述⽐较抖机灵，就像说
诗是那些翻译之后就消失的东西
或者
风景是拍进照⽚就不见的那些东西
这些阐述有某种禅的味道，或者是对其进⾏的恶意模仿
但我相信这个阐述会得到让·⽪亚杰、Papert和艾伦.凯的赞同，你可以轻松在使⽤过程中掌握⼀个概念或⼯具，⽽很难在⼀种概念的⽂本化阐述中掌握它。关于这点⽪亚杰做了精彩的论述，但是他的书真是太难读了。⼤家有兴趣可以看看：
⽐较分析
⼀圈阐述下来，我们对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.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和Scratch3.0都有了清晰的了解，这时候的选型问题，就取决于你要做的具体事情了，我们来讨论⼀些典型的场景
⽐如你想做⼀个或者Tynker这类⽹站，Blockly是个理想的选择，事实上，或者Tynker也确实是这样做
的，Blockly+interpreter是这类⽹站理想的解决⽅案，简单灵活。和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控制？是否⽀持事件风格编程？值得专门写⼀⽚⽂章谈论
尾声
这篇⽂章，拖了好久才写完，写这篇⽂章的时候，我在碧⼭，阿朱阿碧的碧，满⽬⼭河的⼭，写完后，我下午该从这⼉离开了，昨晚下了⼀夜的⾬
我晚上撑着伞，⾛过村头巷尾，路过⼀户⼈家的厨房，很旧的房⼦，门很⼩，⾬很⼤，我在门⼝站了⼀会⼉就⾛了
上次夜⾥路过⼀户⼈家厨房的时候，你说着彼得潘的故事，我这回在这⼉读完了彼得潘
只有⼀个陌⽣的⼩男孩，从窗外向⾥张望。他的乐趣数也数不清，那是别的孩⼦永远得不到的。但是，只有这⼀种快乐，他隔窗看到的那种快乐，他却被关在了外⾯，永远也得不到