可是时间究竟是什么?没有人问我,我倒清楚,有人问我,我想给他解释,却茫然不解了 --奥古斯丁
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是个低门槛、宽围墙、高天花板的playgroundScratch3.0是一个Blockly APPScratch3.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-vmscratch-blocksscratch-renderscratch-storagescratch-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出现的比较迟)。