Scratch-blocks: How much work on scratch-blocks can/will go upstream?

[luxaritas]

In my opinion, scratch-blocks looks nicer than Blockly and the UX is much better (ie, typing a number directly in a block instead of connecting a text block to the side of it - I find it a shame that this is a "hack" and not the normal method of implementation from what I've seen). I even noticed that the Scratch-like styling was using in the Santa Tracker programming activities. Is any of this UI work going to actually go upstream to google/blockly, or should I just ditch the idea of using Blocky for a custom application if I want the different UI and instead use scratch-blocks and scratch-vm?

[ed-cooper]

I doubt that the blockly UI will change - a lot of web applications depend on it, and to suddenly change it would cause a variety of issues

Maybe what you want is to create a fork of scratch-blocks, add your own block definitions and then customise the style sheets to suit your design preferences? I haven't looked at the code particularly but I presume scratch-blocks and blockly will expose the same things (except in the case where we removed some of the blockly modules)

[luxaritas]

I'm just thinking from the perspective of a new project, blocks does not look very appealing. I'd personally advocate a new major version of Blockly or such that would have an improved UI. As I said, at least I feel that scratch-blocks looks/works nicer, and I'd like to see that in Blockly while scratch-blocks is just customized for Scratch's particular needs.

Side note, why isn't scratch-blocks a GitHub fork of Blockly?

[luxaritas]

*Blockly does not look very appealing

[rachel-fenichel]

Hey there--I'm a member of the blockly team and I've done a lot of work on scratch-blocks over the last year.

From a development perspective there are two issues here: UI and behaviour. UI governs how the blocks look; behaviour answers questions like "What happens when you drag a c-shaped block into a stack of blocks?" Some scratch-blocks behaviour has moved into blockly; the scratch-blocks UI will not.

Scratch-blocks definitely has a nicer UI than blockly, but at the cost of being more restrictive. As an example, let's look at one issue you brought up:

(ie, typing a number directly in a block instead of connecting a text block to the side of it - I find it a shame that this is a "hack" and not the normal method of implementation from what I've seen)

This is easily solved by using shadow blocks. Search for "shadow" on this page to see an explanation of them. So blockly allows for this behaviour, but doesn't make it the only option.

The scratch style is really nice for inline inputs but doesn't allow for external inputs, which are used by a ton of blockly programs. They can definitely be ugly, but they allow for much more functionality.

---

There are a lot of other differences between scratch and blockly that mean that scratch-blocks won't simply merge upstream into blockly. Blockly is general-purpose, while scratch-blocks is aimed much more at education.

All that being said, we do actually work to move things upstream from scratch-blocks, often by just implementing them in blockly as they come up and then pulling them into scratch-blocks. We've tried worked hard to make sure that differences in behaviour between the two exist for good reasons, and not just by default. That's been an advantage of working really closely on this for the past year.

If you want the scratch-blocks UI and don't mind the restrictions, you should absolutely use scratch-blocks and scratch-vm. It's intended to be a library for you to use, not just a component of scratch 3.0.

[rachel-fenichel]

To the side note: scratch-blocks isn't a fork of blockly on github because scratch-blocks was not open-sourced from the beginning, and you can't fork an open project as a private project.

[rachel-fenichel]

And finally, on a personal level, I'd love to given Blockly a UI refresh. I understand that it looks dated. We just don't have the resources, both in design and in engineering, to do it now :/

[luxaritas]

@rachel-fenichel Thanks for the background, I'll definitely take a read. Personally I'm not a fan of external inputs from a visual perspective, but I also don't have much experience with Blockly. If I ever find some time, I might try drafting something up for Blockly just for fun, but we'll see how that goes! I'd definitely be interested if there's any other implementation details like that which need to be kept in mind.

[rachel-fenichel]

@LFP6

I'd definitely be interested if there's any other implementation details like that which need to be kept in mind.

Take a look at block_render_svg.js in blockly and block_render_svg_vertical.js in scratch-blocks. The constants at the top determine the shapes of individual connectors; the functions in each file determine which parts get drawn where. rendered_connection.js may also be interesting to diff.

---

With respect to external inputs, blockly's goal is to be flexible and let the developer decide what works best to get information across. Sometimes external inputs are clearer, even if they look meh. More generally, they get used a lot when blockly is used as a configuration language, like this.

Here's a contrived example of when external inputs are useful for something you might write in scratch:

Here's the quadratic formula, for the positive case:

Here's the same thing with the outermost block set to have external inputs:

In the second one it gets a lot easier to see that you're dealing with a fraction.

If I take external inputs to the extreme, I get this:

which looks pretty nasty to me but technically works better for a small display or for really breaking down what's going on there--maybe you'd use that if you're teaching the formula for the first time.