Almost everyone says that. I’m sure I could do a better job of explaining, but also part of the problem is that it’s a new kind of thing – in a category of its own. I feel like it aught to be easiest to explain it to you though! It’s no more and no less than what is needed to make an EYG-ish editor experience for an arbitrary programming language, even a complicated real-world language like Javascript.

Like you I think that having a browser native experience gets code editing into a lot of exciting spaces that programming needs to be like TVs in homes and tablet computers in classrooms – even and especially places where code literacy is needed but installation of a native application would be a major barrier to access.

To build structural editing for an arbitrary language you need some kind of system of parsers to define the languages and some kind of universal node-tree representation which has the property of being able to snap nodes together as if they were lego bricks, just like the EYG editor does.

CSTML is the bottom layer of my infrastructure: the lego bricks. You could think of it as a reimagination of XML that learns from JSON and GraphQL to fix XML’s flaws. It has three big innovations in it:

• Unlike XML, nodes have named relationships to each other which makes expressing syntax trees far more natural. You could imagine that in HTML and XML all nodes have an implicit relationship called “children” with their children, but CSTML is able to add fast random access via named relationships as a layer on top of the implicit ordered-children relationship
• Like HTML, CSTML nodes can be said to have “inner text” embedded in them. This embedded text is the source code of the program as the parser saw it, and serves as the source of truth for semantics. Having a source of truth is very important because the process of parsing is going to denormalize this data by injecting it with a great deal of metadata – in particular the structure of the parse tree expressed as enclosing tags like <*BooleanLiteral> 'true' </>. Having inner text ensures that we are never at a loss for how to print the code the tree is meant to be printed, which is a very important property for being able to make editors. CSTML is not meant to be seen directly except by developers, rather it is meant to be a data layer which can encapsulate any state that might be produced by a powerful GUI tool.
• Lastly CSTML has gaps. It permits you to declare that part of a tree is missing in a particular location. It does not ever permit invalid syntax trees (I do not wish to allow them in my editor), so allowing incomplete trees is the necessary escape hatch. A tree with a gap in it is, conceptually, a template. The smallest possible template is a syntax node, and lego brick with gaps into which other syntax nodes may be placed.

On top of CSTML is BABLR, the schema validation layer. It helps you narrow the infinite space of arbitrary valid CSTML down to just what should be valid according to the rules of your programming language. “Parse don’t validate,” is our philosophy, so once we’ve parsed nodes we make them immutable. Deeply immutable trees of syntax nodes lead to easy caching and another editor feature we want: the ability to hold history efficiently just by holding on to prior roots of the immutable data structure.