[MUSIC]
Hi everyone. My name is Rachel Fenichel. I lead the Blockly team at Google.
This talk is part of the 2022 Blockly Developer Summit.
In this video I’m going to tell you what we’ve been up to in the last year
and what we’re planning to work on in the next year.
This talk has two parts. The first part looks back at the past year of work;
the second part looks forward to the next year.
For each part I’ll talk about features that we have built or will be building,
then look at progress on our migration to TypeScript.
So, what have we been up to since the last summit?
As a reminder, the last summit was April 28th and 29th,
2021. This year’s summit is May 3rd and 4th, 2022.
First things first: the Blockly team grew significantly in the past six months.
In alphabetical order, here are the people who started working on Blockly this year,
either full-time or part-time.
First up, Aaron Dodson. Aaron is a software engineer who works on Blockly and on Google’s
CS First project. You’ve probably seen him being helpful on the forum and on GitHub.
He has had the dubious honor of managing JSDoc for the past few releases.
Next, Beka Westberg. Beka has been an open-source contributor for multiple years.
This year she joined us at Google as a full-time software engineer. During her internship last
summer she rewrote Blockly’s serialization system to make it flexible and extensible.
Christopher Allen knows JavaScript from the inside out and applied his knowledge
to the TypeScript migration for the past several quarters.
John Munoz is a product manager at Google. This
year he became the primary point of contact for partners using Blockly.
Last but not least, Neil Fraser – Blockly’s founder – returned
to the team to work on Blockly and Blockly Games.
So, what features did we build in core this year?
Following last year’s roadmap, we focused on formalizing and publishing APIs
that let developers extend Blockly without forking or monkeypatching.
Beka designed and built a new serialization system that allows blocks to be serialized to JSON.
Developers can now define custom serializers, avoiding translation from XML,
and add code to serialize arbitrary objects. You can also define add-ons to this serialization
system to save custom state. To learn more, check out Beka’s summit video.
Maribeth extended the Tooltip API to allow developers to render arbitrary elements in
tooltips. There’s an example that uses this new API in the blockly-samples repository.
And Monica added a “positionables” API that you can use to add buttons in the
corners of the workspace, as well as a plugin that exercises this new API.
Over on the blockly-samples repository we also saw some solid work, especially on plugins.
Plugins implement features that are useful in the right context, but not appropriate
for every use of Blockly. You can mix-and-match them to get just the features that you need.
Building plugins also lets us use and test our APIs.
Monica built a backpack plugin using the new positionables API. With this plugin
you can drag blocks into a backpack to save them, and you can share the backpack contents
across multiple workspaces. This is useful for a logged-in user who wants to use the
same blocks in multiple places; it’s also handy for a multi-user world with a shared backpack.
Monica also added a content highlighting plugin
that shows the bounding box of all of the blocks on a workspace–particularly
useful for large or complex workspaces where the user can easily get disoriented.
Finally, Abby and Maribeth built a scroll options plugin with two cool scrolling-related features:
first, users can scroll the workspace with the mouse wheel while dragging a block. Second,
the workspace automatically scrolls when a block is dragged to the edge of the visible workspace.
Next up, migration.
In the second half of 2021 we started a long-awaited migration from pure ES5
to TypeScript. This was no small task: we touched every file in core,
and made significant changes to our build system. There is another summit talk where
I take a deep dive into the details of this migration, but I’ll keep it brief here.
In Q3 we paused feature work and the whole team pitched in
to update every file to use Closure modules ES6 syntax.
We released a beta version in September, rather than a full release, to get more time for testing.
In Q4 we finished modularization, did a lot of testing, and fixed up parts of
our build pipeline to keep our outputs as close to the originals as possible.
Migration work continued into the first half of 2022,
although it did not involve every member of the team.
During Q1 we updated from Closure-style classes to ES6 classes. //Again, this was an involved process
because we had to review APIs and initialization code to make sure nothing had changed.
Christopher and Aaron worked on build scripts
to make sure that developing in uncompressed mode continued to work,
which really tested our collective understanding of modules, module loaders, and language features.
Christopher and Beka build a renaming script to help developers with upgrades.
It defines a standard way to record and apply deprecations and name changes,
and hopefully makes your lives easier when updating.
In Q2 2022 we turned on the TypeScript compiler and started converting individual files to
TypeScript. This process will continue, one file at a time, following Microsoft’s suggestions for
converting to TypeScript. I’m aiming to finish all externally-visible conversions by the end of Q2.
So, that’s what we worked on in the last year. Next up is the roadmap:
what we’re going to do and build in the next twelve months.
Our feature work on the core library will focus on adding APIs to support
plugins. We’ll choose APIs based on a combination of the plugins that external developers build
and the ones that we build and publish ourselves. We read everything you post on the forum,
so make sure to tell us if you are building a plugin and get blocked by a missing API.
We’re still following the plan I described last year, where we define interfaces for
parts of Blockly and then move them into the registry so that you can hot-swap for
your own implementations. The trash can is next on the list.
Most developers interact with the core library through our releases on npm. We currently release
at the end of each quarter. We follow semantic versioning conventions: incompatible API changes
cause major version bumps; backwards compatible addition of functionality causes minor version
bumps; and backwards compatible bug fixes cause patch version bumps.
I want you, as developers, to be confident in updating regularly;
have painless upgrades; and find new versions useful enough that you want to update.
To make that happen I want to fully stabilize core after the migration, so that we can go
down to two major releases a year (from four). As a stretch goal, I’m aiming to streamline
our release processes so that we can push smaller, more regular minor and patch releases.
We gave the core library a lot of love this year,
so I expect next year will be quieter in core and we’ll focus more on plugins.
In the second half of 2022 we’ll explore how to better support users with large or complex
workspaces. That could mean support for folders (like App Inventor has); modal function editors,
like Code.org; refactoring tools; and rendering performance improvements.
The correct way to organize a large workspace (or multiple workspaces)
depends heavily on context, so these will be plugins rather than features in core.
Plugins are critical for the library because they force the team to use it as developers,
without the ability to reach inside and use private functions. I hope that
continuing to work on plugins pays off both directly (in the plugins we
publish) and indirectly (in the ways we improve the library).
Finally, documentation. The library gets more useful when there’s good documentation.
In the next few quarters we’ll take a look at our documentation and fix up existing holes,
particularly in user guides and codelabs.
As always, I invite you to get involved in writing or editing codelabs–especially if
you’re already explaining things on the forum to other developers.
We’re also going to get more opinionated in our documentation,
and publish more guides that focus on best practices. I’m particularly interested in
documenting best practices for accessibility and block design.
In the next year I expect us to finish up the TypeScript conversion by reaching
a state where Blockly is primarily developed in TypeScript and our type definitions are complete.
Thanks for watching this talk, and I hope to see you at our upcoming developer summit.
If you have questions you can post them in our Q&A or bring them to Q&A sessions at the summit.