BABLR: Scratch-like visual editing for all programming languages

I know Javascript like the back of my hand, but I may as well be illiterate in Ruby or Python or Java these days. I wouldn’t even know what all the syntax means. The only way to edit a program right now is if you already know what all the syntax means, because the basic mode of editing programs is typing out each character of the syntax.

My suggestion is that a second wave of programming is coming, one powered by editors that interface directly with the semantic representation of code – in other words the representation we currently think of as the AST. These editors will be able to say exactly what the meaning of any textual syntax is, will allow reorganization of logic by simple drag-and-drop, and will be as accessible to scripted change agents as they will be to humans using UIs.

Editors are already powered by AST. Linters, code formatters and refactoring plugins are already “scripted change agents” without human UI. So how does it help with sustainability?

That’s a great point! I own an open source library, and I would like to be able to offer my users help migrating past breaking changes. Indeed scripted change agents exist, so I can do it right? It’s a Javascript library, so do I ship an ESLint plugin? Or maybe babel plugin and instructions on how to setup Recast? …or what about projects that use tree-sitter for tree-based manipulation? Because I can’t anticipate the environment available to scripted change agents, I’d have to write my codemod several times right: once for ESLint, once for Babel, once for Tree-sitter, once for Biome… Then someone who needed to make that change to their code would load up the version of the codemod that pairs with the tools they use (have installed and configured) in their codebase. It’d be kinda like having to write your website once for Firefox, once for Chrome, and once for Internet Explorer.

As you can perhaps imagine I just don’t ship scripted change agents for breaking changes at all, and neither does anyone else, which is a shame because they would be a huge win for sustainability if only we could all agree on what environment such agents run in. Web browsers have agreed on the environment that JS runs in so that you can write code once and run it (more or less) in any browser anywhere. Let’s learn from them!

I would like to be able to offer my users help migrating past breaking changes.

Do you have an example of just one specific problem that you are trying to solve for your users? I don’t understand what is “migrating past breaking changes”. I would appreciate real 3rd party project where this problem exists, the code for the solution they choose and the code with your solution for comparison.

Take a look at GitHub - reactjs/react-codemod: React codemod scripts. This is built on jscodeshift which is built on recast.

Ok. Taking a look.

create-element-to-jsx

Converts calls to React.createElement into JSX elements.

npx react-codemod create-element-to-jsx <path>

Converts calls. Looks fine. How does your tool do this?

I just define data structures, so you take the input CST and transform it into the output CST however you want. There’s no need for anything as complicated as a CLI. The CSTs always have the literal source text embedded in them (in the string-looking parts inside the tags) so to finish a transformation you validate that the transformed structure is a valid tree, and then print all the literals.

I still don’t see how to use your tool without CLI. It is the most simple UI from possible. So, how to invoke the transformation?

You provided code seems too to convert calls to React.createElement into JSX elements. Can you write it?

Basically it would/will work like this:

// names may change
import { parse, traverse, print } from 'bablr';
import * as jsLanguage from '@bablr/language-js';
import { jsxEnhancer as jsx } from '@bablr/language-jsx';

const jsxLanguage = jsx(jsLanguage);
const tree = parse(jsxLanguage, sourceText);
const transformedTree = transformJSXElements(tree);
traverse(jsLanguage, transformedTree); // verify JSX is really gone
print(transformedTree);

(sorry for all the edits)

I don’t have a JS grammar completed, so I can’t really write that yet no. A query engine will also be pretty important to implementing transformations and I have not written one yet.

1 Like

That’s more complicated to invoke than

npx react-codemod create-element-to-jsx <path>

And you’re saying that CLI is complicated. :smiley:

And if writing CLI interface is complicated, then how do you write all the missing code to make this demo work?

react-codemod can only be applied from the CLI: it has no javascript API. I consider my program easier to use because wrapping my API in a CLI would be trivially easy for a package like react-codemod which already has a CLI defined, and additionally I am able to support scripted (non-cli) usages.

You wouldn’t judge how easy it is to use the internet from the experience of using DOM APIs to code a UI framework, would you? The average user browsing the internet only cares that their DOM APIs and web frameworks work well enough that they never have to think about them.

Internet works. Your tool doesn’t. That’s an easy judgement. :smiley:

Remember the forum is about Open Source Sustainability, so my main goal here is to validate that the tool you’re promoting improves something. We can discuss pure theory in other threads about sustainability, but for tools, working demo speaks louder than words.