I would like to make a block-based programming language. Should I use canvas, svg, or various divs and text boxes to make the blocks?

Snap! uses canvas and Scratchblocks uses Blockly (which uses svg). Which design is the most idiomatic HTML?

If you intend on having a colour picker like the touching colour? input, you should use a canvas.

Canvas seems like the way to go in this case. By using canvas, you lose out on all of the nice built-in HTML elements like text inputs, which is a bit of a pain, but if you're willing to re-create those, you'll have much more control over the blocks and how they are rendered.

I'm not sure the best practices have anything to say about implementing a block-based programming language in JavaScript.

Okay, but seriously – I suggest using canvas. It's a lot easier to control exactly how things will render. This is good in that it'll be easier to write the code, but also because you'll get the same result on just about any web browser. If you use HTML5 input elements, your blocks will look different on a Windows computer running Chrome than a Mac running Safari, which will also be different from my Linux system running Firefox. If you use canvas, you'll get results that are (nearly) identical on whatever browser/system combination your users have.

I also recommend using a decent library, if you're going to use canvas. If you use just HTML elements, you get the DOM for free, which acts as a handy way to manage elements and such; with canvas, you don't get that. Chances are, you'll want to either write a similar system yourself, or load a library which does that for you. (I totally suggest morphic.js, which is what Snap! uses!)

webgl

TheMonsterOfTheDeep wrote:

webgl

WebGL is too complicated for my use case and for me… (I know that you were joking.)

TheAspiringHacker wrote:

TheMonsterOfTheDeep wrote:

webgl

WebGL is too complicated for my use case and for me… (I know that you were joking.)

Well, it's probably how I would prefer to write it.

I would take the Blockly approach and use SVG and native HTML elements. That way you don't have to worry about having to render every pixel yourself and you can take advantage of the browsers implementation of text input, copy and paste, etc. You will probably get better performance too since the browser is heavily optimized for rendering HTML/SVG while JS rendering to the canvas is limited to the speed of JS.

PullJosh wrote:

By using canvas, you lose out on all of the nice built-in HTML elements like text inputs, which is a bit of a pain, but if you're willing to re-create those, you'll have much more control over the blocks and how they are rendered.

The problem is that this is hard. Snap! took this approach and it has taken a lot of work to get simple things like copy and paste to work.

BookOwl wrote:

PullJosh wrote:

By using canvas, you lose out on all of the nice built-in HTML elements like text inputs, which is a bit of a pain, but if you're willing to re-create those, you'll have much more control over the blocks and how they are rendered.

The problem is that this is hard. Snap! took this approach and it has taken a lot of work to get simple things like copy and paste to work.

Couldn't one have a hidden HTML input?

Sheep_maker wrote:

BookOwl wrote:

PullJosh wrote:

By using canvas, you lose out on all of the nice built-in HTML elements like text inputs, which is a bit of a pain, but if you're willing to re-create those, you'll have much more control over the blocks and how they are rendered.

The problem is that this is hard. Snap! took this approach and it has taken a lot of work to get simple things like copy and paste to work.

Couldn't one have a hidden HTML input?

If the input is hidden you would have very little control over the input and how you're able to select and change it. Also, some browsers have issues with inputs that are invisible. There would also be a lot of work to figure out how to make the hidden input connected to the block input. Would it be individual for each or just one globally? How would you get the text width when it being rendered differently? Inputs for a block-based program, in general, would be difficult no matter how you approach it.

I personally used svg for the blocks with foreign objects to have text boxes in svg. Divs would also work but you would have less control over the shape of a div since they are rectangular. Canvas could work but there would be a lot of details involving the canvas interaction and rendering of blocks. But whatever you choose you should first think of the bigger picture you're aiming for. How will you move the blocks and how will they interact. How will it be compiled and ran. How will inputs and variables work. But most importantly how will you make it expandable. You don't want to spend an hour adding one new block and getting it to work. It could seem like a lot when you first get started but you should just experiment with it and slowly build up your program.

Wetbikeboy2500 wrote:

I personally used svg for the blocks with foreign objects to have text boxes in svg. Divs would also work but you would have less control over the shape of a div since they are rectangular. Canvas could work but there would be a lot of details involving the canvas interaction and rendering of blocks. But whatever you choose you should first think of the bigger picture you're aiming for. How will you move the blocks and how will they interact. How will it be compiled and ran. How will inputs and variables work. But most importantly how will you make it expandable. You don't want to spend an hour adding one new block and getting it to work. It could seem like a lot when you first get started but you should just experiment with it and slowly build up your program.

Thank you. I'm going to have a “spec” data structure that contains the grammar of each block and a function that reads the grammar and either creates an SVG or draws on the canvas. The compilation of the code would be separate from the editor and the code would be ran in a different window.

Oh, a note: I've previously created two little experiments that may be of relevance. The first was a dragging-svgs-around test (specifically for a block-based language), and it certainly seems like a good choice. The other was a block-based-language thing that was meant to also be typable, and that I did using plain ol' divs, because rectangles fit the aesthetic pretty well.

The reason to use SVGs is that, if you're using vector graphics anyways, using JavaScript + canvas to render it is going to be slower (potentially a lot slower..?) so it would be pretty silly to do that.

Right now, I'm leaning towards SVG because I want to use the native browser features such as highlighting and copying and pasting rather than reimplementing them.

Use Nathan’s visual.

Hi, can you guys help me to become a scratcher? I would really like that..

I think it's better to use descriptive HTML elements to assist screen-readers; and then style with CSS to make everything look pretty.

I suggest you use pixijs for your rendering, due to its very easy approach on WebGL and fallback to canvas

http://pixijs.io/examples/#/demos/dragging.js - might help

Everyone, I've already started on the SVG route.

TheAspiringHacker wrote:

Everyone, I've already started on the SVG route.

Sounds good. You should put it on Github Pages.