Hello, my name is Christopher Allen. I have the great privilege of being one of the approximately
five engineers who work on Blockly at Google. We are part of engineering education and in
particularly we're the kids coding team. I'm based in London. I have colleagues primarily
in the US but also one in Zurich. So this talk I'm going to be talking a little bit
about what Blockly is and what it's used for. I'm guessing a number of you are probably
familiar with Blockly. Who has heard of Blockly before? Who has played with something containing
Blockly before? Anybody written something using Blockly as a component of the thing? Okay, yeah,
good mix of those. Great. So there will be a little introduction for the people who don't know
what Blockly is. We're also going to talk about how to put Blockly into your app. So I shall do a
little demonstration of what it looks like to build an app using Blockly. I'm going to talk a
little bit about the architecture and internals of Blockly. Just a very high level overview but
some of the structure of the code and some of the major pieces of how it works under the covers.
I'm going to be talking a little bit about some of the things we have learned in the last,
well actually now more than a decade, I think nearly 13 or 14 years that the team has been
working on Blockly. I have fortunately had the great privilege of learning most of it second
hand as I've only been on the team for about two and a half years. It's much better to learn
for other people's mistakes. And finally hopefully we'll have some time for Q&A at the end.
So what is Blockly? Blockly is an open source client side library for creating block based
visual programming languages. That's a lot of words. So first of all I assume if you're here
at Fosdame that you probably know what open source is. By client side what we mean is
JavaScript. In fact in these days the actual code base is written in TypeScript but it compiles
to JavaScript, it runs in the web browser. And block based visual programming languages just
mean we're going to write software but our source code is going to look like a bunch of puzzle
pieces connected together. So here is a picture of a Blockly workspace with a little program that
consists of a function that computes Fibonacci numbers on the right and a piece of code on the
left which we'll call that to compute the first five Fibonacci numbers and print them out neatly
formatted. Now let's have a look at that in action. We can have a look at this very program here. You
can see with Blockly that we obviously have these various blocks and I can pick them up and move
them around. I can edit the text if I want to change. And then over here we can compile this code
to any of five different programming languages. We support JavaScript, Python, PHP, Lua and Dart.
Now this is a little playground for Blockly. You'll note that one of the things that it does not do
is run the code. Blockly is the editor and I guess you could say the compiler but it is not the
runtime, it is not the app that uses Blockly. So let's have a look at an app that uses Blockly.
This is Blockly Games. The website is Blockly.games and it consists of a series of puzzles. This is a maze.
The first level of maze is very easy. I just need to move forward twice. And I have succeeded in
solving the maze. It shows me the JavaScript code that was generated. If we skip ahead to a slightly
more interesting level, here I can create a loop and I'm going to add a conditional and I'm going to
check to see if there is a path to the left and if it is I will turn left and if not I will move
forward. And now when I run the program hopefully Pegman will make it all the way around the maze
to the end. And so here Blockly is being used to display and edit the programs and then the game
itself displays the maze and the various controls and it calls back into Blockly to highlight the
blocks as the program runs. Great. All right. So a little bit of history. Blockly originated
with a project called App Inventor. Now my slide says that it started in 2010 but I saw a presentation
earlier this morning from the App Inventor team and I think they said it started in 2008 and I
suspect they are probably right about that. It was a web app to create Android mobile phone apps.
It still is in fact. It was originally sort of started by Hal Abelson and Mark Friedman. Hal
Abelson some of you will probably know as one of the co-authors of the structure and
interpretation of computer programs. A very well known computer science textbook from MIT.
It was a web app and in its earliest version the front end the block editor was written in Java
which was an interesting choice at the time because Java was kind of already on the way out.
A hot Java browser with built-in JavaScript was very much a thing of the 90s and by 2010 if you
wanted to run Java in your browser you had to install a bunch of plugins and fiddle around and
it was not that easy to do. But you know it worked. Here you can see a screenshot from some very
early version of App Inventor. It looks a lot less pretty than the current version does if you were
here for the talk this morning. There were some issues with the Java editor. This was the kind
of rendering bug that would be encountered and getting things to work well. Other than you know
once you got the Java applet running was quite challenging. So kind of recognizing that the
writing was on the wall for Java in the browser and that JavaScript was the way forward. My
colleague Neil Fraser joined the team with and was assigned the task of rewriting the front end
in JavaScript. He tried a bunch of different technologies to do the actual rendering. He used
Canvas and SVG, wrote initial prototypes in both of those, decided that SVG was the way to go.
So ever since Blockly has been an app written in JavaScript that produces SVG to display the
blocks in the browser and on the right you can see a screenshot of a very early version of Blockly.
The amusing thing about this is nobody knows where the trash can icon came from. So we were obliged
to replace it with one that we knew what the copyright status was. Yeah, things happen. Of
course all of you know the ghoul is infamous for cancelling projects and App Inventor was definitely
one of those. It was cancelled but luckily it was open sourced and it was adopted by MIT and they
have continued to develop it. Neil continued to work on the JavaScript block editor. It had not
actually made it into App Inventor by this point and they had taken the Java front end and thrown
it away and I think initially did their own thing completely. But Neil plowed on because he could
see that this was going to be a useful piece of technology. Unfortunately even at Google you
can only work on a cancelled project for so long before somebody tells you you should be doing
something more useful with your time. But my friend Neil, he's a stubborn man and he decided he
would go on vacation. But his vacations don't look like that. They tend to look more like this. The
great thing about coming into the office when you're on vacation is nobody can tell you that
you're not supposed to be working on the cancelled project. And after some weeks of vacation he had
quite a lot of leaves stored up. He did a demo of the first version of the JavaScript block editor.
The project was uncanceled. He got his vacation refunded. His boss told him he should take a
real vacation this time and he was assigned to work on the project full time. The next year
2012 Blockly was officially released. It got this name. Some of you may know that Google Docs
started off originally as something known as rightly and Google has had any number of similarly
named projects inside and Blockly made it out with that name because of that. It debuted at the
Bay Area Maker Faire and I don't know if any of you have been to Maker Faire. I had the chance to go
in 2018 and there was an entire hall full of educational things that people had made and I
was completely boggled at the number of them that had some kind of block based programming
language as an interface. It was quite fun to go around with Neil and guess which ones were
actually Blockly and which ones only looked like Blockly and not even he could always guess which
was which. Blockly has been, because it wasn't specifically made for App Inventor, it was made as
a general purpose library. It was quickly adopted by lots and lots of other groups. So 2014 we had
Code.org releasing a version of Flappy Bird where you write your own Flappy Bird game with blocks.
In 2014 President Obama with the first US president to code using Blockly, you can see his first
program was simple and the interesting bit of the story is our partnership with Scratch. So I'm sure
most of you have heard of Scratch or seen Scratch. Version 1.0 of Scratch was as I understand a PC
app, probably for Windows, I'm not certain about that. In 2013 they released the first web version
using Flash. It had taken them several years from when they made the decision to use Flash. Flash
was like the obvious technology for doing this kind of interactive thing in the browser. By the time
they had the first version ready and released it, Flash was very much on its way out. So they began
thinking about what they would do and Neil and some other folks at Google who were involved with
Blockly also started thinking about what to do and it seems that both Neil and some of the product
people at Google reached out to the Scratch team independently and had conversations,
engineer to engineer and planners to planners and everybody came to the conclusion that using
Blockly as the next version of Scratch might be a good idea. This required a lot of work on
Blockly's part to support the Scratch UI and on Scratch's part to redesign their app around
Blockly. But finally in 2018, it was announced in 2016, in 2018 it came out in data test and in 2019
Scratch 3.0 was released and it has been Blockly under the covers since then and that is certainly
in terms of usage as far as I know our biggest partner. We do however have lots and lots of other
partners including several people in this room including all of these companies and many,
many more and I guess we also have people using Blockly who have no access to computers. This
photo was taken at a school in Malaysia, no computers but they were using cutouts, laminated
cutouts of Blockly blocks to teach their kids to program or at least to be able to do thinking
about computational thinking and algorithms and so on. So I think the question might be to put
to you guys what are you guys building with Blockly? If you have built something with Blockly,
I would love to stand up and just give us maybe a one sentence description of what you have made.
So I'm one of the maintainers of the open app home automation system where we're writing rules and
some of these rules are usually done in Python or JavaScript or we're using Blockly to actually make
the learning curve much easier so even kids can create their rules, their home automation rules
with a Blockly. So we're using the standard blocks and I implement like 100 more blocks
that make our home automation very easy. Nice. I'm adding support for Go, the Go language to Blockly,
especially for TinyGo so we can compile it to microcontroller. Oh, okay, that's cool.
Thank you. A block-based editor to write automations using Google Home. So Google recently released
the Google Home scripting language so it abstracts over that, gives you a set of blocks to work with
so conditionals and actions that you can run and yet block-based editor for that. Yeah, cool.
Oh, and yeah, two more. Apologies to those of you on the livestream who can't see. I'm actually
building an XML editor with Blockly so in this case we are actually going in the other way around
where we generate blocks out of the XML so you can actually just load an XML file and it's going
to become blocks and then somebody that doesn't know XML is not technical can actually
work with that XML file and modify it. That's cool. Yeah, thanks.
We're a boot camp. We teach full stack HTML, CSS JavaScript. After we teach HTML and CSS,
we use Blockly to have people make event handlers and that kind of thing. It generates JavaScript
and so they can make their pages interactive before they have to learn syntax. Then they can
look at the exported JavaScript and learn how it works and what it's doing. Nice.
I use Blockly within Node-RED so within Node-RED you write a function node in JavaScript when
you run out. No, I want to use Blockly so I'm heavily involved with the person who's written
the Blockly interface inside of Node-RED. Excellent. That's my house.
So yes, this is lovely but I think this gives such a great picture of the variety of different
things that people use Blockly for from clearly educational focus things to utility scripting
languages for other applications and sort of more businessy applications. I think that's great.
All right. How to use Blockly. Those of you who already built something with Blockly, this will
be old hat to you but for those of you who have never seen an app built with Blockly,
I am going to show you very quickly how one might go about doing that. First of all, just a little
bit of terminology so you can see here this, the big rectangle with all the stuff in it is what we
call the workspace and on the left of the workspace you can see the toolbox which consists of a set
of categories, logic, loops, math and so on and then a fly out that contains the blocks that users
can drag onto the workspace. On the right you can see a bunch of blocks and on the far right you
can see some zoom controls, a trash can, of course there are scroll bars, a grid, you can see a tool
tip, just the usual sorts of things. All right, we'll see how this goes. So, oh yes, I was practicing
earlier. So, on our developer site there's a page called Get Blockly which gives a number of ways
of obtaining it. We publish Blockly as an NPM package and we also publish a variety of little
utility packages for it, one of which includes a script that will create an app for you and so
rather than making you sit as I take half an hour to type out a bunch of HTML and CSS and
JavaScript we will just start with the little sample app. So, we'll take a moment to install some
packages. It'll end up creating a directory structure for us that contains a main HTML file,
a main JavaScript file, some other files on the side and it also creates a webpack configuration
so that we can do an NPM start. This will fire up webpack, it will build the application,
start a local server and open it in the web browser.
So, here is our sample app. I'm just going to show you how it works. So, again we have our kind of
categories here. I'm going to take a repeat block. I'm going to have it repeatedly put some text
on the screen and you can see over here the JavaScript that is generated by the blocks
appears here and underneath you can see the output of executing that code. We can change the color of
the text and the contents of the text. It's very straightforward. Let's have a look at the files
that it's created. I will try to make sure that these windows are big enough that you can all see
if I can remember the right key combination. Yeah, here we go. Great. So, everything interesting
is in the source directory. The app has a very simple HTML file, which basically just contains
a few divs, one for the whole page, one for the output pane at the bottom left, one for the
generated code at the top left and then the main blockly div which ends up being on the right.
There is some CSS that puts all these things in the right place. This is a point where I have to
admit I am not actually a front-end engineer despite working on a front-end library. So,
I'm not going to try and explain how that works. I'm sure many of you here know far better than I
do. The interesting parts of this app from my point of view are all in the main JavaScript file here.
So, this was created for us using a template, but it's reasonably straightforward. The first bit of
the code at the top just imports the various libraries and other files from the local directory
that are going to be needed. This app contains some custom blocks and a custom generator for
those blocks. The generator is the part of the blockly that actually produces the JavaScript
code to be run. So, we register those custom pieces. Then we find the three divs in the HTML page.
The one that is most interesting to us is BlocklyDiv. This line here is where Blockly is
actually turned on, fired up on our page. It has some options. At the moment, the option we're
passing in is Toolbox. I'll go and show you the contents of the Toolbox in a moment. It's loaded
from another file in the same directory, but we can add some other options. For example, Blockly
supports a number of different renderers. I can change the renderer that's used
just by adding an extra option here. When I save the file, you can see Webpack
recompiles it, reloads the browser, and now we have this much more scratch-style appearance.
We can also add a grid.
Those dots are pretty small. There are actually little crosses. Let's make them a little bit bigger.
Length 5.
That's a little easier to see. I could change the color.
Both Neil and myself are Canadian, so we use Canadian spellings in Blockly.
I really like blue, so we'll go with blue. Now we have blue grid. The grid you can see is
useful for lining things up, but our blocks are not currently snapping to it, but we can
turn on an option for that. I should know my JavaScript syntax by now. Now you'll see the
blocks will snap to the grid each time I move them to keep them nice and neatly organized.
At the moment, you can see in the tool box, you can see a number of blocks. Most of these blocks
come from a standard library of blocks that we created, but a few of them, for example,
this add text block is a custom block for this particular application. You can have a look at
that here. Here is a piece of code which defines the add text block and adds it to the dictionary of
blocks that Blockly maintains. We have lots of documentation about the format here, but as you
can see, it's basically a little bit of JSON with a set of options that control the shape of the
block and the fields and inputs it has. If we look at the tool box, here we have another bit of
basically JSON that lists all the blocks that appear on the tool box, and in some cases, if they
have some extra blocks attached to them. For example, here we have the repeat block, which is in
logic. You can see that by default comes with a shadow block with a number here, so you don't
need to attach a block there just to put a number in. That's given here with the default value of 10.
Suppose that I'm making an app and I decide that I don't need to have variables and functions in
this app because it's a very simple app that's going to be targeted maybe at young users or that
just don't need that functionality. I can go down and find the variables and procedures sections of
the tool box and I can delete them and you can see they disappear from the app. It's reasonably
straightforward to control what Blockly looks like, what blocks it provides, and the things scroll
options, the availability of the trash can, and so on. Blockly architecture and internals.
For those of you who are of a non-technical background, thank you for bearing with me so far.
We're going to talk a little bit more. This part of the talk is going to be more technical,
but it's going to have more pretty pictures hopefully, so maybe that's something.
First of all, a little bit of terminology. This is a stack of blocks, which is basically just any
arrangement of blocks that are connected together. You can see that blocks have a number of connections,
so the little bumps at the top and bottom are previous and next connections for statements.
On the right, you can see a value input where this block can take a value from another block,
and a statement input where you can connect a bunch of other statement blocks to it that it
will execute, in this case, while it's repeating something. On the bottom, you can see a block
that has an output connection on the left, and we describe it as having a dummy input, because
the contents of the block is basically, it's a bunch of stuff, but all that stuff has to be
contained in a set of inputs. The top block has two inputs, which are labeled, though the bottom
block doesn't need any actual input, so it has what we call a dummy input, which is basically just,
it's an input, but not really an input, and it's just to put other stuff inside, in this case,
to put a color picker. The stuff you put inside inputs are called fields, and here's a few different
kinds of fields. For example, on the left, we have the labels repeat and do. We have a drop-down
field for while. The next block has a smaller block inside it, and that smaller block has a
number field on it. On the right hand side of that block, you can see over here, this block here is
what we call a shadow block, so it's a space you can put a block, and until you put a block there,
it acts as if it has a number block in it, whereas this input here has an actual number block in it.
Here we have an image input. In this case, it's just a static picture of a paragraph symbol,
and we have a multi-line text input, and finally over here, we have a color picker, which when you
click on it, pops up a little grid of colors that you can choose from. So those are fields, and you
can see a number of them here, and you can imagine that creating an app, you might want to be able to
create some more kinds of fields. You can see the architecture, and I should admit this is
emitting a tremendous amount of detail, but the high-level architecture is that we have
classes for workspace, for block, for input, and for field, and you can see that the input
has, the input class has three subclasses, one for those dummy inputs, one for value inputs,
and one for statement inputs. The field then has a number of subclasses, labels, numbers,
text input, drop down, and so on, and you can see that this, you would want to be able to add more
of these, and to facilitate developers adding more, the inputs and fields come from something
called the registry, which is basically a little internal database running inside Blockly
that allows the developers to register additional classes to provide different kinds of fields,
or potentially different kinds of inputs.
On the right, we have a little set of classes that are the Blockly events, so there is an
abstract base class, and then for example, for events that have to do with blocks, there is a
block base class, and then another series of block create, block move, block drag, block delete,
and so on, and similarly for inputs and fields, and the connections that connect the inputs and
blocks together. A large hierarchy of events that are generated, you can add event listeners to
listen to these, to different events, and you can also register more events so that your custom
fields, for example, could generate custom events if you wanted them to, and whenever Blockly needs
to create a field, it will look up the field in the registry, and then the field can then look up
the events that it needs to create, and so on, so it's all relatively extensible, it's quite easy
to add additional kinds of things. On the left, there's a little bit of stuff here, so workspace
and block are the kind of the abstract models of a workspace and a block, and then there's versions
of those, there are subclasses of those for the ones that are actually rendered on the screen,
which are block SVG and workspace SVG, and those communicate with a bunch of code that I don't
want to get into called the rendering subsystem that is responsible for like producing the SVG
that is then fed to the browser to make it draw the pretty pictures of blocks.
So that's basically the front end of Blockly, the back end of Blockly as it were is the code
generation subsystem, so we have a base class code generator which provides mostly utility
functions for code generation and things like indentation and so on. There is then a subclass
for each of the languages we support that provides things like functions to correctly quote text in
that language, and for each of those subclasses we also provide an instance of that, in this case
the lowercase j javascript generator that has a little dictionary of generator functions,
so for each different block type, so controls if is the if block, there is a generator function
for that, and so for each of the different blocks there's a there's a function written
that takes as its input a block instance and some extra information for example a reference to the
generator itself and it returns a piece of source code and for blocks that have inputs
of various kinds they will then call the generator function for those inputs
and take the resulting bits of text from those and combine them together to produce the output text.
All right, lessons from a decade of Blockly. So there's a lot that I could say on almost any of
these topics but I think the thing which I am certainly very conscious of and I know Neil is
is that dependencies are very expensive. At the moment if you install Blockly it has only one
dependency, the npm package has only one direct dependency, and that is on js dom and js dom is
only used if you are running Blockly headlessly in no js because we need some DOM functions to parse
XML. So this makes Blockly relatively dependency free but it didn't used to be like that. In the
early days of Blockly we made use of the closure library, I don't know how many of you are familiar
with this but it's a JavaScript UI widget library which also provides some JavaScript utility functions
and it was very convenient to use, it took care of a lot of things like oh you need a date picker,
well it provides a date picker and it also had utility functions that were useful but the closure
library is kind of big and that meant that Blockly was kind of big and tended to load slowly especially
if you had a small internet connection and some of the people that we are most interested in
reaching are people who don't necessarily have that great an internet connection and if you are
in some place where you are dependent on dial up or a low band with mobile phone connection
we want you to be able to use Blockly and obviously if it takes a minute or two to load a page
containing Blockly that is not going to make you very happy, it's not going to make you a returning
customer of that app. So the Blockly team wanted to reduce the size of Blockly, now the piece of
advice that was given was basically to go all in on closure, the closure library if you are going
to use it it has a certain cost in size so you might as well use as much of it as you can and
remove any other code that you have in your app that does the same thing that you could use a
closure library for that seems like good advice and that was the direction that Blockly went for a
while but it became clear that this wasn't working very well, Blockly was still pretty big and the
closure library is designed for HTML and CSS whereas Blockly is mostly the front end is mostly
SVG and using HTML and CSS based widgets in an SVG app turns out to be not very much fun and not
particularly easy so eventually the decision was made to get rid of closure and it actually took
several years to remove all of the bits of code in Blockly that called into the closure library,
the few remaining bits that were actually useful basically just got copied into the Blockly source
code and that dependency was eventually deleted but in the meantime there had been the cost of
keeping it up to date and so on so it was definitely worth removing it because now we own all of that
code ourselves and we don't have to worry about it breaking because somebody has decided to push
an update but it took a long time and a lot of work to get there so I think the team is always
thinking very carefully when opportunities come along to use new bits of tooling it can be very
tempting some new application or utility or library that looks like it would make your life easier
and be super convenient but it has costs another example of this is Blockly games until last week
was running on Google App Engine it was using a version of the API which has been deprecated for
about five years the amount of effort that it was going to take to update to the current version of
the API was enough that we decided that it was going to be easier to self-host it so it still
runs in Google Cloud but it runs in Google App Engine on basically a you know a bear server
where we supply all of the software infrastructure that we previously used to be using that was
provided by by App Engine so and hopefully that will considerably reduce the amount of time we
spend dealing with App Engine updates in future so progress is great but keeping up is hard
when Blockly was started around 2010 the technology that was used in use at Google was
ECMAScript 5.1 which is to say an old version of JavaScript the closure type system I'm not
sure if any of you are familiar with Google's closure compiler but it provided type checking for
JavaScript very early on it was one of the first major tools to provide type checking for a JavaScript
and when you build web apps the size that Google does that's extremely handy we also used what I
might optimistically describe as a module system that was based around a function in a library
called Google provide it wasn't really a module system it was basically just namespace objects
if any of you who's used the TypeScript namespace feature it's basically exactly the same as that
you can create an object and put some properties on it and put some more objects on those properties
and you basically build a little tree and then you tuck your code away somewhere on that tree
that's not going to conflict with anybody else's code and each file in your project puts its code
on a different part of that tree there is still only one scope so if you declare a global variable
by accident everybody gets to see it but it was a pretty pretty useful system at the time
in 2012 TypeScript came along with a different slightly different and slightly incompatible
but similar approach to JavaScript typing in 2014 Google promulgated a new module system called
google.module which I think I would describe as being very similar to common js modules the syntax
is a little bit different but the semantics are pretty similar to common js modules you have
a local scope in each file so you can declare global variables in a file and they stay within
that file life is happy 2015 of course we saw es6 and the introduction of ECMAScript modules
with their own syntax and semantics which were quite different from common js modules
and 2016 Google started to adopt TypeScript for our main internal code base
guess what tech google Blockly was using in 2021 when I joined the project
no no we were using ECMAScript 5.1 and the closure type system and google provide because
you know the the Blockly code base is not enormous in the grand scheme of things google
scale it's a pretty small bit of code but it's still hundreds and hundreds of files and when
you have the choice between adding useful features to your project or fixing bugs that are impacting
your users or spending time on refactoring your code to use a different language dialect and type
system and module system that latter task doesn't seem like a particularly good use of your time
the problem of course is with an open source project if you want to get people to contribute to
your project it's nice to be using the same kind of tech that they're using in their projects and
just just show hands here who's used the closure type system
yeah three people have put up their hands that's about what I expected
so yeah it's hard to find people who are on work on a project that is essentially written in
something like a foreign language or at least a foreign dialect of a language that you know
so we decided that we needed to update but the the cost of that update was substantial
so the migration process was arduous we started by doing an almost entirely manual migration from
the google provide module system to the google module actually really modules system that required a
lot of restructuring code because google provide you didn't have any kind of notion of exports like
just you you created a bunch of properties on an object and that object was visible to any of the
other code in the system and so they could use those data properties or call those functions
we had to think about what each file needed to actually export that other
files within blockly were going to need and what things in that file were private and needed to
be kept within the file it was it was quite a lot of work and we had to move a lot of code around
and that ended up breaking creating a lot of breaking changes in blockly which was not great but
we didn't know any way around that at the time we then were able to do a migration from es 5.1
to es 6 this was a mix of manual work but quite a lot of help from various bits of tool various
bits of tooling to do that migration so starting to use class constructors for example or class syntax
then the main final migration from the closure type system in google module to type script
and es modules that was actually done using internal tooling at google i i probably can't
talk a great deal about that but i know that it was briefly it was briefly made available as a now
deprecated project on github whose name i whose public name i don't remember but it was used by
like one or two other companies that had very heavily closure oriented code bases to do a
typescript migration and they were fairly successful with that but it wasn't a useful general purpose
tool so that has not not really been that useful to anybody else but we we we pushed through we
fixed a lot of type errors that were left over after the automated tooling dumped a bunch of files
into the repository and we eventually got it running we got it passed through typescript
compilers type checking we figured out what we needed to do to get closure compiler to correctly
ingest the code that was generated by the typescript compiler and life was good and now we have
blockly in written in typescript with standard typescript yes modules code base that will be
much more familiar to potential contributors it took a long time for us to get up to speed on
these new technologies we made a number of regrettable mistakes we we we completely rearranged a lot of
the public api of blockly which in hindsight we probably didn't actually need to do but we just
didn't know at the time any better way to do it because we were mostly novices to the technology
we're using we had only one person on the team who had really used typescript before we undertook
this migration and even even kind of expertise on closure compiler there were only a few of us on
the team who had used it extensively and kind of understood what it was doing and how to interpret
some of its more obscure error messages the the blocks the library blocks that we provide and
the code generators those were migrated a bit later that migration was actually done a bit more
manually and using some of the wisdom we had gained by the migration of the main part of the
code base and i would say largely that went a bit more smoothly i don't know that we could have done
the main part of the code base entirely manually it took us basically a whole year's work from the whole
then roughly six person team the the blocks and generators were a much smaller piece but it was
satisfying to to do those and feel like i was you know doing it the way we should have done it the
first time on the main part of the code base but yeah especially in the world's javascript
technology changes it changes incredibly quickly and you're going to need to invest time at some point
to keep your code base looking like something that a new developer will recognize
architecture is always easier in hindsight so i guess there's a there's a few parts of this
so part of it is when blocky began being written javascript was still a relatively new language
that was used it was it was certainly we had gmail and google maps and javascript was being used to
write web apps but web apps were still a relatively new thing and i think there were many different
ways of writing code in javascript javascript is an object-oriented programming language
but it didn't originally have class syntax and so a lot of people explored quite different ways to
build objects it's not unusual for javascript code to copy properties from object to object
to use mixins and things like that and there was a lot of stuff like that within the blocky
code base blocks in javascript in blocky you can see there's a block class and the way different
shaped blocks were created was basically to have a mixin object with some properties on it some
methods and data you you copy those onto a new fresh block instance and you call an init method and
it then kind of sets up the block so each block is an instance of the block class but it has
some random extra properties on it and that was fine in the early days of javascript but that is
not a type model that works particularly well with class syntax or especially with type script
type checking there are some other interesting wrinkles here we have a workspace svg and block
svg classes they were essentially an effort to separate the the model from the view but it's
it's one of these cases where instead of having a view the model is the view and this then creates
some problems we might want to turn our block definitions into actual subclasses of block but
now you need a now you need to be able to subclass either block or block svg depending on whether
Block v is running with a UI or headlessly so fixing that yeah these guys here they're they're
they're difficult we we will probably continue working on this bit of the Block v architecture for
some time but let's just say it's a lot clearer to us now how we should have written this the
model the view and the controller should have been separate pieces there should have been less
inheritance between them it should have been a has a rather than is a relationship and so on but
you know nearly nearly 15 years experience you you learn some things
finally no technical decisions are made in a vacuum Block v is a library that is used by
hundreds thousands of other projects we don't we don't even know exactly we we have some metrics
that tell us that we know roughly as a minimum about 40 million people a year use Block v to learn
to code but we have no idea how many people use Block v as part of some you know corporate internal
financial reporting system or a robot controller or any of the rest of us so we need when we're
making changes to Block v we need to do so in a way that is going to be as as convenient as possible
for developers to upgrade unfortunately if you never make any breaking changes to your code base
you end up in a situation where you're eventually not going to be able to make any useful changes
to it either so we look very carefully at breaking changes we try really hard not to break the Block
v API and behavior but if we if we break it so the developer has to update their code we're okay
with that but we do not break Block v in a way that would prevent the developer from being able
to update their app and load saved programs what we do not want is somebody who's written a program
in Block v being unable to load that program into Block v because of some change that we've
made to Block v itself so some breaking changes for the developers hopefully no breaking changes
when it comes to loading programs because we would like well it is still the case that the very first
Block v programs that were ever written there it you know all the ones from Block v games that
kids have saved those all still load and work today so and finally Block v's unexpected killer feature
we only let the developers choose the hue of blocks people like to pick colors for things
it we basically in Block v you can choose the hue and Block v chooses the saturation and value for
the different parts of the block developers often complain about this and you can work around it if
you really want to but the big advantage of doing it this way is it turned out that if you only let
the developers choose the hue they really couldn't choose a set of colors that looked awful
and the unexpected benefit was that Block v basically just looked better than any of the other Block
front-end libraries out there at the time because because it prevented developers from
making bad color choices so we kind of won on that one sort of by accident so yeah sometimes less
is more I guess all right we have a few minutes left for Q&A I am happy to answer almost any
question I can I did mention that I am not much of a front-end developer most of my work on Block
v has been involved in migration and tooling and things like that but I am happy to answer any
questions I possibly can with that mind stick up your hand I will pass you the mic if you're not
too far away just so people who are watching on the live stream can hear could you tell us a bit
more about Block v's own type system so each block can have a type so what kind of types are
supported yeah so Block v's type system is very simple basically each connection can provide that
to say an input or an output connection from a block can provide a list of strings those strings
might be things like string number boolean color something like that and you can only connect
two blocks together if there's at least one type in common between an output and an input
and that is basically Block v's type system now there has been some work done by my colleague
Becca on something called a nominal connection checker which is basically designed to provide a
much more sophisticated kind of type checking that was she did that work experimentally actually
before she joined Block v team so if you if you search for Google Block v nominal connection
checker you can find some of the work that she did on that we are definitely interested in providing
a bit more sophistication in terms of typing but it's not a huge priority for us because for the
kind of educational market that we are there is our main target of our work this very simple type
system that we have is generally good enough to make it easy for kids to not produce invalid
programs which is our main goal thank you so one in the middle or I was just gonna
I just wanted to build on that so for App Inventor we also have a system we extended Block v to
take a function so as long as the function returns true then you can connect two blocks
and that gives you basically max the developer of the app can figure out what type checking they
want to do yeah
thanks for the talk really interesting and one of the downsides of teaching coding through
or one of the perceived downsides is that when you graduate beyond using blocks to using real code
it's a one-way street right you take your code and you generate some code and it maybe is not
the same shape of code that you would write if you're writing code from scratch and it's also a
one-way street you can't go back yes do you know if there's been much research into going the other
way like bringing existing logic into Block v and on kind of bridging this gap more smoothly on
like improving the quality of the generated code to feel more like a human would write yeah so this
is this is something that we're definitely very interested in my my colleague Neil is actually
doing some work at the moment on basically pre-work on something like that the idea is okay so the
fundamental problem with the kind of general code to blocks is that within Block v even in our
standard block library we we don't have blocks that represent all of the different things you
can do in any of the five languages that we support so there are lots of programming constructs which
we just can't represent in Block v so you would need to have a set of blocks that could represent
everything that the language can do in order for that to work in the general case even in the case
the specific case that the program only uses constructs from within the set of things that you
can do with Block v blocks it is not that straightforward to figure out how to how to do the reverse
uh so Neil has a sort of a little research project that he's working on that will basically try to
evolve a Block v program to be as close as possible to a given input text so one of the things
that he's worked on so far is making the generators work a lot faster so that you can basically like
randomly permute a Block v program like thousands of times and try to like you know tweak it in the
direction that it looks more and more like a piece of code but yeah the fully general case would
require a very comprehensive set of blocks and some fairly careful thought put into how to make that
mapping work uh I will take your question but actually I just wanted to mention one thing which is
I don't know if you guys are aware but there are some other projects that have looked at
alternative approaches to the kind of blocks to coding transition one that I'm aware of is called
pencil code which is a it's basically like a blocks editor but the blocks look a little bit
more like source code and you can kind of click a button and the blocks disappear and just leave
behind the source code and so then you can write code and you can then like click the button and
then the blocks come back so that's kind of a clever that's kind of clever system so that that
might be that might be a route that one could that could take again there was lots of things we
would love to add to Block v uh alas we are a small group with a lot of responsibility and
have to focus on you know fixing the bugs for one thing but yeah uh yes I have two small questions
first of all why is google I appreciate that google is doing this because we all um use it
and I don't appreciate a lot so why is google actually developing it what does it bring to
google that's the one question and the second one I'll just add it quickly what will do with
future of Block v so what do you have in mind on doing it okay so the first question but what
why does why does google pay me to work on this I to be honest the the real answer that is
is several uh several pay grades above where I sit on the org chart uh I don't really know for
sure but I do know that we work with very closely with a part of the organization called education
for social impact uh which as of uh as of this basically as of this weekend has moved to become
part of google.org so it has always been uh I don't want to say exactly a charitable but a very
intentional uh corporate citizenship outreach kind of uh department they run a lot of coding
learn to code digital skills programs uh often targeting disadvantaged people marginal
look at marginalized groups and uh we they are they are within google they are effectively our
our customer um google uses Blockly as part of the um I forgot we have a learn to code program at
cs first uh that is based on scratch which in turn is based on Blockly so the work that we do on
Blockly eventually makes it around that loop so it becomes part of the cs first uh product that
that google runs and and then just generally uh despite the current uh despite the current
to belt tightening and so on at google google I think does continue to recognize that there is a
considerable value to uh things like cs education uh for one thing uh we may not be hiring at the
moment but for almost the entire company's history uh google has struggled to find enough
highly qualified engineers so anything involved in providing more potential uh potential staff
for the company has been a an important initiative uh hopefully we'll go back to hiring otherwise
maybe that will be less useful as a justification uh as to ours the uh future of uh Blockly um
we have a bit of an internal roadmap uh I find myself standing up here having had a long weekend
of thinking about all kinds of other amazing projects and I cannot remember what we talked about
in our team meeting even just a couple of weeks ago um but we are uh one of our major projects at
the moment is to try to get our major partners up to date using latest version of Blockly because
there have been a lot of bug fixes and new features added since there uh many of them have forked
Blockly and are using older versions and we are gradually getting them back onto the main line
version of Blockly uh after our big migration and uh in addition to that work we uh we have a number
of projects adding features that have been requested one feature that was recently added
was a set of APIs that allow you to create uh create procedure or function blocks in one workspace
and call them from code in another workspace uh it can also be used to like uh have two
workspaces that are kept in sync and we did a little demo within one browser but you could very
easily ship the event data between two different browsers so you could have two people coding
together on the same program in on two different computers um so we have a we have a we have a
you know essentially a list of feature requests along those lines adding features that are useful
for Blockly uh and generally we try to add them a fairly generalized way so that they can be used
for a number of different purposes and that that one is an example of it.
Did you have set outside contributions? Do you have set outside? Yes we do we do we are we are an
open source project uh we get a lot of pull requests uh come our way uh you can see actually here we
have two different github repositories the Blockly repository is the main Blockly library
and we welcome pull requests there but that is maybe not the easiest place for less experienced
developers to start the Blockly codebase is it's a little complicated and the interesting bits are
quite complicated but Blockly samples is a repository containing a large number of plugins for Blockly
basically additional stuff that you can plunk into the registry to add new kinds of fields
and new features to Blockly and that is a much more tractable place we had a number of plugins
that have been contributed to that repository and we get lots and lots of people doing bug fixes
we have a good first issue label so if you are new to the project and maybe potentially even
relatively new to contributing to github there are any number of little little bugs that are tagged
that way that might just be like might just be fixing some documentation or you know
uh you know correcting some typos or things like that uh and there's definitely lots of feature
requests we quite often get feature requests from people on the forum they're saying oh how do I
do this with Blockly and I'm like well we don't currently offer a way of doing that but here's
a sketch of what you could do and if you can get it working please turn it into a plugin and contribute
it back to the Blockly repository so other people can use it and uh of course it doesn't always
happen but a surprising number of plugins have happened because somebody wanted something and
we're like well we don't have time to build that but here's here's a rough idea of how to make it
work go for it and and they've they've succeeded with it so yeah we uh we absolutely welcome
contributions uh and in addition to external contributors we're very lucky to have a small
group of other Googlers who work on Blockly as a 20 as a 20 project so yeah so that uh there's
you're kind of in in a way as an external contributor you're sort of in good company because
there's other external contributors within google as well we try to make life good for all of those
people if we can. Any final questions? All right well thank you very much just before you go if
you were one of the people who stuck your hand up earlier to tell me what you were building in Blockly
please please come up here after the talk but yes so that's what you thank you so much for coming
and uh I look forward to seeing what you guys make with Blockly